Thoughts on shaku_rocket service configuration and hand off to rocket

[n0mn0m]

Hi,

I've spent some time tinkering on a basic rocket project here and there the last few days. For context most web services I've worked on in the past have been in C# .NET and Python. Having worked through The Rust Book and some rust exercises here and there I thought a project would make things more concrete and push me to learn more.

Starting with Rocket I wanted to find some form of DI configuration to help with testing and swapping out components (Loggers, db etc) while I learn and experiment. Looking at the shaku_rocket example the module is injected to manage in the same scope it is built.

From the shaku_rocket example I was wondering if you have seen a pattern were something like the AutoFac (or other DI container approach) module builds up all the services independent from the scope where rocket is constructed, and then that is container is handed off to the rocket construction function?

Something like:

fn configure_services() -> {
    let module = AutoFacModule::builder()
        .with_component_parameters::<Logger>(LoggerParameters {
            ...
        })
        .with_component_parameters::<Database>(DatabaseParameters {
            ...
        })
       .with_component_parameters::<SwaggerUI>(SwaggerParameters {
            ...
        })
        ....
        .build()
}

fn rocket() -> rocket::Rocket {
    rocket::ignite()
        .manage(service)
        .mount("/", routes![index])
}

This allows for service construction independent of ignite and launch which makes testing easier, and allows for mock service injection. The thing that stands out here is the module builder and how to avoid having a giant module to use the builder pattern with all the required services. I'm sure there is a pattern to handle this (thats something I plan to dig into more tomorrow), but I also thought I might get into some interesting ownership scenarios.

Before I get too far down this path any anti patterns you might call out? Early on in my project and rust learning, so I wanted to get some input.

Gist here that extend the autofac example with a test.

[n0mn0m]

Re reading https://docs.rs/shaku/0.5.0/shaku/macro.module.html this morning I think I would use sub modules for the above. Thanks for giving me a place to think out loud, it's helped some pieces click together more. I'm going to look at the test again too and their structure.

If anybody does have suggestions still happy to hear those.

[AzureMarker]

Building up the services and module can totally be separate from Rocket's initialization. Your gist highlights that pretty well, and I especially like how it includes a test for the endpoint.

You found some info on submodules, which is how shaku handles organization and abstraction of groups of services. There's a submodules getting started guide that should be helpful: https://docs.rs/shaku/0.5.0/shaku/guide/submodules/index.html

If you want to look at a (medium-large) project which uses shaku_rocket, check out https://github.com/Mcat12/pihole-api/. The shaku module is located at https://github.com/Mcat12/pihole-api/blob/master/src/services/mod.rs.

[n0mn0m]

This is great. Thank you! I've got a PiHole on my network so I'll have to give this a spin while digging in.

Once I get a bit further I'll add my project repo and share it back on this post. If you want me to add a test to the shaku_rocket example just let me know.

[AzureMarker]

It most likely won't work with the latest version of Pi-hole, unfortunately. It was developed along with https://github.com/Mcat12/pihole-web to replace the PHP web interface (originally https://github.com/pi-hole/api and https://github.com/pi-hole/web), but the team's priorities have shifted since then and I've moved on to other projects (like shaku!).