Add support for caching non-GET requests

[j-f1]

For example, the GitHub GraphQL API requires a POST request. It would be nice to reuse the existing network functionality rather than having to manually do the request (and store it in the cache).

Since the GitHub API has the same URL even as the query changes, the existing URL-based keying mechanism does not work if you want to do more than one GitHub API request on a website. Would it be possible to (optionally?) add support for serializing the body of the request (including headers and payload) in some stable manner and adding that to the hash key (maybe by doing a sha256 of it or similar?)

[petermekhaeil]

Here is a workaround until a feature is implemented to solve this. Add a query string to the end of the url containing something that is unique, eg the request body:

await EleventyFetch(`https://api.github.com/graphql?__query=${body}`

[pdehaan]

I believe POST requests are supported if you pass some custom fetchOptions (see example in 11ty docs; plus node-fetch's fetch options docs):

const EleventyFetch = require("@11ty/eleventy-fetch");

module.exports = async function() {
  const url = "https://httpbin.org/post#withData";

  return EleventyFetch(url, {
    duration: "1d",
    type: "json",
    fetchOptions: {
      method: "POST",
      body: JSON.stringify({name: "PeTeR"}),
    }
  });
};

But yes, if you are doing a lot of POSTing to the same endpoint, I think you'd need to use suitably unique URLs to bypass unwanted caching. Note the goofy #withData slug in the url above.

[groenroos]

@pdehaan's trick does work, but with the caveat that cache seems to work based off of the URL only.

So if you do multiple requests to the same URL but with different POST values (i.e. fetching multiple pages of a paginated API endpoint, with the page / cursor ID passed in POST), Fetch will treat these as the same request, and load the second one from cache.

We got around it by adding a hash that's unique to each request, i.e.;

async function fetchPage(pageId = 1) {
	const data = await EleventyFetch(`https://www.example.com/api#${pageId}`, {
		duration: '1d',
		type: 'json',
		fetchOptions: {
			method: 'POST',
			body: JSON.stringify({ page: pageId }),
		},
	});

	//...

	if (data.nextPage) {
		await fetchPage(data.nextPage);
	}
}

We found hash to be more reliable than a ? query string, as the latter can lead to a rejected request by some particularly picky APIs.

But ultimately I think Eleventy Fetch should automatically include the contents of fetchOptions.body as part of the hash generation, so this trick isn't necessary.

[zachleat]

Shipping with v5.