Since the inception of rails it was apparent from the beginning the
importance of the relational database. At that time
mysql got all the
love but these days it seems like
postgresql seems to be favoured by
the rails community.
In this post, I want to share why I think
redis has now become a core
component of the rails architecture.
The default session storage is the cookie store. Which works well out of the box but can pose different types of client side attacks that are a little more difficult to accomplish with server side storage. It also has restrictions on the amount of data you can store in session due to limits on cookie size. Adding too much data to session is an anti-pattern but there are times when need to get around the cookie size limit.
The active record session storage works well with your relational database but does requires regular cleanup of stale sessions.
mysql> select count(*) from sessions where updated_at < '2019-02-01'; +----------+ | count(*) | +----------+ | 854463 | +----------+ 1 row in set (0.51 sec) mysql> select count(*) from sessions; +----------+ | count(*) | +----------+ | 943406 | +----------+ 1 row in set (0.28 sec)
For easy session storage I think the redis session store is the best
choice. It’s a server side session storage and the expired sessions can
be cleaned out automatically without having to run rake tasks via a cron
redis supports TTLs for individual keys
which makes it very easy to drop stale sessions.
The default rails cache store is the file store. This works good enough when you have a single rails host but as soon as you add a second host your cache will get out of sync. This is where having a distributed cache is necessary to ensure that all nodes are using the same cache entries. If a cache entry needs to expire, the distributed cache ensures that every node that uses it does not use a stale cache value.
memcached used to be the standard in this area but nowadays I
redis. Redis appears to have better support and better at it’s
memory usage and release.
redis has the ability to dump to disk.
redis supports clustering.
offers websocket pub/sub support with a direct dependency on
See a previous post for details.
Finally, for background processing of active jobs the sidekiq
adapter is simple and efficient. It also depends on
I had a chance to meet 🎤 🍐🐷 a few years ago at RailsConf and he was very friendly and able to answer all my questions. I also like the opportunity to support an independent developer.
🎤 is also working on a new language-agnostic, persistent background job system that also depends on redis.
Adding more components to your architecture requires additional
knowledge of those components. For small teams I think it’s best to
limit the amount of new architectural components that you need to upkeep
and manage. I think adding
redis to your rails architecture is almost
as essential as having a relational database and provides a lot of
additional value over alternatives.
Reasons to use
- Session: Redis
- Caching: Redis
- Active Job: Redis
- Action Cable: Redis
Many components in rails now either have a strict dependency on or work best with redis.