Make session loading lazy

[maxcountryman]

Ideally we would not load sessions from stores until the moment we actually want to use them.

Currently we pay an overhead price of loading the session from the backing store on each request where this middleware is installed. This can be mitigated with caching techniques, for example by using Moka. That said, it's overhead that could be avoided altogether.

Consider that many applications will install this middleware at some lower point in their route graph where only a subset of those routes will use the session--this is an example of overhead we should strive to eliminate altogether.

To facilitate this, I'm working on strategy for loading sessions on demand. The current approach involves making the session generic over a store. This would allow us to defer the store load until we interact with the session in some way, say by explicitly loading or saving it.

These methods will be abstracted away such that as a user the interface remains the same, with the exception that the session takes a generic parameter. Internally, the session will manage a kind of cache which is hydrated lazily and sent back to the store when modifications have happened.

This should also simplify the design measurably and perhaps even enable other optimizations, such as a custom future type (i.e. eliminating the need for a boxed future).

[maxcountryman]

cc @bikeshedder, this might be of interest to you. 🙂

[maxcountryman]

I've put together an implementation on this branch.

Some things to note:

1. It loads infinitely faster compared to our current implementation (we simply do not load from the store in the middleware).
2. The session is now generic over an arbitrary store, meaning the session houses the store directly.
3. The API must change such that the key-value methods are async (and in the case of *_value methods, return a result).
4. Session store IO can happen during a request now, directly in the handler, which means we can enable atomic updates for certain kinds of stores.

One side effect of this approach is the middleware itself is much simpler. Of course, the tradeoff here is that the session itself has become more complex (shuffling state between a store and memory is tricky and there's a good deal of necessary nuance).

Regarding the second point: it might be nice if instead of this being a generic parameter we were able to leverage impl SessionStore as a parameter to Session and SessionManager. Unfortunately given the associated error type on SessionStore, this doesn't seem like a fruitful path. We could opt to remove the associated type and supply a library-level error type. But apart from being a worse end-user interface (now you have to map your error types to our crate's error type) it also seems incorrect and obscures the underlying store error from application code.

Regarding the third point: I think this is an okay tradeoff. There's more syntax required now. Methods have to be awaited and there's no way to e.g. just grab the value and ignore the result. That said when you know your store cannot fail, you can of course unwrap the result. As for async, this crate is entirely built around async and will be expected to be running within an async context so I think the await syntax is reasonable change.

Finally I think something like this design is more or less required for scale. At a certain point, it's not practical to load the session from a store, even if that store can be made very fast, on every middleware request. It's also worth pointing out this is how other established frameworks implement sessions. (In fact, this design very closely mirrors the Django approach we've based our semantics on.)

@czocher I'd love your thoughts on this direction.

[maxcountryman]

I looked at integrating the above branch with axum-login and needing to provide the store as a generic parameter was pretty unfortunate in that context.

Given that, I decided to try another approach, where we provide a concrete type for session store errors. That's now in this new branch. Note that this branch has been updated such that the examples and tests should all function; please feel free to give it a try.

It's a bit sad to lean on erasing the error type, but if we wanted to continue to use an associated type, that too would require a generic over the session which would leak into e.g. axum-login: I'm pretty convinced we want to avoid this as much as we can. What this means is that downcasting will be required to get to the original error type. Most applications will probably not need to care about this and can simply match on session::Error::Store directly.

Unless there are objections to this design or thoughts about other ways we might achieve lazy sessions, I'll plan to start migrating the crate to this implementation.

[maxcountryman]

Expanding a bit on the concrete error type, I've iterated just slightly here to define an error enum of three concrete errors. What this means is stores will need to convert their errors to this enum. I think I prefer this over the Box<dyn Error> because ultimately the error type is needed for the library and its application-code uses should map decently to this enum without the trouble (and potential runtime peril) of downcasting.

[maxcountryman]

I've opened a PR and would appreciate feedback there as well.