Hi, @bigfootjon
Recently, I analyzed the source code of the session. I think the entire session and its related components can be divided into two parts: 1. Core interface, 2. Upper module. Among them, the core interface is concentrated in django.contrib.sessions.backends.base.SessionBase and each of its subclass; the upper module includes any other functions and classes that call the core interface, such as middlewares and any other functions and classes that call request.session.
I only analyzed the source code of SessionBase in detail, that is, most of the code of the core interface described above.
I drew a call graph of the various interfaces in the SessionBase. Most of its interfaces are related to I/O, because these interfaces directly or indirectly call one or more of exists, create, save, delete and load. And exists, create, save, delete and load must be functions related to I/O.
In addition, there is no clear_expired function on the call graph, because this function is usually not called in business logic, it is usually called in batch tasks that run periodically.
I think session needs to be changed to natively support asynchronous context, because session is one of the core parts of auth and is the most frequently called part. But I also think that the session part is more complicated, and there are many APIs, so we need to plan carefully.
I generally think we can start with the core interface. The first step is to use sync_to_async to wrap the synchronous function, which can easily expose the asynchronous interface to the outside world, and can also realize the decoupling of the core interface and the upper module. In the second step, we can transform each module according to the priority, and the transformation process of each module should not affect each other.
I hope to hear your opinion, and I attach the call graph of SessionBase here, I hope it will be useful to you.
