Split TypedPath into a separate crate

[Palladinium]

• I have looked for existing issues (including closed) about this

Feature Request

Motivation

I often write web+desktop portable applications split into three crates: a frontend, a backend, and an api crate.
The backend crate uses axum, and the frontend crate some form of cross-platform UI framework, something that both compiles to WASM and native platforms.
Both frontend and backend crates depend on the api crate, which is mostly a bunch of types with derive(Serialize, Deserialize).
I try to keep as much of the type safety of requests and responses in the shared api crate, and this pattern works great for extractors like Json.

I'd love to put types that derive TypedPath into the shared api crate, so that the frontend can use the to_uri and with_query_params convenience methods to keep the paths in sync with the Router on the backend. In theory, I can do that, but doing so also pulls a lot of dependencies into the frontend crate, including axum, which is something I would like to avoid, especially if I'm compiling for WASM.

Proposal

Could the TypedPath trait and derive be split into a separate crate and re-exported, to avoid having to pull in all of the axum_extra dependencies if all that's needed is a consistent representation of request URLs? The headers crate is currently re-exported in a similar way by the typed-header feature. The axum-specific parts, like RouterExt, would remain in axum_extra.

The Resource helper would also make sense to expose outside of axum, but that one is tougher due to how coupled it is to Router (which is also what makes it ergonomic).

Alternatives

Currently, my workaround is to duplicate the work in the api crate with both a backend-centric and a frontend-centric implementation. The former uses TypedPath and is feature-gated, and the latter uses manually written format!s. The two are kept in sync by unit tests. It is not very ergonomic, and it's easy to forget to add unit tests for new paths.

I have not yet found a better alternative, but suggestions would be welcome! 😄

[mladedav]

Another alternative would be to make axum an optional dependency of axum-extra and not pull it unless needed.

[jplatte]

If what @mladedav suggested is possible, I'd be happy to accept a PR. That seems like something that doesn't have any downsides.

[mladedav]

Thinking about it again, I'll just mention feature unification, which is the classic downside almost always when features get involved. If frontend and backend are in the same workspace, this is not going to help.

[zeonzip]

There isn't a clean way around the feature unification problem without splitting backend and frontend into different workspaces or build units, but there could still be some upsides to making axum optionally depended on in axum-extra nontheless.

[mladedav]

axum is now an optional dependency of axum-extra in main so that should help.

As for feature unification, if you're using nightly, you might want to test this, otherwise you can compile with cargo build -p frontend to work around the unification problem.