Passiday
Passiday

Reputation: 8075

Efficient session variable server-side caching with Python+Flask

Scenario:

Flask.session and limitations? (Cookies)

Database is too much?

Question

Perhaps that could be a memory-based solution, but I am worried that different Flask app requests could be executed at different threads that would not share the memory-stored session data, or cause conflicts in case of simultaneous reading-writing.

Upvotes: 9

Views: 4605

Answers (2)

imbr
imbr

Reputation: 7672

You are on the right track.
Flask.session is not for sensitive or long-term data. For those or "if the data is too big" your only option is a database.
But in-between session cookie and database: for server-side session data you should use:

Flask-Session

An extension for Flask that adds support for server-side sessions. In simple terms if you set up a session, the session variable is available in all your routes and it behaves like a dictionary. The data stored in this dictionary is individual for each connecting client.

Store

Supports many storage-types like Redis, Memcached, MongoDB, CacheLib, SQLAlchemy and DynamoDB. They must be properly configured (database tc.) before use.

For development or very simple scenarios CacheLib with 'filesystem' is a amazing option.

CacheLib 'filesystem'

Doesn't need any additonal package (client-library).
Simple set app.config['SESSION_TYPE'] = 'filesystem'

from flask import Flask, session
from flask_session import Session

app = Flask(__name__)

app.config['SESSION_TYPE'] = 'filesystem'
Session(app)

@app.route('/set/')
def set():
    session['key'] = 'value'
    return 'ok'

@app.route('/get/')
def get():
    return session.get('key', 'not set')

Upvotes: 3

Javier
Javier

Reputation: 2776

Your instinct is correct, it's probably not the way to do it.

Session data should only be ephemeral information that is not too troublesome to lose and recreate. For example, the user will just have to login again to restore it.

Configuration data or anything else that's necessary on the server and that must survive a logout is not part of the session and should be stored in a DB.

Now, if you really need to easily keep this information client-side and it's not too much of a problem if it's lost, then use a session cookie for logged in/out state and a permanent cookie with a long lifespan for the rest of the configuration information.

If the information is too much size-wise, then the only option I can think of is to store the data, other than the logged in/out state, in a DB.

Upvotes: 2

Related Questions