3 ms·
With a proper runtime, you don't bolt caching on, but rather implement it throughout the code base using both local cache state and shared network cache state.
by pifflesnort 14y ago
With a proper runtime, you don't bolt caching on, but rather implement it throughout the code base using both local cache state and shared network cache state. The end result is something simpler to implement, maintain, and deploy.
However, thanks to using faster systems, the bar at which you must pay the implementation and deployment costs for caching is much higher than that of someone that needs it just to achieve acceptable speeds at all.
- Tomte 14y agoI don't understand why you would want to implement HTTP caching in a language's runtime. Honestly, I don't even see where and how you could even do that.
- pifflesnort 14y agoYou don't implement HTTP caching, except in very specific cases. You cache generated data where you need it. This is 1) Easy to add later, 2) Doesn't sacrifice the flexibility of being able to recompose that data on-demand, and 3) Doesn't require a bunch of complex front-end infrastructure to support.
- Tomte 14y agoOf course "you don't implement caching". I think it was clear that I was talking about designing a cache-aware application. Cf. http://www.mnot.net/cache_docs/ http://www.mnot.net/cache_docs/.
- pifflesnort 14y agoYes, and I was talking about implementing caching of components used to compose the pages and API responses, not a full HTTP cache tier that has to be placed in front of your application.
- Tomte 14y agoOkay, then I misunderstood where you were getting at. My fault.