5 ms·

What about caching in Ruby is complicated to you? It seems pretty simple to me. What production website doesn't cache? You make it sound like it's a Ruby-only

What about caching in Ruby is complicated to you? It seems pretty simple to me. What production website doesn't cache? You make it sound like it's a Ruby-only issue.

rubiquity 11y ago
Websites that are still fast without caching and don't need to?
- ishansharma 11y ago
  I'd be interested in seeings popular sites that don't use caching. Can you provide examples?
  - rubiquity 11y ago
    bleacherreport.com is on record for generating unique content on the fly per user.
    - cheald 11y ago
      From the bleacherreport.com source:  So much for that theory.
    - abritinthebay 11y ago
      I work at Bleacher Report. We use caching. Everywhere. As much as possible. We can probably do more. Just because we end up using that cached content to create a unique mix for each user doesn't mean that we don't cache. I think you misunderstand the process.
      - rubiquity 11y ago
        I stand corrected. This conference talk had me believe otherwise: https://www.youtube.com/watch?v=xT8vDHIvurs https://www.youtube.com/watch?v=xT8vDHIvurs
        abritinthebay 11y ago
        Michael's great, one of the smartest engineers I've worked with, but I don't think even he would say he meant to imply we don't use any caching at all. He's also mostly talking about our Elixir stack which is not our primary stack (though... we're hiring!). So it's a little bit of an edge case. There IS less caching involved in our Elixir stack though - due to how it functions - so maybe that's where the confusion arose.
swanson 11y ago
Caching involves adding generally untested code to your production environment. Caching can bring your production environment out of sync with your development environment. Caching introduces state between generally state-less requests - increasing the mental overhead of understanding why you are seeing certain behavior. Subtle bugs can result in disproportionately bad behavior (wrong cache key could accidentally show one user's private data to another user). I don't think you should never do caching - just that is is non-trivial, especially once you move past a 15min-blog use case.
- Bluestrike2 11y ago
  Caching makes things more complex, but unfortunately, that's the nature of the game and there's no escaping it. If you plan things out and break your caching strategy down into more manageable pieces, you'll be able to work out a way to make it work as a cohesive whole. It's really easy to just ignore caching until you're almost done with a project, only to be stuck in the painful position of trying to make it work with a shoehorn. Just thinking about the basics in the beginning will help make it a lot easier for you later on.
virtualwhys 11y ago
It's not that caching itself is complicated, but rather one more layer to keep track of/thing that could break. On the JVM, .NET, etc. statically compiled languages typically provide blazing performance, which allows you to selectively cache (i.e. where you really need it) vs. caching virtually everything because it's-just-so-damn-slow otherwise.
karmajunkie 11y ago
Plenty of them. Apps that are write heavy, and/or that have highly personalized, realtime, or secure data frequently abstain from caching altogether. Cache invalidation is hard to get right, and more importantly, its hard to keep right.

What about caching in Ruby is complicated to you? It seems pretty simple to me. What production website doesn't cache? You make it sound like it's a Ruby-only issue.

rubiquity 11y ago

Websites that are still fast without caching and don't need to?

ishansharma 11y ago
I'd be interested in seeings popular sites that don't use caching. Can you provide examples?
- rubiquity 11y ago
  bleacherreport.com is on record for generating unique content on the fly per user.
  - cheald 11y ago
    From the bleacherreport.com source:  So much for that theory.
  - abritinthebay 11y ago
    I work at Bleacher Report. We use caching. Everywhere. As much as possible. We can probably do more. Just because we end up using that cached content to create a unique mix for each user doesn't mean that we don't cache. I think you misunderstand the process.
    - rubiquity 11y ago
      I stand corrected. This conference talk had me believe otherwise: https://www.youtube.com/watch?v=xT8vDHIvurs https://www.youtube.com/watch?v=xT8vDHIvurs
      - abritinthebay 11y ago
        Michael's great, one of the smartest engineers I've worked with, but I don't think even he would say he meant to imply we don't use any caching at all. He's also mostly talking about our Elixir stack which is not our primary stack (though... we're hiring!). So it's a little bit of an edge case. There IS less caching involved in our Elixir stack though - due to how it functions - so maybe that's where the confusion arose.

swanson 11y ago

Caching involves adding generally untested code to your production environment. Caching can bring your production environment out of sync with your development environment. Caching introduces state between generally state-less requests - increasing the mental overhead of understanding why you are seeing certain behavior. Subtle bugs can result in disproportionately bad behavior (wrong cache key could accidentally show one user's private data to another user). I don't think you should never do caching - just that is is non-trivial, especially once you move past a 15min-blog use case.

Bluestrike2 11y ago
Caching makes things more complex, but unfortunately, that's the nature of the game and there's no escaping it. If you plan things out and break your caching strategy down into more manageable pieces, you'll be able to work out a way to make it work as a cohesive whole. It's really easy to just ignore caching until you're almost done with a project, only to be stuck in the painful position of trying to make it work with a shoehorn. Just thinking about the basics in the beginning will help make it a lot easier for you later on.

virtualwhys 11y ago

It's not that caching itself is complicated, but rather one more layer to keep track of/thing that could break. On the JVM, .NET, etc. statically compiled languages typically provide blazing performance, which allows you to selectively cache (i.e. where you really need it) vs. caching virtually everything because it's-just-so-damn-slow otherwise.

karmajunkie 11y ago

Plenty of them. Apps that are write heavy, and/or that have highly personalized, realtime, or secure data frequently abstain from caching altogether. Cache invalidation is hard to get right, and more importantly, its hard to keep right.