I dont understand what the use case is for this.
If I have a front end, I would hope that the formated response is what were caching. Be that HTML or JSON.
If I cant read from that cache then I should be reading from fresh data all together? right?
If I have a front end, I would hope that the formated response is what were caching. Be that HTML or JSON.
If I cant read from that cache then I should be reading from fresh data all together? right?
It (Redis/Memcache caching) adds a huge amount of complexity to your application, and the risk of defects is very, very real.
ReadySet basically gives you a magic "stick this thing between your database and application and we'll do the caching for you." It totally eliminates a time consuming and error-prone part of your application.
If you want to, they go into details here: https://blog.readyset.io/dont-use-kv-stores/
After an initial query seen by their proxy, you can configure all future queries of the same kind to be pre-computed.
So I think it makes more sense to think of it like an auto-updating materialized view available with the click of a button rather than a cache.
There are some more under-the hood details here: https://docs.readyset.io/concepts/overview#how-does-readyset...
Efective Cache: Request -> (less)work -> cache
This Product: Request -> work -> work.. -> query/cache
I understand the concept of caching at a boundary layer. I fail to see the point of cache at THIS boundary layer. You have all the problems of a cache with fewer benefits (you're not going to fix a thundering Hurd at this level).
No you don't. You have next to none of the problems of a cache (especially as you directly have to opt-in individual queries to it) like cache invalidation, etc., with all the benefits. It's about as free as performance benefits can be (from a implementations standpoint).
I understand that for many use-cases caching at the response level may be preferable, but there are also many use-cases that are read-heavy but also involve a lot of computed values that are updated and have to be recomputed regularly, where this dataflow-based approach has been shown to be one of the least compute intensive and efficient solutions.
Yes after all the data + work/compute
>> there are also many use-cases that are read-heavy but also involve a lot of computed values that are updated and have to be recomputed regularly, where this dataflow-based approach has been shown to be one of the least compute intensive and efficient solutions.
From a comp sci, from a programing, from an engineering perspective I get this. But at the end of the day those are just the hammers and nails of the business. I am wondering where the actual, in production use case, with business need requires this. I can think of a dozen technical fuck ups where this solution is appealing but that's just stacking irresponsibly...