Caching of external api calls from within SvelteKit

Describe the problem

The following situation:

On my new personal website, I wanted to call the dev.to api to show the links in the blog section.

I made it work by adding an json endpoint and including it in the SSR.

The problem I see is that with every request to /blog the dev.to api will be called again (with a lot of traffic the might block me).

So if I could cache the response for about 1 hour, I could drastically reduce the api calls even when a lot of traffic hits.

As far as I understand it cloudflare has some functionallity like that.

• Cloudflare docs

• Vercel docs

Describe the proposed solution

I would be nice to have something similar to cloudflare, where we use cache controll on the request/response.

Alternatives considered

No response

Importance

nice to have

Additional Information

No response

[Rich-Harris]

You have a variety of options, depending on exactly what behaviour you want. You can return a cache-control header from your endpoint…

export async function get() {
  const res = await fetch(`https://dev.to/api/articles?username=dreitzner`);

  return {
    headers: {
      'cache-control': 'public, max-age=3600'
    },
    body: {
      articles: await res.json()
    }
  }
}

…or, if you wanted to respect the original cache headers (probably not, since it looks like the dev.to API uses public, no-cache), and you don’t need to munge the response in any way, you can just proxy it…

export function get() {
  return fetch(`https://dev.to/api/articles?username=dreitzner`);
}

…or, since the API doesn’t need a private key, you could fetch the data in load and use maxage, which will hit the API during SSR but then cache the rendered page, and hit the API directly for client-side navigation rather than going via your endpoint (which will result in more API hits if people navigate between blog posts, but from many IP addresses):

<script context="module">
  export async function load({ fetch }) {
    const res = await fetch(`https://dev.to/api/articles?username=dreitzner`);

    return {
      maxage: 3600,
      props: {
        articles: await res.json()
      }
    };
  }
</script>

Personally I’d probably opt for the first one, since it means you have the opportunity to slim down the response to just the bits you need. Though I’d typically pick a much lower maxage (a few minutes at most, rather than an hour), so that you can handle getting slashdotted (oops, might have just aged myself) while avoiding stale content.

[Rich-Harris]

3. if I’m not mistaken cache headers will only be honored by the browser and not inside svelte-kit/serverless function, that would result in calling the api once for each user

It depends. Cache-Control: max-age=3600 will be respected by browsers, but Cache-Control: public, max-age=3600 will be respected by CDNs as well — in other words, if you have a CDN in front of your app, then only the first request in a ten minute window should hit the origin server. (Subsequent requests will have an additional Age header, so that a response served 7 minutes into the window will only be cached by the browser for the remaining 3 minutes.)

I like the idea of something writing out a static file and then all client-side pages access this file, and periodically this file gets rebuilt as data changes/goes stale.

I just learned about the “Incremental Static Regeneration” ergonomics in Next.js and they truly are on the next level.

Yes, we definitely want to adopt ISR (particularly on-demand ISR, where revalidation is triggered by a webhook notifying of a change, rather than requests). It’s something we hope to implement after 1.0: https://github.com/sveltejs/kit/issues/661