3 posts tagged with "Caching"

Every GraphQL client eventually has to pick between two HTTP methods, and both come with a problem attached. GET is safe and cacheable, but it puts the whole document into the URL. POST carries the document in a body, but HTTP has to assume that every POST might change something, so caches and retry logic stay away from it. In June 2026 the IETF published RFC 10008, which defines a third option: QUERY, a method that carries a body like POST and is safe and idempotent like GET. That description also fits a GraphQL query operation very closely.

Here's a sentence that should terrify anyone running a GraphQL API in production: "Our iOS app sends arbitrary query strings to our server, and we just trust them." You wouldn't let your web app send raw SQL. You wouldn't let a mobile client dictate the shape of a REST response. Yet for some reason, we've collectively decided it's fine to let clients write GraphQL queries of any depth, width, and cost, and we'll just sort it out at runtime with complexity analysis and rate limits. Persisted documents are how mature GraphQL teams fix this, and in 2026 there's finally enough consensus to do it properly.

"Just add caching" they said. "It'll be easy" they said. Three weeks later, I emerged from my cave with bloodshot eyes and a newfound respect for cache invalidation. This is my story.