Level 104
They will be cached wherever you decide to cache them.
2 likes
May 4, 2022
3
Level 2
API & Database Caching in Laravel Question
I am building two websites. Site A will hold all of the product data and content and act as a CMS. No "customers" will ever see site A. Site B will load data and content from Site A using API requests. With a preference for caching as much as possible, my question is this:
When Site B requests data from Site A, will the transactions only be cached in the app for Site A? Or will they also be cached in Site B? In other words, would data returned from an API request get cached if it doesn't actually touch a database directly?
Please and thank you
Level 80
@jessycafrederick I’m struggling to follow your question if I’m honest.
Caching happens where ever you specify it to happen. There’s also different types of caches. Browser caches, client-side caching, server-side caching, etc.
First, I’d identify what actually needs caching, and then come up with a strategy based on that. Because if you just indiscriminately cache everything then you can end up having an adverse effect. As a rule of thumb, you should only cache things if they’re being requested frequently, or is resource-intensive to retrieve/calculate.
When Site B requests data from Site A, will the transactions only be cached in the app for Site A?
What transactions? Caching will only happen in Site A if you build caching in Site A.
Or will they also be cached in Site B?
Caching will only happen in Site B if you build caching in Site B.
In other words, would data returned from an API request get cached if it doesn't actually touch a database directly?
This statement is the one I’m struggling to make sense of the most. How would something get cached if you don’t actually retrieve it from the database? Where would you retrieve data from if not the database, and before it has been cached?
There’s probably two ways to go about caching here with a “headless” CMS like you’ve described:
-
Cache “expensive” queries in Site A. HTTP requests arrive at Site A, Site A returns data from cache. Site B just consumes the HTTP responses from Site A completely “dump” as to whether the data in the response has came directly from the database or the cache.
-
Create a proxy in Site B, if Site B is going to be making lots of duplicate requests in a short amount of time, and the data will not be changing as frequently as requests are being made. So instead of Site B making requests directly to Site A, it makes a request to a proxy within Site B that either lets the request out if it needs to, or can intercept the request and return its own cached response.
So say for example Site B needs to hit https://site-a.com/api/products multiple times a minute, but products aren’t actually being updated that frequently. Instead of wasting time going over the network, hitting Site A, and Site A serving the same response of cached products over and over again, Site B could instead just cache the first request for n seconds, and any subsequent requests just send back that cached response for any calls made within that window.
Hopefully this helps. Let me know if there’s anything I’ve missed though, or anything you need me to go over/more in depth on.
Level 2
@martinbean Thank you. I think you covered all of the permutations that were swirling in my head. I didn't want to say too much in case I was thinking about it incorrectly — I'm not a trained programmer and I learn as I go, which leaves conceptual gaps in my knowledge. This is the most thinking about caching I've ever done.
Most of the data changes VERY infrequently. It's in the database to make good use of Eloquent, to make search work better, and to make content bits reusable outside of their original context.
My intention was to cache the database requests at Site A and cache the returned data at Site B, too. Then I'd check for an existing cache item before requesting anything from Site A. I was thinking about how to handle "forgetting" specific cached elements and where in the code I might need to forget them.
The idea is to have all of the heavy lifting (processing data feeds, creating analytics reports, etc.) happen on Site A leaving Site B to quick and speedy, only touching Site A's database when truly necessary.
It sounds like I've got a plan, but I'm always grateful for additional feedback if I've said something troubling.
1 like
Please or to participate in this conversation.