38 posts tagged with "GraphQL"

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.

GraphQL specification editions used to arrive every few years: 2016, 2018, 2021. The September 2025 edition ended a gap of almost four years, and the September 2026 edition follows twelve months later. It is a smaller release than September 2025, which ratified @oneOf and schema coordinates. Its changes are careful ones that matter more than their size suggests, including a new definition of what fragments are for. That one made us look again at a post we published in 2025.

Send a GraphQL server a document with a typo in it, and for most of the last decade the answer came back as 200 OK. Ask for a field that does not exist, and you got 200 OK. Run a query that half worked, and you got 200 OK again, with the bad news inside the body. Load balancers, CDNs and dashboards do not read response bodies, so to them all three requests looked like successes. The GraphQL over HTTP specification is getting its first edition, named September 2026, and its main job is to let the status code tell the truth again without breaking the clients that learned to ignore it.

For most GraphQL developers, "federation" has meant Apollo Federation: a set of directives, a _entities field in every service, and a router that stitches it all together. Other vendors built gateways that are compatible with Apollo's design. Under the GraphQL Foundation, a working group has worked since 2022 on a vendor-neutral specification for the same job. On 21 September 2026 that specification got a new name. The Composite Schemas specification is now the GraphQL Federation specification.

A movie has a title and a rating. The rating service is down, so the rating field fails, and the title loaded without any problem. Under today's GraphQL rules, the client may still lose the whole movie, because one failed field can take its parent object with it. For years, the community answer has been "make more fields nullable". The proposal now moving through the GraphQL working group answers differently: let the client say, in each request, how far an error is allowed to spread. It is called onError, and in August 2026 the working group also decided what happens to every client that does not send it.

Every GraphQL talk eventually arrives at the same slide: "GraphQL doesn't need versioning." The audience nods. The speaker looks pleased. And somewhere, a team is about to learn the hard way that "doesn't need versioning" is a bedtime story we tell each other to avoid discussing the actual versioning strategy GraphQL requires. Spoiler: there is one. It's just embedded into the schema instead of the URL.

Every few years, the API wars get a new challenger. REST fought GraphQL. GraphQL fought gRPC. Now GraphQL is fighting tRPC, and a loud corner of the TypeScript community insists we can finally delete GraphQL from the stack forever. They're half right, half wrong, and half neither (yes, that's 150%; API debates don't always add up). Here's the honest comparison, the scenarios where each genuinely wins, and a reminder that this debate is only meaningful for a specific slice of the industry.

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.

Every GraphQL tutorial on subscriptions starts the same way: "First, upgrade your HTTP connection to a WebSocket." Then comes the lecture on graphql-ws, the Sec-WebSocket-Protocol header, ping/pong frames, and the eight ways your connection can die without explanation. You nod through it, ship your subscription, and a month later a customer calls because their corporate firewall blocks wss:// and nothing works. Welcome to 2026, where GraphQL over Server-Sent Events has quietly become the pragmatic alternative that just works.

For a decade, GraphQL responses came back as one lump. You asked for a page, you waited for every field to resolve, then the server wrapped it up and sent it over the wire in one envelope. Fast fields waited for slow fields. The whole response moved at the speed of its slowest resolver. Then @defer and @stream arrived to fix exactly that. They've been maturing as a proposal for several years - deliberately, because getting incremental delivery right is genuinely hard - and they're now real enough to use with modern clients and servers. The open question is when they pay off, and both camps have a case.