Your P99 just spiked from 180ms to 2.4 seconds. Your supergraph has eight subgraphs. Each subgraph team insists they're healthy. The dashboards on each individual service are green. The router is sweating. Somebody is lying. Without proper tracing across the federation, you're going to spend the next three hours on a war room Zoom call doing forensics with timestamps.
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.
For six years, the Java GraphQL world had two doors. Door One: Netflix DGS, born at a company whose entire product is one giant graph. Door Two: Spring GraphQL, blessed by the Spring team itself. Pick a door, write your code, and pray you never had to switch. Then somebody at Netflix and somebody at VMware had coffee, and the doors got knocked down. Here's what actually happened, what it means for your codebase, and whether you should care.
For a decade, we've told ourselves a nice story: GraphQL is for humans and frontends. Schemas exist so React developers can autocomplete field names. Then 2026 arrived, LLMs started writing half the code in your repo, and it turns out the thing AI agents desperately needed was exactly what you already had sitting in schema.graphqls. Every typed field, every enum, every nullable flag, every input validation: a ready-made contract for an agent to reason against. You just didn't call it that.
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.
Every GraphQL query you send travels over HTTP. Every response comes back the same way. But here's the thing: HTTP was designed for fetching documents, not executing queries. GraphQL essentially hijacked a delivery truck and turned it into a taxi service. Let's explore the protocol that makes it all possible.
Every time you fire a GraphQL query, your beautifully crafted response comes back wrapped in JSON. But how well do you actually know JSON? Not "I can read it" know, I am talking about "I know exactly where the spec draws the line" know. Buckle up. We're going deep on the most successful data format the web has ever seen.
You know how most companies build a GraphQL API, hit some scaling issues, and then write a blog post about it? Airbnb took a different approach: they built an entire data-oriented service mesh, ran it for five years at massive scale, and then open-sourced it. Meet Viaduct - GraphQL's ambitious cousin who went to architecture school.
Your REST API is like a teenager: it only responds when you ask it something. Repeatedly. Every second. "Any new messages?" "No." "Any new messages?" "No." "Any new messages?" "STILL NO." Enter GraphQL Subscriptions - where your API finally grows up and learns to call YOU when something interesting happens.
You've got a GraphQL interview tomorrow. Panic is setting in. Fear not - this is your survival guide. From basic concepts to system design, I've been on both sides of the table, and these are the questions that matter.