[Feature Request]: Redis adapter

[tobiasdiez]

Package

lucia

Description

The migration guide of v3 specifies that the redis and unstorage adapters are deprecated. There doesn't seem to be a proper replacement for those. Given that Lucia now exclusively handles sessions, and those are most often stored in fast access db systems (e.g. Redis, other key-value dbs), it seems logical to support these. In fact, on may even argue that they are more relevant than the classical dbs that are currently implemented for the storage of session data.

[pilcrowOnPaper]

I don't think there's enough demand for a Redis adapter, and I did experiment with a Redis adapter but the API was always awkward. If we were to remove "users" from Lucia and solely focus on sessions, I could see myself adding a Redis adapter.

[yalamber]

@pilcrowOnPaper would it be suitable to use redis/KV store for session and other database table for users data in may be a hybrid adapter?

[tobiasdiez]

@yalamber It's relatively simple to implement it yourself. You can take https://github.com/JabRef/JabRefOnline/blob/64660d8a626ca092a39a4c123d830249ce25044e/server/user/UnstorageSessionAdapter.ts as a reference and modify it to use redis.

I still feel it would very much make sense to provide this out-of-the-box by lucia. If someone else needs the redis/unstorage adapter, please ping me and I'll consider publishing it as a new package.

[yalamber]

@tobiasdiez thanks, I am trying to use cloudflare Workers KV, this should be helpful for us to follow.

[babalugats76]

Just started digging into migrating from V2 and this development was disappointing to me. As @tobiasdiez suggests, the ability to use a low-latency KV provider for sessions is, in fact, "more relevant", and, to me, more vital, than the support of an array of traditional persistent database storage options--at least for my use cases.

I agree with @yalamber, that there is a true need for an out-of-the-box "hybrid" adapter; in my experience, combining slow, persistent storage (for users) with fast, ephemeral storage (for session info) is the best practice and prevailing norm, not an edge case by any means.

Please consider that, because of this change in direction, many more developers will have to develop custom adapters to replicate previous, off-the-shelf functionality. I don't believe that this is necessarily a simple task for the average dev. Not undoable by any means, but it does raise the barriers to entry and discourages somewhat the use of an otherwise stellar framework/solution.

To mitigate this, I would recommend publishing a detailed custom adapter example that features unstorage session storage and a traditional database provider for users (perhaps this already exists?). To support existing users, a more explicit one-to-one migration example for those using the deprecated session storage adapters would seem like a fair mitigation.

Put simply, the original instinct to more explicitly support separate session providers, e.g., unstorage, etc., was the on the mark, imho. I believe this issue should be revisited and not merely closed.

[gmwill934]

This is really disappointing.

Can someone please explain the decision on deprecating v2 redis adapter and not building a proper replacement?