Great question! The quick answer is technically no, but almost certainly you'll turn it on.
Most SR devs will have caching enabled, because if you think about it, to not have it enabled means that you are hiding potential errors and undesirable behaviours that only manifest in production. The decision to turn off caching by default in Rails is one that has - in my opinion - done a lot of harm while creating a near-superstition that turning it on is somehow problematic or leaving the golden path.
I promise you that I can say confidently that turning on caching just means that you're able to use caching, including the low-level Rails.cache, which used to be a go-to for power users... at least until Kredis was released. If you turn on caching and don't use caching, it is exactly the same as not turning it on.
The bigger context here is really Redis and cookie-based sessions. Over time, it's become increasingly clear that Redis is one of the most powerful tools in our stack. If you're working with ActionCable, you 100% want to use Redis as your subscription manager (in config/cable.yml). Not only is it great for caching, the redis-session-store gem is vastly superior to storing sessions in Postgres - which Heroku users report can cause strange, intermittent logouts when Devise is in the picture. When you factor in the raw opportunity power of Kredis, doubling down on Redis becomes a no-brainer.
The real question, then, is why SR doesn't support cookie-based sessions. Websockets cannot write secure cookies, which get set during HTTP responses. The request that is available in an ActionCable Connection is the request that was used to upgrade the HTTP connection to WS. This means that when using cookie sessions inside the Connection, the session accessor that is provided by ActionDispatch is a cold snapshot. You can read values that were set before the WS connection was established, but newer changes are not available and worse, attempts to write to the session appear to succeed but are not committed to the real user session.
When all of this is considered, we decided to double-down, lead by example and march our developers to a better place: Redis-based caching enabled, Redis-backed sessions, using Kredis instead of the session object because it's 100x more useful, using Redis as the subscription adapter, using Sidekiq-backed ActiveJobs. All of these things make building asynch UIs with tools like CableReady smooth as butter.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great question! The quick answer is technically no, but almost certainly you'll turn it on.
Most SR devs will have caching enabled, because if you think about it, to not have it enabled means that you are hiding potential errors and undesirable behaviours that only manifest in production. The decision to turn off caching by default in Rails is one that has - in my opinion - done a lot of harm while creating a near-superstition that turning it on is somehow problematic or leaving the golden path.
I promise you that I can say confidently that turning on caching just means that you're able to use caching, including the low-level
Rails.cache, which used to be a go-to for power users... at least until Kredis was released. If you turn on caching and don't use caching, it is exactly the same as not turning it on.The bigger context here is really Redis and cookie-based sessions. Over time, it's become increasingly clear that Redis is one of the most powerful tools in our stack. If you're working with ActionCable, you 100% want to use Redis as your subscription manager (in
config/cable.yml). Not only is it great for caching, theredis-session-storegem is vastly superior to storing sessions in Postgres - which Heroku users report can cause strange, intermittent logouts when Devise is in the picture. When you factor in the raw opportunity power of Kredis, doubling down on Redis becomes a no-brainer.The real question, then, is why SR doesn't support cookie-based sessions. Websockets cannot write secure cookies, which get set during HTTP responses. The
requestthat is available in an ActionCable Connection is the request that was used to upgrade the HTTP connection to WS. This means that when using cookie sessions inside the Connection, thesessionaccessor that is provided by ActionDispatch is a cold snapshot. You can read values that were set before the WS connection was established, but newer changes are not available and worse, attempts to write to thesessionappear to succeed but are not committed to the real user session.When all of this is considered, we decided to double-down, lead by example and march our developers to a better place: Redis-based caching enabled, Redis-backed sessions, using Kredis instead of the
sessionobject because it's 100x more useful, using Redis as the subscription adapter, using Sidekiq-backed ActiveJobs. All of these things make building asynch UIs with tools like CableReady smooth as butter.