3 ms·

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 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?

tutfbhuf 3y ago
Sometimes, you have to deal with closed-source and legacy software for which there is no sufficient support in the application. This proxy can help boost the performance of such applications.
jerrygenser 3y ago
What if it's a backend service that is not exposed to a frontend that receives html or Json. E.g a task that takes an id and a operation name and needs to fetch from the database a bunch of data to process.
- marceloaltmann 3y ago
  You will add readyset between your backend and database in order to cache the data you fetch from db.
  - jerrygenser 3y ago
    I'm answering the comment above mine that is asking for a user case. I'm saying that my use case is an example where json/html caching is not sufficient. 100% agree with you.
hobofan 3y ago
You are reading from "fresh" (though only eventually consistent) data. For many public facing queries that's enough. 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-work-under-the-hood https://docs.readyset.io/concepts/overview#how-does-readyset...
- zer00eyz 3y ago
  Normal request: Request -> work -> work.. -> query/db 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).
  - hobofan 3y ago
    > You have all the problems of a cache with fewer benefits 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.
    - zer00eyz 3y ago
      >> I understand that for many use-cases caching at the response level may be preferable 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...
jitl 3y ago
How do you invalidate your cache? Is it complicated? What about search queries with many filters? What about responses that are unique per user? What about common queries that are shared between multiple views, do you constantly re-run those as your response cache is invalidated?
- marceloaltmann 3y ago
  Caches are never invalidated. Readyset uses CDC to receive updates from PostgreSQL/MySQL and update the cache entries. No invalidation required. The price you pay is eventually consistent data, which is already true if you use any async replication like readyset does.
  - jitl 3y ago
    That’s how ReadySet works, I’m asking the grandparent (rhetorically) how their own method of caching works for them
gwbas1c 3y ago
Ever add (or inherit) the server-side part of an application that uses Redis or Memcache? The data is denormalized: When you do an update/insert/delete into the SQL side of things, you need to do a corresponding change in Redis / Memcache. All of your queries end up being something like: Try Redis/Memcache, if the data isn't present, query the database and insert into Redis/Memcache. 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/ https://blog.readyset.io/dont-use-kv-stores/

tutfbhuf 3y ago

Sometimes, you have to deal with closed-source and legacy software for which there is no sufficient support in the application. This proxy can help boost the performance of such applications.

jerrygenser 3y ago

What if it's a backend service that is not exposed to a frontend that receives html or Json. E.g a task that takes an id and a operation name and needs to fetch from the database a bunch of data to process.

marceloaltmann 3y ago
You will add readyset between your backend and database in order to cache the data you fetch from db.
- jerrygenser 3y ago
  I'm answering the comment above mine that is asking for a user case. I'm saying that my use case is an example where json/html caching is not sufficient. 100% agree with you.

hobofan 3y ago

You are reading from "fresh" (though only eventually consistent) data. For many public facing queries that's enough. 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-work-under-the-hood https://docs.readyset.io/concepts/overview#how-does-readyset...

zer00eyz 3y ago
Normal request: Request -> work -> work.. -> query/db 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).
- hobofan 3y ago
  > You have all the problems of a cache with fewer benefits 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.
  - zer00eyz 3y ago
    >> I understand that for many use-cases caching at the response level may be preferable 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...

jitl 3y ago

How do you invalidate your cache? Is it complicated? What about search queries with many filters? What about responses that are unique per user? What about common queries that are shared between multiple views, do you constantly re-run those as your response cache is invalidated?

marceloaltmann 3y ago
Caches are never invalidated. Readyset uses CDC to receive updates from PostgreSQL/MySQL and update the cache entries. No invalidation required. The price you pay is eventually consistent data, which is already true if you use any async replication like readyset does.
- jitl 3y ago
  That’s how ReadySet works, I’m asking the grandparent (rhetorically) how their own method of caching works for them

gwbas1c 3y ago

Ever add (or inherit) the server-side part of an application that uses Redis or Memcache? The data is denormalized: When you do an update/insert/delete into the SQL side of things, you need to do a corresponding change in Redis / Memcache. All of your queries end up being something like: Try Redis/Memcache, if the data isn't present, query the database and insert into Redis/Memcache. 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/ https://blog.readyset.io/dont-use-kv-stores/