Recommended caching strategies?

[mgburns]

I'm working on a universal React application that requires multiple requests on page load and am investigating caching strategies to help performance and alleviate the pressure on our API request limit. I've seen #83 and know that this SDK does not handle caching out-of-the-box.

My initial thought was to create a caching proxy layer on our application server (similar to https://github.com/felixjung/contentful-proxy), but I can't figure out a way to make that work with this SDK as the baseURL is not exposed in a way that lets me modify the path.

For example, my proxy lives at https://my-server.com/api/contentful/, so a request to https://my-server.com/api/contentful/spaces/123 caches the response for https://cdn.contentful.com/spaces/123.

Has anyone else attempted something like this? Are their other approaches that others have had success with?

[Khaledgarbaya]

hi @mgburns,
You can pass in a host when creating the client.

import {createClient} from 'contentful'
const client = createClient({
  space: '<space-id>',
  accessToken: '<token>',
  host: 'mycacheproxy.com'
})

the SDK will then make http request against your proxy. for e.g when requesting an entry the expected endpoint will be https://mycacheproxy.com/spaces/<space-id>/entries/<entry-id> and so on.
Also if your proxy is not https you can add insecure : false when creating the client

here is a list of all possible configs that you can pass to the client.
https://contentful.github.io/contentful.js/contentful/4.4.4/contentful.html#.createClient

[zcei]

From a design perspective I wouldn't cache calls to our CDN on your end, as you would need to implement all the things we're actually already doing for you, like availability, edge caching, etc.

It's important to mention here what counts towards the limits and I'm citing the docs here:

There are no limits enforced on requests that hit our CDN cache, i.e. the request doesn't count towards your rate limit and you can make an unlimited amount of cache hits.

So if you don't hit 78 unique uncached URIs a second, you're good to go. If you do, there might be better counter-measurements than caching it yourself.
The reason for the space cache to be invalidated is any change to the records in there. So if you edit so quickly that you hit the rate limit, your self-made reverse proxy would still serve outdated content, defeating the whole purpose of Contentful's Delivery API

[mgburns]

@Khaledgarbaya Thanks for the quick response! I was hoping I could mount it at a different base path, but that's a good workaround and I've confirmed it does work as intended.

@zcei Good point re: CDN functionality that is sacrificed with this approach. That said, we're building a universal application wherein the initial fetch to Contentful always occurs server-side, and as such doesn't really benefit from the CDN anyways.

I'm not as concerned about the rate limiting as I am about the plan limits as it impacts cost for our client (e.g. 250,000 API call per month, +$0.10 for 1,000 more).

I had reached out to the Contentful support team as I noticed that most of my requests were coming back as 304 Not Modified, and was hopeful that these weren't count against the plan limit but that does not appear to be the case:

As a rule of thumb, every request that hits our API endpoints will be counted towards your plan limits, including those returned as 304.

That being the case, any caching that is implemented in the level of your application will surely help you decrease the overall amount of utilized requests.

[zcei]

I noticed that most of my requests were coming back as 304 Not Modified

Just a guess, as I have no clue about your setup:
Instead of pulling from our APIs that often without actual changes, let them push changes to you via Webhooks / Sync API.

[mgburns]

@zcei Good thought! That's a potential solution, but it would be a much heavier lift for us than a simple caching proxy with a short TTL. We would have to rewrite all application code interfacing with the Contentful SDK, and it also introduces additional points of failure (webhook sending, receiving, and the sync operation). Are you aware of any open source projects implementing this pattern?

[zcei]

Nope, haven't had the use-case by now.

To just ease the burden of burst requests, a cache would be most simple indeed.

[mgburns]

Thank you both for your responses!