9 February 2019

rails πŸ’– redis

by mo


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.

πŸ’Ž