Enhancing Redis sessions with hashes and secondary indexing

[mortensi]

Session management could be improved by modeling it as a hash as Spring does. This would reduce serialization/deserialization overheads and benefit from the latest hash-field expiration improvements in Redis 7.4. I would like to understand how to enhance flask-session to support the hash data model (while keeping backward compatibility with the current string format). So, as a summary, we would like to introduce:

• searchable sessions
• ability to find sessions open for a user (different devices)
• expiring data in the session before the session expires (may be useful to model those use cases where "you have 10 minutes" to complete a reservation or anything similar)
• analytics from anonymous sessions or authenticated sessions
• find sessions in a geographical area, or find sessions that are close to a location (e.g. in retail, sessions that are close to a shop)
• reduce the overhead to serialize or deserialize the entire session by just accessing the desired data
• ...

Next Redis 8 version will include search capabilities (already available in the Redis Stack packaging) that can support the scenarios above.

I am willing to contribute, but I would appreciate feedback before starting any actual work on this.

[Lxstr]

Hi @mortensi thanks for your input. I have been absent and still need to catch up on some other PRs but this sounds like an interesting proposal.

My first though is possibly offering a 'passthrough mode' where flask-session doesn't do any serialization/deserialization, but only provides session.id and sets and reads cookies. This would then allow the user to operate something like redis-py on the session ids to achieve all of the functionality you have mentioned. I haven't thought too deeply on this but it is likely there would need to be manual use of methods like .should_set_cookie. Flask-session could provide non-shipped boilerplate to this effect in the repo if it is useful. What are your thoughts?

[Lxstr]

I just noticed that you are with redis so that is great news that you are taking an interest here!

I do see also two other options beyond my suggestion above

1. Work towards a fork or extension that is exclusively for and tightly coupled to redis.
2. Implement the features you have suggested directly in flask-session (I can't picture how this would look)

Depending on the choice, the overall position of Flask-session may need adjustment. Flask-session currently sits in a strange place where we try to facilitate the easy swap in and out of backends, which is great for users and has been great to consolidate the important logic, but it may not be sustainable long term for paradigm shifts such as this.

I was also eventually hoping to align the core logic and settings with quart-session.

My overarching concern is to keep core logic and settings of flask-session / quart-session within the close watch of the pallets team while being open to somewhat interchangeable backends, how that is achieved is definitely open to interpretation

My secondary concern would just be that we don't reinvent redis-py within flask-session :)

[mortensi]

Thanks for your prompt answer, @Lxstr.

Your ideas and scenarios make sense, but I need to determine the best way forward at this time.

1. A Redis-only Flask extension would make sense. It would grant the liberty to model the session and index it as desired, introduce expiration on hash fields, etc. However, how this would fit into the Pallet's view is certainly a different discussion. How can I start such a discussion and where?
2. A change in the current flask session needs to consider user experience, backward compatibility, and consistency with other backends. A configuration could be introduced to model the session as a hash and introduce more commands for session management. But again, consistency with other backends needs to be considered.

Finally, porting the same strategy and work to Quart makes a lot of sense.

We'll take some time to analyze the situation and try to understand what fits the long-term view of the Pallets team. I will post my progress here.