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.
Session Storage
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.
For example:
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
job. redis supports TTLs for individual keys
which makes it very easy to drop stale sessions.
Cache Store
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
favour 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.
Action Cable
Action Cable
offers websocket pub/sub support with a direct dependency on redis.
See a previous post for details.
Active Job
Finally, for background processing of active jobs the sidekiq
adapter is simple and efficient. It also depends on redis.
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.
Sidekiq has a great community, enterprise support and lots of plugins and the ability to schedule jobs.
π€ is also working on a new language-agnostic, persistent background job system that also depends on redis.
Conclusion
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 Redis
- 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.