If sessions die when your system reboots, that means you can't reboot the system (update the service) without breaking whatever any users were currently doing on your site or in your software. That does sound bad to me and like a bad fit for Redis the memory cache. (I know it can do persistence optionally but that's what the person above you was complaining about: this is not what it's good at)
Why not use a regular database for this (can be as simple as an sqlite file, depending on your needs), or the default thingy that comes with your framework or programming language? This is built into everything I've ever used, no need to reinvent session storage or overengineer the situation with jwt or some other distributed cryptographic system and key management
> Why not use a regular database for this (can be as simple as an sqlite file, depending on your needs)
A lot of depends on the scale and load pattern (e. g. ratio of active and inactive sessions). For a small scale sqlite could be a good choice.
Storing session in a regular DB (say Postgres) could be more expensive (hardware wise) than in Redis and there are cases when the load is high enough to matter but the budged is not unlimited (to use a DB at any cost). Also redundancy with a Redis cluster is easier than with Postgres. I don't think Redis always better, but at some load patterns it is.
> or the default thingy that comes with your framework or programming language?
Default PHP session store is files in /tmp - works for a home page but if load is high it explodes (millions files in /tmp is too slow to work with).
I didn't know what you meant so I looked up micro frameworks. Wikipedia has a page named Microframework and lists 23 examples. I don't have time to dive into each of them and most items aren't links (so not sure how relevant they are), but
- I know Flask and it has sessions
- It also lists three frameworks for PHP, which has sessions built into the language (session_start() is what I use in any project that needs a session system)
- Expressjs is one of the few others with a Wikipedia page. Looking into that, it says it requires some middleware for having sessions, which seems not only well-supported, but there is also an include from the authors of Expressjs themselves called expressjs-sessions. It's technically not in the framework, but the authors provide it and clearly keep it in mind when developing the framework so you don't have to DIY that
I can't conclude this isn't a common feature in microframeworks :p
> I'm also wondering right now why there is no local cache with p2p self discovery and sync. Should be easier than deploying an extra piece of software.
The whole design space for this type of API is weirdly under-explored, but there are some well-supported mainstream solutions out there.
Fundamentally, Redis ought to be a NuGet library, a Rust crate, or something like it. It's just a distributed hash table, putting it onto its own servers is a bit bizarre if the only need is caching.
Microsoft's Service Fabric platform and the Orleans library both implement distributed hash tables as fundamental building blocks. Both can trivially be used "just" as a cache to replace Redis, and both support a relatively rich set of features if you need more advanced capabilities.
Of course, there's Scala's Akka and the Akka.NET port also.
I wonder if you think about (things like) Hazelcast?
It is JVM based "shared cache" so can be used to transparently share results of expensive queries - but also to share sessions. It mostly just works but the free version have some issues when one upgrade data models.
I know half the people here probably loathe JVM but once one is aware of one implementation I guess it should be possible to find similar things for .Net and maybe also go and Python.
Garnet, like Redis, is explicitly designed to be remotely accessed over the network, which is frankly disappointing and derivative.
Microsoft could do better than that!
For example, Azure App Service could use an out-of-process shared cache feature so that web apps could have local low-latency caches that survive app restarts.
> Garnet, like Redis, is explicitly designed to be remotely accessed over the network
I know, but it is written in a sane language so my suggestion was that you can literally reference a project and make it into an embedded database. But then again, I would've tried Tsavorite/FASTER KV first.
I'm using redis only for temp state data like a session (when I can't use a jwt).
Or when I have to scale and need a warmed up cache
Is that bad now?
I'm also wondering right now why there is no local cache with p2p self discovery and sync. Should be easier than deploying an extra piece of software.