aantron
Redis-likes for Session Storage?
This framework looks very impressive! I noticed in the docs the session backends include memory, cookies, or sql. Was curious if you'd be open to a PR that extends a redis (or redis-like) session store?
Could it be written as a library, which we could link to from the Dream repo/sites? The reason I am asking is because I am concerned about picking up a dependency, or else an awkward API with extra callbacks to bind it to a dependency dynamically. If there is any obstacle to writing a redis session backend as a library, I think we should fix that and I would be very open to a PR to that end.
I see, the memory, cookie, and db backends reuse resources already included in the framework whereas this would require at least a redis client library which may not get used by anything else. That said, it can be useful for async worker queues but understandably not a high priority.
A separate library with a link in the docs works for me as a staring point.
I'll start drafting that library. My plan was to match the other storage module APIs and use a popular\common redis client library so not expecting much chaos there, but will see how it goes.
If I do run into any barriers from the framework design I'll create issues to make sure it's something that needs to be addressed and to ensure we're on the same page for how to solve it.
If there is any obstacle to writing a redis session backend as a library
Correct me if I'm wrong, but I don't see any way to write a new session middleware in such a way that it can be used by the session accessor functions like session_field, set_session_field etc. Of course it's possible to just make new accessor functions that talk to Redis for example, but it would be less flexible because we wouldn't be able to just swap out session backends and keep using the same accessors...
On the contrary they are written in such a way as to let you plug in another back end, like Redis.
Not at the moment. An early version of Dream, when I was still developing it, before publishing, had the hooks for users to bind their own backends exposed, but they ended up being pretty messy, and I wasn't confident enough in the design to leave them in the API.
This should actually be simplified by transitioning to effects, as one of the issues was that I wanted to have as few of the operations as possible be promise-valued, but depending on both the nature of the back end and the exact behavior of the binding, I/O might have to be done in almost every place.
Right, currently if an API was exposed for this it would probably look something like:
val sessions_backend :
get:(string -> string promise) ->
set:(id:string -> expires_at:float -> string -> unit promise) ->
delete:(string -> unit promise) ->
?lifetime:float ->
middleware
Kinda awkward...