Ask Remix: what's the best way to cache JSON responses from 3rd party API?

[emadabdulrahim]

I'm over-engineering re-writing my website in remix and using NotionAPI as my CMS. I noticed the latency with NotionAPI is high (usually > 500ms) and I also don't want to potentially get rate limited. SSG is usually the answer for such problems since I'd only hit the CMS API on build.

Possible cache layers:

1. Write the JSON responses from notion to disk? Not possible since Vercel doesn't allow cloud functions to write files.
2. Use a DB as cache layer? I've currently implemented an MVP with supabase and it seems to work well, although Supabase isn't that much faster (still hit 400ms-800ms)
3. Use something like Redis? Never used it before
4. Use Cloudflare KV storage? That might work. Values have 64k limitation, which is fine. I haven't used it before though.

Question

What would Remix folks suggest I do to cache my NotionAPI response so I don't hit their API every time a user visits my site?

Thanks!

[sergiodxa]

You could cache the whole loader response with Cache Control in the CDN, or the html for the initial document request.

[ccssmnn]

@Adam-Collier Manually resetting the cache is a feature that the CDN needs to provide. An example: Vercel resets all cached responses on a deploy docs. My Remix site needs less than a Minute to deploy, so triggering a Vercel deploy hook on content updates would do the job here. They are working on APIs for more selective cache invalidation.

[Adam-Collier]

@ccssmnn looking at the page you linked they do mention:
When the CDN receives a request with Pragma: no-cache (such as when the browser devtools are open), it will revalidate any stale resource synchronously, instead of in the background..
Does this mean we could possibly use Pragma: no-cache for this?

[ccssmnn]

I'm not quite sure what your goal is. As of now we can:

• Serve fresh content (no cache)
• Serve semi fresh content (stale-while-revalidate)
• Serve old content until we redeploy (cache forever)

If your revalidation period is small, you could just update the content, hit each route yourself and then the following requests will get fresh content. Or when caching forever, you update your content and hit the redeploy-hook, which purges the cache.

Pragma: no-cache should only work if the content is stale, if I'm getting it right. Instead of hitting a route and having fresh content on the second request, you will hit the route and have fresh content immediately, which is not really a benefit.

If your content is not stale, you should still get the "old" data from the cache.

[Adam-Collier]

To add some context I have some admin routes where I can add, edit and delete content (which is stored in a database). Let's take a post page as an example, the content is being cached with stale-while-revalidate so the pages stay quick without having to hit the database on every request.

I want to be able to:

• Edit the post content in the admin
• Save the new content to the database
• Redirect to the updated page showing the updated content

As it stands because of the stale-while-revalidate cache-control headers the old content is being served until I refresh the page after redirecting.

So my thinking here is I either need to:

• Find a way to invalidate the cache
• Somehow trigger a "rebuild" of the page before the redirect so the updated content is already there

[ccssmnn]

A third option could be to make the database fast and close to your server to always serve fresh data. E.g. Cloudflare KV or Fly.io KeyDB / PostgreSQL Clusters