6 posts tagged with "Schema Design"

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.

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.

Two camps. One schema. Endless arguments on Twitter. Every Java GraphQL project, within the first week, has the same meeting: should we write the schema first in SDL, or should we write Java classes and let the schema fall out of them? Both camps are convinced the other is doing it wrong. Both are partially right. Here's the honest breakdown, the actual tradeoffs, and what the 2026 Java ecosystem looks like when you stop arguing and pick one.

Your GraphQL schema looked perfect on day one. Clean types. Tight enums. Non-null everything because you were sure those fields would always be there. Then requirements changed, a service went down, and your schema went from "elegant contract" to "active crime scene."

This is a post about evolving GraphQL schemas without making your clients hate you.

Null. The billion-dollar mistake. The void that stares back. In GraphQL, null isn't just a value - it's a lifestyle choice. Let's explore the surprisingly sensual world of nullable fields.