- A very common use case for Redis is session storage.
I assume that you basically know
what user sessions are in a web application context.
You might not have Node.jsd but in our shopping application,
we do already utilize sessions to some degree.
For instance, here in my user admin route,
when we scroll down a little bit,
you see that I'm here writing into
request session dot messages,
and I'm using this to implement user notification.
So these are the notifications that you see in the front end
and I'm using sessions,
because then the notification survives the redirect
that we see in line 37.
Also, if we scroll further down,
we have this impersonate route.
In there, I'm writing the user ID that was selected
into the session.
Right now, we are doing nothing with it,
but we will add some logic to this later.
Let's see how the session management
is right now implemented for that.
I open app.js, and there you see in line four
that I bring in express sessions.
So this is the default session module by express,
and if I scroll down, you see that in line 18,
I'm just adding the session middle there
with some configuration arguments, and that's it basically.
In this default configuration express,
we'll use the applications memory
to store session information in there,
and this is fine during development
but it has some major shortcomings.
So here, we have a node application,
and it has some memory assigned to it,
and those white boxes are user sessions
that are stored in memory.
If a user accesses decide and a session
is created for the user, a new box is created,
and when the user comes back,
they come with some cookie, with some session ID,
and this session that is then used
to find the session in memory again,
and assign it to the user.
So that's all fine and everything will work great.
Now in production, it's very common
to create multiple instances of a node.js application.
For instance with the node.js custom module,
or to even run node.js on different machines
or accompany these parts.
Now each of these node applications
has their own memory segment,
and a user can randomly end up on the one or the other
instance of this node application.
So this means that the session that exists on one instance
won't exist on the other instance.
So the user would lose the session.
This means if we, for instance, have a shopping basket,
the user adds something to the basket,
but when the page is reloaded,
they end up on a different instance,
and the basket is empty again.
So this is, of course, something we want to avoid,
and now Redis comes into play,
because Redis is available to all node.js applications
on one machine, and it also stores the data in memory.
So it comes basically with best of both worlds.
So it's in memory,
but still available to all node.js instances,
and the best part is that Redis also supports clustering.
This means you can connect Redis instances
on different machines, and the data will then replicate it.
This means your session information is then available
to each instance on each machine,
and this is exactly what we want to achieve.