Announcing tower-sessions

[maxcountryman]

Hi folks,

I'm pleased to announce the first release of tower-sessions, a crate that aims to replace axum-sessions with much improved design and overall better functionality.

How is tower-sessions an improvement over what we already have?

First and foremost it addresses the problems we've had trying to share the underlying async-session Session by owning an implementation of the session functionality that's tailored to tower applications. This new design follows other successful tower middleware, like tower-cookies, and wraps an inner state in a way that makes it safe to share mutable state without the possibility of deadlocking in the service itself.

Furthermore we're able to simplify the API by having just one extractor, in the form of Session--no longer will your applications have to choose between writable and readable session handles (in fact there are no handles anymore).

This new crate also provides direct support for Redis and SQLx backends out of the box, just enable the respective feature flags and you're good to go.

There are several additional design changes which aim to simplify the process of using sessions with tower and axum applications while maintaining flexibility.

What's next for these crates?

Going forward, my goal is to migrate folks to tower-sessions and I'll continue to iterate on the crate as folks provide their feedback over there.

As for axum-sessions, I've split the crates in this way so as to minimize disruption--if you use axum-sessions because of async-session then that won't change. However, the development is currently stalled pending crucial changes in async-session. I don't know when those changes will land and if you can migrate to tower-sessions, I would encourage it.