General purpose dependency injection

[Kinrany]

As far as I can tell, a significant part of axum, including magic functions, is a fully general dependency injection framework that doesn't have anything to do with HTTP.

Would it be a good idea to extract this framework into a separate crate?

[davidpdrsn]

Would it be a good idea to extract this framework into a separate crate?

No I don't think that's a good idea. The way extractors work is a core part of axum so it's really important that we control the API as much as possible and can evolve it as necessary. Extracting it into a library potentially makes things harder to change.

[Kinrany]

Isn't that part of the API relatively stable? And besides, major version bumps in the new crate would solve that, no?

[davidpdrsn]

It’s not about stability. It’s about control.

[jplatte]

In addition to what David wrote, the "framework" here is mostly made up of traits that are very specific to HTTP. The only way to abstract over that in a way that's not HTTP-specific would be to have the framework crate expose one or more macros for declaring these traits, which would make axum's code a whole lot less readable, and defining the input format for these traits (which would likely need a bunch of configuration / extension knobs) would be far from trivial.

[Kinrany]

Ran into another challenge that made me think about this again.

Derive macros are super important for composition of trait implementations. A single type can derive lots of different traits with effectively the same mechanism.

Axum's magic functions are very convenient, but they don't play nice with derives for other traits.

Specifically I was looking at aide, a library for generating OpenAPI documentation. It offers no way to derive documentation from handler functions, and I see how implementing that would be a challenge. In the absence of shared tooling, it'd be easier to derive documentation for types implementing FromRequest + a version of Handler that only asks for async fn call(&self) -> Self::Result.