3 ms·

Good work! What was it about this problem that made you need Compute@Edge rather than the standard Fastly/Varnish VCL-backed caching? If you tried that route,

• gnz00 5y ago
  It's been awhile but IIRC you can't inspect the body on a POST request using Varnish. Either that or any real compute in Varnish gets super gnarly. I also think Fastly has a distributed K/V for state storage that you can access if you're using their new compute.
  • timsuchanek 5y ago
    That is correct, you need to first transform the POST request into something Fastly can cache. They don't have a K/V Store besides the edge dictionaries with max 8kb value size yet, but I've heard something is coming...
    • gnz00 5y ago
      Ah cool, thanks for the update. I haven't looked at their stuff in over a year. Congrats on the launch, looks really slick.
• timsuchanek 5y ago
  Good question pbowyer! We actually do a bunch of GraphQL parsing / calculations in the Compute@Edge layer. So without that, we would not be able to provide our current features. We also support a feature we call "scopes" - where we both support cookies and headers in the "Vary" header so you can cache user-specific data only for the user with a specific "Authorization" header for example. In order to support scopes with cookies, we needed Compute@Edge and could not make that work with VCL on its own. But believe me - we tried. Our first version was actually mostly built on top of VCL.