Forem: WunderGraph

The Three Bottlenecks AI Can't Code Away

WunderGraph — Thu, 07 May 2026 10:02:10 +0000

TL;DR

AI writes nearly half of all new code, but teams aren't shipping faster. The bottleneck moved from writing code to coordination, governance, and review. GraphQL Federation addresses all three with clear ownership, async governance, and schema-level usage tracking.

AI now generates roughly 40–45% of all new code, according to recent developer surveys on AI-assisted coding (Sonar State of Code Developer Survey ). Teams with high AI adoption have merged nearly 2× more pull requests year over year. But PR review times have increased by around 90% in some organizations, change failure rates are up, and deployment frequency often hasn’t caught up (Faros AI: The AI Productivity Paradox Report 2025 ).

We have a 10x faster engine bolted onto a 1x organization.

Unfortunately, the bottleneck didn't disappear. It moved.

If you're leading an engineering org of 50, 100, or 500 people and wondering where the productivity gains went, this post is for you. It addresses the three things your AI tools can't solve: coordination, governance, and review.

Why AI Coding Tools Aren't Making Engineering Teams Faster

Every engineering leader I talk to has the same story.

They rolled out some internal AI tooling, like Copilot or Cursor, and their engineers are writing more code than ever. Those metrics look great on paper.

But features aren't shipping faster.

The reason is simple: writing code was never the biggest bottleneck.

Yes, coding took time. But when you had a clear spec, it was fast. The real time sink was always the work around the code: figuring out what to build, where it lives, who needs to agree, and whether the result actually meets the spec.

AI made the coding part nearly instant. Turning a spec into code is fast now. And that has exposed how slow everything around it is. You have a spec, implement part of it, hit a new problem, go back to planning, and then you need to re-coordinate.

That loop is where the time actually goes. AI helps you get through the implementation steps faster, but you barely save any time if every return to planning means more meetings and governance overhead.

Think of it like a highway. You widened the middle section from two lanes to ten. But the on and off-ramps are still one lane. Traffic didn't improve. It just moved to the ramps.

The three ramps are coordination, governance, and review.

How API Coordination Becomes the Bottleneck in Large Engineering Orgs

Here's a scenario I see constantly.

A 70-person engineering org. Ten teams, six to eight engineers each. A product manager creates a ticket: "Add listening history to the user profile." Simple feature. Should take a few days.

It takes three weeks.

It doesn't take three weeks to build it; it takes three weeks to figure out where it goes.

Which team owns the user profile? Which service holds listening history? Do we add it to an existing endpoint or create a new one?

The frontend engineer Slack's the platform team. The platform team sets up a meeting with the backend team. The backend team informs them that it is actually two services, owned by two different teams. More meetings.

Three weeks later, they have a spec. The code takes a day.

This is the coordination tax, and it scales linearly with org size. More teams, more services, more time spent figuring out who to talk to.

AI doesn't help here because you can't prompt your way out of an organizational problem.

With REST APIs, this is structural. Every URL lives on a specific server, owned by a specific team. The moment you design an endpoint, you're making a backend decision. With 50 microservices, you have 50 possible homes for every new feature and no clear way to navigate them.

Compare this to GraphQL Federation. In a federated graph, you don't start with the backend. You start with the customer. What does the API consumer need? You model the perfect query, the "dream query", without thinking about which service implements it.

Then the supergraph tells you. It shows you which teams own the relevant entities, which subgraphs already implement parts of what you need, and where the gaps are.

Do you want to talk to 10 teams or let the graph tell you which 3 people to talk to?

API Governance at Scale: Why Catalogs and OpenAPI Specs Fall Short

Coordination answers who to talk to. Governance answers what's allowed.

Once you've figured out where a feature lives, someone still needs to decide if it's the right design. Is the naming consistent? Does it follow the schema conventions? Does it overlap with something another team already built?

In most organizations, this is a monthly API review committee. A queue of proposals waiting for the platform team to review. Product teams are blocked on a meeting that happens in two weeks.

This doesn't scale.

The deeper problem is that traditional API tools don't give you a domain-level view.

An API catalog is a list of endpoints. It tells you "here's a URL." It doesn't tell you the story of the data. What a playlist is, where it comes from, who owns each part.

Imagine a supergraph with 100,000 lines of SDL. That sounds unmanageable, but it's not. Because you don't navigate it by URL. You navigate it by entity.

A Playlist entity might have 100 fields coming from 20 different services. In a graph, you see all of them in one place: the fields, the ownership, the relationships. You see that Playlist.tracks comes from the catalog service, Playlist.recommendations comes from the ML team, and Playlist.analytics comes from the data platform.

Try doing that with an OpenAPI spec . You'd be reading 20 different API documents with no way to see how they relate.

Endpoints don't tell a story about the data. Entities do.

This is exactly what WunderGraph Hub is built for. Entities and their ownership are first-class concepts, not a wiki page someone forgot to update.

You see every entity, who owns it, and which services contribute to it. Governance becomes self-service: you propose a change, Hub tells you who's affected, and those people review it asynchronously. No committee meeting. No queue.

Why AI-Generated Code Is Slowing Down Code Review

AI generates code fast. But 96% of developers don't fully trust its functional accuracy.

So every AI-generated PR needs a human reviewer. And review times are up 91% because PRs are larger, more frequent, and harder to evaluate when you're not sure if the author (or the AI) truly understood the requirements.

This is the third bottleneck: review.

But here's the thing. Review is only painful when the spec is weak.

If you've solved bottleneck #1 (coordination) and #2 (governance), you have a clear, agreed-upon spec before anyone writes a line of code. Reviewing becomes validation against that spec, not an open-ended architecture debate in a PR comment thread.

At the schema level, this gets even more concrete. With Federation, you can track field-level usage across all clients. When a field is deprecated, every affected client sees it immediately. When a deprecated field hits zero usage, the system tells you it's safe to remove. We call this graph pruning: sunsetting fields and APIs that are no longer needed.

This is a natural lifecycle for API evolution: propose, implement, track, deprecate, and prune. No surprises. No "wait, who's still using this?"

If you have a good spec, reviewing becomes much easier.

How GraphQL Federation Solves Coordination, Governance, and Review

Federation is not a better API technology. You can solve the technical problem of routing a request to 50 services with BFFs, API gateways, gRPC, or any number of tools.

Federation solves the organizational problem.

Coordination: Start with the supergraph. Add the capabilities the consumer needs. Don't worry about which backend implements them yet. The graph's ownership model tells you exactly who to talk to. In WunderGraph Hub , creating a draft or proposal for adding a handful of fields to an entity takes a couple of minutes. Expand the graph, see the affected owners, and submit. More complex changes take longer, but the baseline is fast. No meetings. No scavenger hunts.

Governance: Proposals are reviewed asynchronously by the right people. Not a central committee, but the actual entity owners. They see exactly what's changing, in context, on a visual canvas that shows clients on the left, the supergraph in the middle, and services on the right. One single pane of glass for the entire API surface.

Review: Schema usage analytics, deprecation tracking, and graph pruning give you a continuous feedback loop. You know what's being used, what's stale, and what's safe to remove. Reviews are against a concrete spec, not vibes.

SoundCloud is a powerful example of this in action. They popularized the BFF pattern in 2011, the original workaround for "how do multiple frontends talk to many backends?" For years, it worked. Then the number of frontends grew, the number of services grew, and the BFFs became their own coordination problem: a layer of indirection that hid how frontends depended on backend services.

They're now migrating to GraphQL Federation . The company that popularized the workaround is adopting the real solution.

When You Don't Need GraphQL Federation

If you're a 10-person team with one frontend and a handful of services, don't adopt Federation.

Build a monolith. Move fast. Ship features. Stay under 10 engineers as long as you can.

Federation comes with a cost: schema design, composition, ownership models, governance workflows. That cost pays for itself when you have multiple teams, multiple frontends, and a growing service landscape.

The threshold is roughly this: if adding a new feature requires coordinating across three or more teams, you have the organizational problem Federation solves. If it doesn't, you don't need it.

Don't solve a problem you don't have.

How to Get the 10x Productivity Gain from AI

The companies that move fastest in 2026 won't be the ones writing code fastest, but the ones getting from ticket to production fastest.

The path from ticket to production has many steps: coordination, spec, implementation, review, governance, deployment. AI already made implementation fast. The question is whether you can make every other step just as fast.

Federation handles ticket → spec. AI handles spec → code. Schema analytics and governance handle review. Automate every repetitive step in between, and you get something close to the 10x everyone was promised.

But if you only invest in the AI side, faster code generation, smarter autocomplete, agentic coding, you're widening the highway while the on-ramp stays one lane.

Smaller companies have a natural advantage here. Less coordination overhead. Fewer teams to align. Larger organizations that don't address these bottlenecks will find themselves outpaced by leaner teams who got the full pipeline right, not just the coding part.

You can read the original article here: https://wundergraph.com/blog/ai-coding-bottlenecks

Where Does API Complexity Live?

WunderGraph — Mon, 04 May 2026 14:06:27 +0000

TL;DR

Every API architecture handles the same five concerns - data fetching, security, caching, contract management, and governance. None of them disappear. They just move. REST pushes data fetching to the client and keeps security and caching in the infrastructure. GraphQL pulls data fetching to the server and pushes security and caching into application code. Federation distributes the runtime concerns across teams but lands governance on humans. Fission moves governance from humans to design-time tooling. The question you should be asking yourself is where you want each responsibility to live.

In thermodynamics, the first law is non-negotiable: energy cannot be created or destroyed. It can only change form. To heat one thing, you must cool another. The total energy in a closed system remains constant.

Software architecture obeys a similar law. Larry Tesler, while at Xerox PARC in the 1980s, called it the Law of Conservation of Complexity: "Every application has an inherent amount of irreducible complexity. The only question is: Who will have to deal with it?" 1. Fred Brooks drew a complementary line in 1986, distinguishing essential complexity - the irreducible difficulty of the problem itself - from accidental complexity introduced by our tools 2. The essential part cannot be engineered away. It has to live somewhere.

Every API architecture must handle the same set of concerns:

Data fetching: who assembles data from multiple sources?
Security: where are access controls enforced?
Caching: where are responses stored and invalidated?
Contract management: who maintains the schema between producer and consumer?
Governance: what are the rules for how the system evolves?

These concerns never disappear. They move - between client and server, between infrastructure and application code, between modules in a monolith and services in a microservices architecture, between humans and tooling.

This article traces where each concern lives across four architectural approaches: REST, GraphQL, Federated GraphQL, and an emerging pattern that WunderGraph calls Fission. The goal is not to compare features or declare a winner. It is to map responsibility: where does each concern live, and who owns it?

One important caveat before we begin. REST is often discussed in its idealised form - proper HTTP caching, clean resource modelling, well-maintained OpenAPI specifications. In practice, most REST APIs do not fully achieve this. This is not just my opinion - Postman's State of the API reports consistently show gaps between API design intent and reality 22, and Fielding himself has noted that most APIs calling themselves REST do not actually conform to the architectural constraints he defined 25. That gap is not an indictment of REST. It is a recognition that when any architecture's idealised model meets operational reality, responsibility shifts. Where it shifts to is the question worth asking.

The Scenario

How do API architectures handle data from multiple services?

You lead the engineering team for a product detail page at a large e-commerce company - the single most visited page type on your platform. The page needs product information, pricing, inventory levels, reviews, and shipping availability. This data lives across four backend services, each owned by a different team. You serve two clients: a mobile app showing a condensed view and a web storefront showing everything.

The same five concerns apply regardless of architectural choice. What changes is where each one lives - and who carries it.

We start with REST, where most of these responsibilities begin their journey.

REST

Why does REST push data fetching to the client?

Data fetching lives with the client. The product detail page requires five sequential HTTP calls - one per service. On a slow connection, each round trip adds latency. The mobile app receives 47 fields per response but uses 8. This is the aggregation problem that REST's resource model does not inherently address - what Microsoft's Azure Architecture Centre documents as the "Chatty I/O" antipattern 23.

Responsibility for solving it falls on someone: the client writes orchestration code, the API team builds per-consumer aggregation endpoints, or a Backend-for-Frontend layer absorbs the work. A BFF sits between the client and the backend services - the mobile app makes one call to its BFF, which fans out to all five services server-side, filters the response down to the eight fields the mobile client needs, and returns a single payload. The five round trips collapse into one. But now someone needs to build and maintain that BFF. Usually it falls to the frontend team, who now own a server-side service in addition to their client code. Alternatively, a platform team provides the BFF - but then every consumer change requires a platform team ticket. Either way, you need a BFF per client type, each with its own aggregation logic. And as backend services evolve - new fields, changed response shapes, deprecated endpoints - each BFF becomes brittle, requiring constant maintenance to stay in sync. Phil Calcado formalised the BFF pattern at SoundCloud but warned about its limits: "Trying to derive a single schema that holds a complete-ish model of your data...reminds me too much of an Enterprise Data Model" 5. Martin Fowler echoed: "Beware of a One-Size-Fits-All API in any form" 6. The aggregation work exists. The question is who carries it.

How does REST handle caching and security?

Security lives in the infrastructure layer. WAFs inspect requests by URL pattern. Rate limiting works per endpoint. OAuth scopes map to URL paths. Decades of HTTP security tooling understand this model natively. This is one area where REST's operational reality aligns closely with its idealised form - the infrastructure is mature and widely deployed.

Caching lives in the protocol layer. Roy Fielding made caching a first-class architectural constraint in his 2000 dissertation: "Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable" 3. Each REST endpoint carries Cache-Control and ETag headers. CDNs, reverse proxies, and browser caches understand HTTP GET natively. The protocol owns this responsibility.

That is REST at its idealised best. In practice, the picture is less clean. Research reported by Nordic APIs found that 75% of APIs do not conform to their own specifications 4. Cache headers are misconfigured or omitted. Cache lifetimes are guessed at. The idealised story - where infrastructure handles caching automatically - degrades into partial coverage that teams must supplement with application-level caching. When the ideal breaks, caching responsibility shifts from the protocol layer to the application team, partially or entirely.

Why are contract management and governance fragmented in REST?

Contract management lives with the API team, separately from the code. OpenAPI specifications must be written, maintained, and kept in sync with actual server behaviour. When the contract is a separate artifact from the implementation, drift is the default state, not the exception. Keeping them aligned requires governance, tooling, and discipline.

Governance is implicit and fragmented. Each API team sets its own versioning policy, naming conventions, and change processes. There is no central authority deciding how the system evolves - each team governs its own endpoints independently. When aggregation spans teams, governance defaults to whoever builds the aggregation layer.

Gregor Hohpe captures the underlying pattern: "Flexibility brings complexity; decoupling increases latency; distributing components introduces communication overhead" 7.

In REST, responsibility for data fetching, schema accuracy, and governance sits with the teams building and consuming the API. Responsibility for security and caching sits close to the infrastructure. The problems are all present. They live on the client side and with the API team.

Now the responsibility shifts.

GraphQL

How does GraphQL solve over-fetching and shift complexity to the server?

GraphQL moves the centre of gravity from the client to the server by consolidating the API behind a single typed schema. A client describes the data it needs in a single query. The mobile team requests eight fields. The web team requests forty-two. One round trip. No over-fetching. As Lee Byron - co-creator of GraphQL and Executive Director of the GraphQL Foundation - put it: "GraphQL is a trade in the opposite direction - it optimizes for the network" 8.

Data fetching moves to the server. The client's aggregation problem from REST dissolves - but the work does not. The GraphQL server resolves each field independently, calling each backend service per resolver. The N+1 problem migrates: in REST, it manifested as N+1 HTTP round trips on the client. In GraphQL, it manifests as N+1 resolver calls on the server, typically addressed using batching patterns like Facebook's DataLoader 9 10. Responsibility for efficient data fetching has moved from the client to the server team.

Why do caching and security move into the application layer in GraphQL?

Caching moves from the protocol layer to the application layer. GraphQL is protocol agnostic - it can run over HTTP via the GraphQL over HTTP specification , over WebSockets for subscriptions, or over other transports entirely, much like MCP supports both STDIO and HTTP streaming. In practice, most deployments use HTTP POST, which CDNs and reverse proxies cannot cache natively. The network caching infrastructure that REST can leverage becomes unavailable. Caching still happens - normalised client caches, resolver-level caches, persisted queries over GET - but responsibility moves from infrastructure conventions to application developers who build and maintain these layers explicitly 11 12 13.

Most comparisons describe REST caching as automatic and GraphQL caching as absent. In practice, many REST APIs do not properly implement cache headers, and many GraphQL deployments achieve effective caching through persisted queries and normalised client stores. Adobe Experience Manager, for example, serves persisted GraphQL queries over GET - making them cacheable by CDNs and the browser's standard HTTP cache, just like REST endpoints. The operational reality on both sides is more nuanced than the idealised framing suggests.

Security moves from the infrastructure layer to the application layer. REST's per-endpoint rate limiting, WAF pattern matching, and route-level middleware depend on knowing what a request will do based on its URL. GraphQL's single endpoint accepts arbitrary query shapes, which means query depth attacks, batching attacks, and cost analysis all require custom middleware rather than infrastructure configuration 14. Escape's 2024 report found 69% of GraphQL services susceptible to DoS due to lack of resource controls 15. Neither REST nor GraphQL is inherently more or less secure. Security responsibility lives at a different layer.

Why can GraphQL governance become a bottleneck?

Contract management moves from a separate artifact to the implementation itself. The GraphQL specification requires introspection - the schema cannot drift from the implementation because it is the implementation 16. GitHub cited this as a primary motivation for adopting GraphQL: "Type safety, introspection, generated documentation, and predictable responses benefit both the maintainers and consumers" 17. For complex APIs with many consumers, this eliminates an entire category of integration failures. For simple APIs, it introduces more ceremony than REST's implicit contracts.

Governance concentrates on the schema owner. A single team owns the schema - and with it, the rules for how the API evolves. This works until multiple domain teams need to evolve it simultaneously, and the schema owner becomes the bottleneck. As Kin Lane observed, GraphQL "makes some very complex things simpler" but "also makes some very simple things more complex" 18.

No concern disappeared. Each one changed address. Data fetching moved from client to server. Security moved from infrastructure to code. Caching moved from protocol to application. Contract management moved from a separate artifact to the implementation itself. Governance concentrated on a single schema owner.

The problems that lived with the client now live with the server team. But one problem - governance - is about to move again.

Federated GraphQL

Why does GraphQL federation introduce new complexity?

As the schema grows and more teams need to contribute, the single schema owner becomes a bottleneck. Federation restructures governance by distributing schema ownership. Each team owns a subgraph defining their domain types. A gateway/router composes these into a unified schema at build time and routes queries at runtime.

Netflix operates at this scale: 300+ subgraphs, 3,000+ types, powering 50-60 applications with a small gateway/router team. Stephen Spalding explains: federation "removes the business logic from the core aggregator, so that it becomes an appliance, like a reverse proxy. That is something you can scale" 19.

How are data fetching, caching, and security distributed in federation?

Data fetching lives with each subgraph team for their domain, and with the gateway for cross-subgraph orchestration. The gateway decomposes a client query into subgraph fetches, executes them in parallel where possible, and merges results. The orchestration responsibility that lived with the client in REST, and with the monolithic server in GraphQL, now lives with the gateway.

Caching distributes across subgraph boundaries. Each subgraph caches its own resolver responses. The gateway can cache composed responses. Client-side normalised caches must understand entity references that span subgraphs. Cache invalidation becomes a distributed problem.

Entity caching changes this dynamic. When the gateway/router caches resolved entities - a product, a user, a price - by their entity key, caching becomes a platform concern rather than a team-by-team responsibility. Individual subgraph teams no longer need to build and maintain their own caching layers. The platform offers caching as a service, and every team benefits without additional work. This shifts caching from a distributed problem back toward an infrastructure problem - though one that lives at the gateway layer rather than the protocol layer.

Security distributes across layers. Field-level authorisation lives with each subgraph team. Query cost limits, depth restrictions, and authentication live with the gateway. The gateway must trust that dozens of teams enforce policies consistently - or centralise authorisation and accept the governance overhead.

Why does federation create a governance bottleneck?

Contract management lives with each subgraph team for their types, and with the composition system for cross-subgraph compatibility. The schema remains introspectable and self-documenting. But composition introduces a new failure mode: changes in one subgraph can break composition with another. Contract testing and schema validation become essential infrastructure.

Governance - and this is the most significant shift - lives with humans. Discovering who owns which types requires institutional knowledge. Cross-subgraph schema changes require finding owners, scheduling meetings, negotiating entity keys, and tracking approvals. One enterprise with 60+ subgraphs and 25 teams found that a feature spanning three subgraphs took nine weeks from request to production - two days of engineering per team, seven weeks of governance overhead 20. Platform teams in large federations report spending sixty percent of their time as human routers rather than engineers.

The journey continues. Data fetching moved from the client to the server, then to the gateway. Caching distributed across subgraph boundaries. Security distributed across teams. Contract management distributed to subgraph owners with a composition system keeping them aligned. Each of these concerns found a new home.

But governance - the concern that was implicit and fragmented in REST, then concentrated on the schema owner in GraphQL - has now landed on humans. Platform teams, Slack threads, meeting invitations, approval chains. And human governance does not scale linearly.

The responsibility is about to move once more.

Fission

How does Fission change API design from bottom-up to top-down?

An emerging pattern addresses federation's governance bottleneck by inverting the direction of schema design. WunderGraph calls the algorithm Fission - a name borrowed from nuclear physics, where a heavy nucleus splits into smaller parts while releasing energy. The analogy is deliberate: a single consumer-facing schema splits into subgraph responsibilities, and the energy released is engineering velocity previously lost to human governance.

In federation, each team builds a subgraph based on what their service can expose. The supergraph is assembled from below - a side effect of composition, not an intentional design. Field names reflect service internals. Type boundaries match team boundaries. The consumer API is whatever falls out.

Fission starts from the other end. Design the consumer-facing API first - the ideal query a client would write with no technical constraints. Then decompose downward into subgraph responsibilities. The supergraph is the source of truth. Federation's runtime model stays intact; the design process inverts.

This is a return to GraphQL's origins. When Byron and colleagues built GraphQL at Facebook, the premise was consumer-first: the client describes what it needs, the system figures out fulfilment. Federation drifted producer-first over time. Fission recovers the original philosophy at enterprise scale - design like a monolith, implement as microservices.

How does Fission reduce governance overhead?

Governance moves from humans to design-time automation. Fission identifies who owns which types, analyses the impact of proposed changes, propagates entity keys and federation directives, and routes proposals to affected teams. Composition validation happens at design time, before code is written. The platform team stops being human routers.

An eBay architect described the underlying problem: "Ownership, checks, and cross-team negotiations have become one of our biggest velocity bottlenecks" 21. Early adopters report that the barrier to proposing schema changes drops significantly when governance shifts from meetings to tooling 20. The pattern is still emerging - these are early signals, not established benchmarks.

What new complexity does Fission introduce?

Contract management lives in a dual-view system - the supergraph (consumer-facing API) and the subgraphs (what each team implements), kept synchronised by the Fission engine. When a consumer need changes, the tooling derives the subgraph consequences.

Caching, data fetching, and security remain where federation placed them. Fission does not alter the runtime architecture. It addresses the design-time governance layer.

But the conservation law holds. New complexity appears.

Design-time tooling must be maintained, monitored, and trusted. Keeping supergraph and subgraph views synchronised as the graph evolves is a non-trivial engineering challenge. The tooling is young and the pattern is still emerging.

Consumer-first design requires someone to do the design. When APIs are shaped from consumer needs rather than backend structure, someone must understand those needs deeply. This is API product management - a discipline most engineering organisations have not formalised.

Governance must be defined, not just enforced. Naming conventions, design standards, composition policies - automation handles enforcement, but humans decide what to enforce. Automated governance with poorly chosen rules produces consistently bad schemas efficiently.

Responsibility shifted from human governance to design-time tooling, product thinking, and governance definition. Whether this is a favourable trade depends on which of those your organisation is better equipped to handle.

The journey that began with the client - assembling data from five REST endpoints - has passed through the server, the gateway, the organisation, and arrived at design-time automation. At every stage, the same five concerns were present. At every stage, they lived somewhere different.

The Responsibility Map

How do REST, GraphQL, federation, and Fission distribute responsibility?

Across four architectures, the same five concerns appeared. None disappeared. Each one moved.

Responsibility Map - Google Sheets

docs.google.com

Why doesn't any API architecture eliminate complexity?

If you were to draw each architecture as a shape on a radar chart - one axis per concern, measuring not capability but where responsibility sits - you would see four distinct shapes. REST extends outward on data fetching and contract management, pulls inward on security and caching. GraphQL inverts this. Federation distributes runtime concerns but extends human governance. Fission compresses human governance but extends tooling complexity.

The total area enclosed by each shape is roughly equal. No architecture is smaller. Each one distributes the work differently - across different layers, different teams, different disciplines.

What This Means

Which API architecture is the best choice?

The Postman 2025 State of the API report shows REST at 93% adoption and GraphQL at 33% 22. Those numbers describe coexistence, not competition. Organisations adopt different responsibility distributions for different contexts - often running both simultaneously.

The question was never which technology is better. It was always: given your team's strengths, your consumers' needs, your organisational structure, and your operational maturity - where should each responsibility live?

What is the real question behind REST vs GraphQL?

A reader who finishes this article thinking about REST versus GraphQL has missed the point. The point is: who in your system or organisation is responsible for each problem - and is that where you want the responsibility to be?

Architecture is not about eliminating complexity. It is about deciding where it lives, and who owns it.

How WunderGraph Helps

If you're running federated GraphQL and recognise the governance bottleneck described in this article, WunderGraph builds the platform to address it.

WunderGraph Cosmo is the federation platform - the control plane for composing, managing, and operating your federated graph. It handles schema composition, analytics, and the operational concerns that come with running federation at scale.
WunderGraph Hub is the design-time governance layer - schema proposals, impact analysis, automated composition validation, and routing changes to the right teams. Hub is where Fission lives, inverting the design process so you start from the use-case and design with intent.

The concerns described in this article don't disappear. WunderGraph moves them to where tooling can manage them - so your engineers can focus on building, not coordinating.

References

[1] Tesler, L. "Law of Conservation of Complexity." (~1984). https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity

[2] Brooks, F.P. "No Silver Bullet - Essence and Accident in Software Engineering." (1986). https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.pdf

[3] Fielding, R.T. "Architectural Styles and the Design of Network-based Software Architectures." PhD dissertation, UC Irvine, Chapter 5. (2000). https://roy.gbiv.com/pubs/dissertation/rest_arch_style.htm

[4] Nordic APIs. "Understanding the Root Causes of API Drift." https://nordicapis.com/understanding-the-root-causes-of-api-drift/

[5] Calcado, P. "Some Thoughts on GraphQL vs. BFF." (2019). https://philcalcado.com/2019/07/12/some_thoughts_graphql_bff.html

[6] Fowler, M. Tweet on BFF and GraphQL. https://x.com/martinfowler/status/1149688467829354501

[7] Hohpe, G. "The Software Architect Elevator." O'Reilly. (2020). https://architectelevator.com/book/

[8] Byron, L. "Interview with GraphQL Co-Creator Lee Byron." Nordic APIs. https://nordicapis.com/interview-with-graphql-co-creator-lee-byron/

[9] Shapton, L. et al. "Solving the N+1 Problem for GraphQL through Batching." Shopify Engineering. https://shopify.engineering/solving-the-n-1-problem-for-graphql-through-batching

[10] Facebook. "GraphQL DataLoader." https://github.com/graphql/dataloader

[11] Sturgeon, P. "GraphQL vs REST: Caching." APIs You Won't Hate. https://apisyouwonthate.com/blog/graphql-vs-rest-caching/

[12] Byron, L. Reactiflux Q&A transcript. https://www.reactiflux.com/transcripts/lee-byron

[13] Giroux, M-A. "GraphQL & Caching: The Elephant in the Room." Apollo GraphQL Blog. https://apollographql.com/blog/backend/caching/graphql-caching-the-elephant-in-the-room

[14] OWASP. "GraphQL Cheat Sheet." https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html — See also: "REST Security Cheat Sheet." https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html

[15] Escape. "The State of GraphQL Security 2024." https://escape.tech/resources/the-state-of-graphql-security-2024

[16] GraphQL Foundation. "GraphQL Specification, Section 4 - Introspection." https://spec.graphql.org/October2021/

[17] GitHub Engineering. "The GitHub GraphQL API." (2016). https://github.blog/developer-skills/github/the-github-graphql-api/

[18] Lane, K. "My GraphQL Thoughts After Almost Two Years." API Evangelist. (2018). https://apievangelist.com/2018/04/16/graphql-thoughts-after-almost-two-years/

[19] Shin, J. & Spalding, S. "How Netflix Scales Its API with GraphQL Federation." InfoQ. https://www.infoq.com/presentations/netflix-api-graphql-federation/

[20] WunderGraph. Customer case study: 60+ subgraphs, 25 teams. 75-87% schema change cycle time reduction, 4x monthly schema proposals after adopting Fission. (2026).

[21] WunderGraph. eBay architect testimonial: "Ownership, checks, and cross-team negotiations have become one of our biggest velocity bottlenecks." (2026).

[22] Postman. "2025 State of the API Report." https://www.postman.com/state-of-api/2025/

[23] Microsoft. "Chatty I/O Antipattern." Azure Architecture Centre. https://learn.microsoft.com/en-us/azure/architecture/antipatterns/chatty-io/

[24] Hamer, N. "The Conservation of Complexity in Software Architecture." Capgemini Engineering. https://capgemini.github.io/architecture/The-Conservation-of-Complexity-in-Software-Architecture/

[25] Fielding, R.T. "REST APIs must be hypertext-driven." (2008). https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

This article was originally published on: https://wundergraph.com/blog/rest-vs-graphql-vs-federation-complexity#references

GraphQL vs REST: 18 Claims Fact-Checked with Primary Sources (2026)

WunderGraph — Sat, 18 Apr 2026 01:23:38 +0000

What happens if we take a scientific approach to analyzing the most common claims about GraphQL vs REST? You might be thinking that you know the answer to most of these claims, and even I thought I did before I started this research.

SPOILER ALERT: GraphQL is inferior to REST because it breaks HTTP caching is actually misleading. The infamous N+1 problem? It's real, but REST has it too, say multiple high-profile sources.

Some of these claims are repeated so often that they become accepted wisdom, and people stop questioning them. I always knew that some of them were wrong, but what I didn't expect was how even the most widely repeated claims often turned out to be misleading or incomplete when I traced them back to their original sources.

Disclaimer

I run WunderGraph . We build GraphQL Federation infrastructure. I have a horse in this race, and you should know that upfront.

That said, my personal opinion is that both GraphQL and REST are valuable tools for different use cases. I would always recommend our customers to use both solutions side by side if they can complement each other, but ultimately, it's about finding the right technical solution to solve a business problem, not about picking a side in a technology debate.

I traced these commonly repeated assertions to their original sources where a verifiable primary source was available, and used secondary or vendor sources where primary evidence was not accessible.

Where only vendor benchmarks or secondary sources are available, those are labeled explicitly and treated as directional rather than conclusive.

Summary

Summary - GraphQL vs REST: 18 Claims Fact-Checked with Primary Sources (2026) - Google Sheets

docs.google.com

Here is what the evidence suggests.

Part I: What the Evidence Says

This section focuses on verifiable claims and their sources.

Every claim is sourced where a verifiable reference is available. A fair comparison requires evaluating both technologies under equivalent assumptions: default vs. default and optimized vs. optimized.

In this analysis, “default” means out‑of‑the‑box behavior, while “production” means commonly adopted patterns in mature or scaled deployments.

Where an original claim is right, I say so; where the evidence disagrees, I show why.

The Origin Story: How Facebook Actually Built GraphQL

Claim 1: "Facebook built GraphQL for hundreds of internal microservices"

Verdict: Historically imprecise.

The 2012 timeline, the iOS News Feed context, and the mobile bandwidth constraints are all real.

I could not find a primary source describing Facebook's 2012 backend as a system composed of "hundreds of microservices," or stating that GraphQL was created to unify such a system. The GraphQL Foundation's own Federation page states:

Meta (formerly Facebook), where GraphQL was created, has continued to use a monolithic GraphQL API since 2012.

Facebook ran a massive PHP codebase, scaled through HipHop (a PHP-to-C++ transpiler) and later HHVM (a just-in-time compiler for PHP). Keith Adams , Facebook's Chief Architect and HHVM team lead, describes how Facebook scaled a large, unified PHP application in Software Engineering Daily interviews and InfoQ presentations .

The strategy emphasized scaling PHP through compilation rather than prioritizing early service decomposition. On top of the PHP application sat TAO , a graph-structured data layer built on MySQL and memcached. TAO provided a unified way to access social graph data. The backend included multiple systems and data sources, but primary sources do not describe it as a microservice-oriented architecture.

Meta's engineering blog describes "existing databases and business logic," rather than framing the problem as a microservice-oriented API layer. The common argument is that GraphQL was built to manage hundreds of microservices. There is no primary source clearly supporting that framing of the original problem GraphQL was designed to solve, and its later use in microservice architectures does not change that original motivation.

In short, microservices later became a use case for GraphQL, not the original design driver; saying GraphQL was “built for hundreds of microservices” reverses that causal order.

Claim 2: "Lee Byron, Dan Schafer, and Nick Schrock built GraphQL"

Verdict: Generally accurate, but slightly simplified.

Primary sources and historical accounts consistently credit Lee Byron , Dan Schafer , and Nick Schrock as the key creators of GraphQL. Nick Schrock is widely described as writing the initial prototype, reportedly called "SuperGraph." Together with Dan Schafer and Lee Byron, they developed GraphQL and brought it into production at Facebook around 2012.

Nordic APIs interviewed Lee Byron about the creation process, and Datanami covers the contributions of all three.

However, this framing simplifies the broader effort. GraphQL was developed within a larger team at Facebook, and multiple engineers contributed to its design, implementation, and adoption. The claim is accurate at a high level, but should be understood as identifying the primary contributors rather than the full set of people involved.

Claim 3: "Facebook open-sourced GraphQL in 2015"

Verdict: Accurate.

Facebook publicly released GraphQL on September 14, 2015 , following its public introduction at the React Europe conference in Paris earlier that year. In 2018, GraphQL was moved to the GraphQL Foundation , where it is now governed under the Linux Foundation .

The GraphQL N+1 Problem: Does REST Have It Too?

Claim 4: "Fetching 25 users with posts in GraphQL results in 26 database queries"

Verdict: Partially true (implementation-dependent, not inherent to GraphQL).

The arithmetic is correct for one specific scenario, and the official GraphQL.js documentation confirms it:

In GraphQL.js, each field resolver runs independently. There's no built-in coordination between resolvers, and no automatic batching.

This behavior is not defined by the GraphQL specification, but by how resolver-based servers like GraphQL.js execute queries. When you query for 25 users and their posts, the server may first execute one query to fetch all 25 users. Then, for each user, it may execute a separate query to fetch that user's posts. That's 25 + 1 = 26 database queries, which is the classic "N+1 problem": N queries for related data, plus 1 for the initial list.

For servers built on GraphQL.js without DataLoader, this is a common outcome in resolver-based implementations. In practice, many GraphQL deployments introduce batching layers, such as DataLoader, or use engines that compile queries into optimized database queries to avoid this pattern. But the picture is incomplete in two ways.

First, some GraphQL engines addressed this years ago. Tools like Hasura and PostGraphile don’t rely on per-field resolvers for database-backed queries. They compile GraphQL queries directly into optimized SQL with JOINs. In these systems, the 25-users-with-posts query can often be executed as a single database query. In its own benchmarks, Hasura reports up to higher throughput than hand-written Node.js code using DataLoader. This is based on vendor benchmarks and should be treated as directional rather than conclusive.

Second, REST can exhibit a similar N+1 pattern at the network layer, as shown in the next claim.

Claim 5: "In REST, fetching 25 users with their posts is two calls"

Verdict: Misleading.

A common claim is that REST handles this in two calls:

GET /users and GET /users/:id/posts.

But look at that second URL. The :id is a path parameter.

Without a dedicated batch endpoint, the REST client has to call GET /users/1/posts, GET /users/2/posts, ... GET /users/25/posts. Without a batch or embedding mechanism, this can result in 26 HTTP round-trips. In many systems, 26 HTTP round-trips (each requiring a full network request-response cycle) is going to be more expensive than 26 database queries behind a single HTTP call.

The REST API Tutorial documents this exact problem. Microsoft's Azure Architecture Center calls this the Chatty I/O antipattern and explicitly names it "the N+1 problem." N+1 is not a GraphQL-specific problem. It manifests at different layers.

To get it down to two calls, REST needs a purpose-built batch endpoint like GET /users/posts?ids=1,2,...,25. That endpoint either uses POST (typically uncacheable in practice) or GET with dynamic query parameters where every unique combination of user IDs produces a different URL.

And it's not just the combination that matters; it's also the order, unless it is normalized.

?ids=1,2,3 and ?ids=3,1,2 are different URLs to a CDN, which means different permutations of the same IDs can produce different cache keys. In practice, many REST architectures introduce aggregation layers or backend-for-frontend services to avoid this pattern. We'll come back to why this matters in the caching section.

The fair comparison is either naive-to-naive (26 HTTP calls vs. 26 DB queries) or optimized-to-optimized (batch endpoint vs. DataLoader or query compilation, both producing 1-2 queries). The original claim oversimplifies the design trade‑offs by mixing optimized REST with naive GraphQL.

Claim 6: "DataLoader is not built into GraphQL and is not part of the specification"

Verdict: True (but often misunderstood in practice).

The statement is technically correct at the specification level, but incomplete in how GraphQL is used in practice.

DataLoader was originally developed at Facebook, and its copyrights were later transferred to the GraphQL Foundation. It is now maintained as part of the broader GraphQL ecosystem. It batches and deduplicates data fetches within a single request, does not share results across requests, and is not a replacement for application-level caching.

When multiple resolvers request the same data (e.g., "fetch user 1", "fetch user 5", "fetch user 12"), DataLoader collects them into a single batch call and issues one combined fetch. Instead of 25 individual database queries, a single batched query can often fetch all 25 users at once.

DataLoader is generic and not specific to GraphQL, the same pattern can be used in REST APIs, microservices, or any system with N+1-style access patterns.

For example, Netflix DGS provides @DgsDataLoader annotations in Java, gqlgen documents DataLoader integration for Go, and GraphQL-Ruby has GraphQL::Dataloader built in. Query compilation engines (Hasura, PostGraphile) bypass the need for DataLoader by generating optimized SQL directly.

DataLoader reduces redundant fetches, but it introduces additional complexity in resolver design and requires careful scoping and key management.

REST does not define a standard batching mechanism at the protocol level. When batching is needed, it is handled through API design (such as bulk endpoints), infrastructure, or framework-specific solutions. Some specifications attempt to address this, such as OData’s batch format or JSON:API’s compound documents, but adoption is inconsistent.

These differences reflect where batching is handled. GraphQL solutions often address it at the execution layer, while REST implementations handle it through API design or infrastructure. DataLoader is therefore just one of several batching patterns in the GraphQL ecosystem, not the only way to avoid N+1.

GraphQL vs REST Performance: What Benchmarks Actually Show

Claim 7: "REST delivers nearly half the latency and 70% more requests per second"

Verdict: Context-dependent and often misapplied.

These numbers come from a Medium benchmark that tested a Hello World‑style endpoint and is representative of a broader class of “Hello World” REST vs GraphQL benchmarks, not necessarily the exact one cited by any particular critic:

REST at ~7.68ms latency vs. GraphQL at ~13.51ms, and ~11,972 RPS vs. ~7,085 RPS.

That kind of workload mostly measures protocol overhead on a flat response, not the multi-resource retrieval problem GraphQL was designed to address. It is also informal evidence from a single implementation, not a peer-reviewed study. For relational or multi-resource data retrieval, several studies report the opposite result under some workloads.

A peer-reviewed study by Seabra, Nazário, and Pinto, published at SBCARS '19 (proceedings in the ACM Digital Library), found that migrating from REST to GraphQL reduced latency in two of three tested applications, often by reducing the number of network round-trips. Under workloads above 3,000 requests, REST outperformed GraphQL.

A study by Jin, Cordingly, Zhao, and Lloyd at UW Tacoma , presented at WoSC10 (December 2024), evaluated a 10.9‑million‑row CMS dataset on AWS, and reported 25–67% lower average latency for GraphQL on several data-intensive operations, while REST retained an advantage at the highest concurrency levels.

A separate study by Lawi, Panggabean, and Yoshida, found REST was faster on response time and throughput in that test setup, while GraphQL used about 37-40% less CPU and memory. That supports a real resource-efficiency tradeoff, though the result is specific to that workload.

Elghazal, Aneiba, and Shahra presented at WEBIST 2025 and found REST ~3.7x faster on response time in a Go-based microservices setup, while GraphQL transferred significantly less data overall, reducing total data volume from several gigabytes to a few hundred megabytes. The 3.7x latency gap is larger than what other studies report, which suggests strong sensitivity to implementation and workload.

Across these studies, a general pattern emerges

Performance varies by workload, and neither approach is consistently faster. REST often has lower per-request overhead for simple payloads and at high concurrency. GraphQL can have lower total latency when it reduces or eliminates multiple round-trips, transfers less data, or uses fewer server resources.

The right choice depends on the workload, including schema design, query patterns, and implementation details. Citing a flat CRUD benchmark to evaluate a system designed for relational queries is technically correct, but it measures a different use case.

GraphQL Caching vs REST Caching: The Real Tradeoffs

Claim 8: "GraphQL uses POST to a single endpoint; HTTP caching does not work"

Verdict: Partially true (default vs production setups).

Standard GraphQL implementations use POST to /graphql. POST requests are not cached by browsers, CDNs, or reverse proxies by default. This is a real limitation and worth understanding.

HTTP caching relies on two things: the request URL being stable across clients, and the HTTP method being GET in most common caching setups. When every GraphQL request is a POST with a body that is not used as part of the cache key by intermediaries, caches cannot reliably match requests to stored responses.

More precisely, the issue is a lack of stable cache keys rather than POST itself, since POST responses can be cached when explicitly configured. By default, this gives REST an advantage for simple, per-resource caching, while GraphQL requires additional setup to achieve similar behavior.

But the comparison with REST is asymmetric.

As we established in Claim 5, REST serving relational data often either makes multiple individual GET requests (cacheable but N+1 round-trips) or uses a batch endpoint (efficient but less cacheable in practice). In many production systems, REST avoids this trade-off by relying on per-resource caching combined with client-side or edge aggregation (for example, a BFF or gateway), rather than batching at the CDN layer.

A REST batch endpoint like GET /users/posts?ids=1,2,3,...,25 produces a different URL for every unique combination of requested users. And as we noted in Claim 5, it's not just the combination that matters, but also the order: ?ids=1,2,3 and ?ids=3,1,2 are different cache keys to a CDN. CDN cache hit rates for these parameterized URLs can be lower in practice, depending on usage patterns.

Even if you do manage to cache batch URLs, invalidation becomes expensive. When a single entity changes (say, user 7 updates their profile), you need to invalidate every cached batch URL that contains that user's ID. Most CDNs have no built-in way to compute which URLs contain which IDs without additional tagging or indexing. A single entity change can invalidate an unpredictable number of cached responses. This comparison mixes HTTP-level caching with client-side caching, which solve different problems but are often combined in real systems.

Compare this to GraphQL's normalized client cache (Apollo Client, Relay), where invalidation happens at the entity level. This operates at the client layer and does not replace HTTP-level caching. User 7's data is stored once by its cache ID. When it changes, only that entity updates, and every view referencing it refreshes automatically. No URL permutation problem. No batch invalidation cascade.

These trade-offs can make it difficult to simultaneously optimize REST for both batch efficiency (for the N+1 comparison) and high HTTP cache reuse (which requires stable, per-resource URLs). These approaches are in tension. Optimizing for batch efficiency reduces round-trips, but tends to lower CDN cache hit rates and complicate invalidation.

A common production solution: Persisted Queries.

Also called trusted documents, persisted queries are a recommended production pattern for GraphQL APIs. Instead of sending the full query string in a POST body, the client sends a hash: GET /graphql?extensions={"persistedQuery":{"sha256Hash":"abc123"}}.

This approach is most effective for first-party APIs, where the set of allowed operations can be controlled.

It can be implemented as a GET request with a more stable URL when queries are pre-registered. This requires maintaining a registry of allowed operations and coordinating deployments between client and server. CDNs can cache it like other GET requests when configured appropriately.

However, this approach is less flexible for highly dynamic queries and is harder to apply in public or third-party API scenarios. Variables still affect cache keys, so different inputs produce different cache entries, and fragmentation can still occur depending on usage patterns. Adobe Experience Manager , for example, recommends persisted queries as the preferred way to enable CDN caching for GraphQL.

Persisted queries can help address the caching problem (GET requests, stable URLs), the security problem (only pre-registered queries execute), and the client size problem (works with plain fetch()).

While some systems allow GET with query‑string GraphQL, it is brittle in practice, which is why POST‑by‑default is the effective pattern.

Claim 9: "56% of teams report caching challenges with GraphQL"

Verdict: Partially true (source unclear, underlying concern valid).

The 56% figure is widely cited, attributed variously to an "Apollo 2024 survey" or a "JetBrains Developer Survey." I could not locate a clear primary source for this exact number. Given the lack of a verifiable primary source, this statistic should be treated as anecdotal rather than evidence‑based.

Even if the number were accurate, it would still need to be interpreted carefully. Regardless of that specific percentage, the underlying concern is real: GraphQL caching is more complex by default, because it often handles multi-resource queries that do not map cleanly to per-resource HTTP caching and pushes more responsibility onto the client and gateway layers. This means teams must make explicit architectural choices to get effective caching, rather than relying on default HTTP behavior.

REST systems can avoid some of this complexity through per-resource caching, but face their own trade-offs when aggregating data or batching requests, including reduced cache reuse and more complex invalidation. At the same time, the problem is well understood, and there are established patterns to address it: persisted queries for CDN caching (see Claim 8), and normalized client caches for application-level caching (see Claim 10).

Claim 10: "Apollo Client weighs 43 KB gzipped"

Verdict: Misleading comparison (incomplete framing).

I often see comparisons framed as Apollo Client (43 KB) versus fetch() (0 KB), implying GraphQL requires a heavy client library while REST uses native browser APIs.

Historically, measurements around 40–45 KB gzipped were reasonable for older Apollo Client bundles , but recent v4.x releases have reduced bundle size and made features more modular. Regardless, that is not a cost of GraphQL itself. The same concern exists for feature‑rich REST clients like SWR or TanStack Query . It is a misleading comparison because both REST and GraphQL can be implemented with nothing more than fetch(). Therefore, the theoretical baseline for both styles is 0 KB.

GraphQL is an HTTP request:

const data = await fetch('/graphql', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ query: '{ users { name } }' })
}).then(r => r.json())

No library is strictly required.

With persisted queries, it can be simpler at runtime: a GET request with a hash parameter. This requires pre-registering operations and coordinating between client and server.

In practice, many GraphQL applications adopt libraries like Apollo Client or Relay because they solve common problems around caching, state management, and request orchestration. The additional bundle size in libraries like Apollo Client pays for these capabilities.

Similar trade-offs exist in REST clients, though GraphQL clients often include more built-in behavior due to the structure of the query model. In both cases, these libraries shift complexity from the API layer to the client. Without it, you often end up rebuilding similar logic yourself or pulling in REST-side alternatives like TanStack Query or SWR.

Apollo Client provides a normalized cache that stores entities by ID and enables automatic UI updates when cached data changes. When a mutation returns updated data, Apollo can update the cache and reflect those changes in many relevant queries without requiring manual refetching.

On top of the normalized cache, Apollo provides additional features.
These include optimistic updates, pagination helpers, request deduplication, and partial error rendering.
It also includes local state management and DevTools for inspecting cache data and queries.

Relay (by Meta) provides additional compile-time guarantees. Its ahead-of-time compiler runs at build time, catching malformed queries before the app ships. Fragment colocation lets each component declare the data it needs, and data masking ensures components only access the data defined in their fragments, preventing accidental coupling between components.

Relay includes configurable garbage collection for unreferenced records in its normalized store, helping limit memory growth in long-running applications. These features address common data consistency and state management problems.

In applications where the same entity appears in multiple places (e.g., avatar, comments, profile), a normalized cache with automatic mutation propagation reduces stale-data bugs. Building this yourself means maintaining a manual entity store with subscription and notification logic.

That's the role these libraries serve.

Real-world REST applications pay similar costs, though they can sometimes defer this complexity longer depending on access patterns. TanStack Query, Axios, and SWR introduce additional bundle size for features like caching and request management.

A fairer comparison is either naive-to-naive (no clients, just fetch()) or full-featured to full-featured: Apollo Client and tools like TanStack Query both add bundle size in exchange for caching, deduplication, and state management.

Claim 11: "fetch() ships with every browser at 0 KB"

Verdict: Confirmed.

True. The Fetch API is built into all modern browsers and is available natively in recent versions of Node.js. But as we showed in Claim 10, GraphQL also works with fetch() at 0 KB. This is often presented as a REST advantage, even though it applies equally to both.

Is GraphQL Less Secure Than REST?

Claim 12: "A 128-byte nested query can consume 10 seconds of CPU time"

Verdict: Partially true (context-dependent).

Security research shows that small, deeply nested GraphQL queries can consume disproportionate CPU time.

This applies primarily to resolver-based implementations without depth or cost controls. In a GraphQL schema with circular references (e.g., a User has friends who are also User objects), an attacker can construct a query like:

{ user { friends { friends { friends { friends { friends { ... } } } } } } }

In a worst case scenario with an unoptimized implementation, if each user has 10 friends, 6 levels of nesting could theoretically result in up to 10^6 = 1,000,000 resolver calls. The query string itself is tiny, but the computational cost can grow quickly — in some cases exponentially — depending on schema design and resolver behavior.

The specific numbers depend on schema complexity and server hardware, but the principle is documented in security writeups and research .

Scope: first-party vs public APIs matters.

For first-party APIs, trusted documents can significantly reduce this attack vector in controlled environments, but do not address inefficient resolver behavior within allowed operations. When a GraphQL server only executes pre-registered operations, arbitrary queries, including malicious depth attacks, can be rejected before execution. The official GraphQL.org Security page confirms this.

For public APIs, this remains a real concern. GraphQL.org explicitly states that "trusted documents can't be used for public APIs because the operations sent by third-party clients won't be known in advance." Public APIs need depth limiting, cost analysis, and rate limiting. Many implementations also use batching techniques (e.g., DataLoader) to reduce redundant resolver execution.

The attack scenario is valid for public APIs. But many GraphQL deployments are first-party, and persisted queries can prevent arbitrary depth attacks by restricting execution to pre-registered operations. These risks depend heavily on whether the API accepts arbitrary queries or restricts execution to known operations.

Claim 13: "80% of GraphQL APIs are vulnerable to denial-of-service through query depth"

Verdict: Misleading framing (misinterpreted statistic).

The 80% figure is commonly misinterpreted from Escape's State of GraphQL Security 2024 .

The reported DoS vulnerability rate is 69% of scanned public GraphQL endpoints. 80% comes from a separate finding in the same report: "80% of issues could have been resolved by implementing best practices", which measures remediability, not prevalence.

The 69% and 80% figures come from different parts of the same report and measure different things; they are not interchangeable.

Public APIs accepting arbitrary third-party queries have a different security profile than first-party APIs using trusted documents. For first-party APIs, the depth-DoS attack vector can be significantly reduced when using persisted queries, though inefficient or overly expensive allowed operations can still create performance risks.

API security challenges are not unique to GraphQL.

Salt Security's 2024 report , based on a survey of 250 IT and security professionals, found that 37% experienced an API security incident in the past 12 months (up from 17% in 2023), 95% encountered security issues in production APIs, and 23% suffered an API-related breach.

These findings apply to APIs broadly and are not specific to GraphQL.

Important caveat: Escape's 69% measures vulnerability scan results on 160 public endpoints. Salt's figures measure self-reported incidents across 250 organizations. They are not directly comparable because different methodologies are being used to measure different things. Even so, the broader point is: API security is an industry-wide challenge, not specific to GraphQL.

Claim 14: "Most frameworks ship with no default depth limit"

Verdict: Partially true (implementation defaults).

Many GraphQL server frameworks do not enable depth limiting by default. The official GraphQL.org Security page recommends it, stating: "Even when the N+1 problem has been remediated through batched requests to underlying data sources, overly nested fields may still place excessive load on server resources." This is not defined at the GraphQL specification level and is left to server implementations.

This is a real concern and should be taken seriously, even with DataLoader or query compilation.

The plugin ecosystem makes it relatively easy to add these controls. Libraries such as GraphQL Armor and Envelop plugins provide depth and cost controls. But it is opt-in, not opt-out.

However, the comparison should be symmetric.

Many REST frameworks also ship with limited security controls enabled by default. Express.js , a minimal web framework, does not include rate limiting or input validation out of the box and relies on middleware for these concerns. Django REST Framework includes throttling features, but they are not enabled by default.

"Insecure defaults" is not a GraphQL-specific problem; it is a common pattern across web frameworks.

HTTP Behavior and Error Handling

Claim 15: "GraphQL returns HTTP 200 always, even when errors occur"

Verdict: Misleading framing.

This conflates GraphQL (the query language and execution engine) with one specific transport binding.

GraphQL is designed to be transport-independent. It runs over HTTP, WebSockets, Server-Sent Events, multipart responses, and other transport mechanisms. This is a deliberate architectural choice. GraphQL is similar to SQL in that it is a query language and does not dictate how queries are transported. You can run SQL over a TCP socket, a named pipe, or an HTTP API. GraphQL works the same way.

GraphQL reports errors in the response body's errors array rather than relying solely on transport-level status codes. A single GraphQL response can contain both data and errors, representing partial success.

The current working draft of the GraphQL specification defines this explicitly: a field that errors out returns null and adds an entry to the errors array, while sibling fields resolve successfully.

This is a defined behavior of the GraphQL execution model rather than a limitation. HTTP status codes do not cleanly express partial success: a request is typically represented as either 200 OK or 4xx/5xx, but not both.

GraphQL can tell a client "here's 90% of what you asked for, and here's exactly which field failed and why." In practice, many GraphQL-over-HTTP implementations return HTTP 200 responses with errors encoded in the response body. However, transport-level errors (e.g., invalid requests, authentication failures, or server errors) may still return appropriate non-200 status codes.

Under the commonly used application/json media type, the GraphQL-over-HTTP specification recommends returning 200 OK for any well‑formed GraphQL response, even when the errors field is populated. More nuanced status codes, including non-200 responses, are defined when using the application/graphql-response+json media type.

Claim 16: "The OWASP GraphQL Cheat Sheet reads like a confession of design decisions that were never made"

Verdict: Misleading framing (not unique to GraphQL).

The OWASP GraphQL Cheat Sheet documents standard security hardening practices, similar to other OWASP cheat sheets. But OWASP publishes similar cheat sheets for many technologies.

The REST Security Cheat Sheet covers input validation, output encoding, HTTPS enforcement, access control, rate limiting, and error handling. These are not defined by REST itself, but are implemented at the framework or application level. The REST Assessment Cheat Sheet goes further, documenting how to test REST APIs for vulnerabilities.

OWASP also publishes cheat sheets for Node.js , Django , Ruby on Rails , and dozens of other technologies.

Characterizing the GraphQL cheat sheet as a "confession" while ignoring equivalent guidance for REST can imply that GraphQL is uniquely insecure compared to other technologies. The existence of an OWASP cheat sheet reflects community attention to security and ecosystem maturity, rather than indicating an inherent design flaw in the technology itself.

Adoption and Tooling

Claim 17: "83% of web services use REST"

Verdict: Misleading framing (usage ≠ exclusivity).

The 83% figure is often attributed to the RapidAPI Developer Survey 2024, which other sources describe as measuring public APIs using REST, but I was not able to locate the original survey report directly. The Postman 2025 State of the API Report reports REST usage at 93% among surveyed developers, not 83%. Postman's survey allows multiple selections, so 93% reflects developers who use REST, not developers who use REST exclusively.

The same survey shows 33% of developers use GraphQL alongside REST, making it one of the most commonly used API styles in the survey. Multiple factors contribute to REST's widespread use beyond active evaluation:

Historical momentum: REST has been the default since the mid-2000s. Most APIs were built before GraphQL was available or widely adopted.
GraphQL adoption is increasing: Gartner has predicted that by 2027, more than 60% of enterprises will use GraphQL in production, up from less than 30% in 2024.
They coexist: Companies such as GitHub, Shopify, Netflix, Airbnb, Twitter, and The New York Times run GraphQL APIs in production, often alongside REST.

Using REST's market share as evidence against GraphQL reflects historical adoption patterns more than a direct comparison of technical fit or capability.

Claim 18: "REST with OpenAPI 3.0 offers self-documenting, typed client generation, HTTP caching built in"

Verdict: Misleading framing (omits comparable GraphQL capabilities).

Everything stated about OpenAPI is true. However, GraphQL has comparable capabilities in each area, with different trade-offs.

Self-documenting: A GraphQL server requires a GraphQL schema. The schema is not optional, not a nice-to-have, not a separate file you maintain on the side. It is a required part of the server.

GraphQL servers can expose their full type system through introspection , which lets any client query available types, fields, and arguments at runtime. Meta's engineering blog describes this as a core design goal: "Introspective: A GraphQL server can be queried for the types it supports."

With REST, an OpenAPI spec is optional. You often need to generate or maintain the spec separately and keep it in sync with your implementation. Some REST APIs still ship without a machine-readable description. An OpenAPI spec can drift from the implementation because they are separate artifacts.

In GraphQL, the schema is part of the server itself, which in practice can make drift much harder, because the schema is tied directly to the running implementation, though that is not guaranteed.

Typed client generation

GraphQL Codegen (by The Guild) and tools like genqlient produce compile-time validated, fully typed client code. GraphQL.org's blog documents that operation-based codegen produces types specific to each query, which can be more precise than endpoint-level types because you get types matching exactly the fields you requested.

OpenAPI also supports typed client generation, but typically relies on maintaining a separate specification. In many cases, OpenAPI-based clients are simpler to generate and require less build-time integration.

HTTP caching

As discussed in Claims 8-9, persisted queries can enable HTTP caching for GraphQL. And as discussed in Claim 5, REST's HTTP caching can be less effective for some relational or batch-style queries, which is the use case being compared.

By default, GraphQL does not align as directly with HTTP caching as REST.

Totals (by verdict): 3 confirmed, 6 partially true, and 9 misleading or incomplete.

In practice, REST remains a strong default for simpler, resource‑oriented services, while GraphQL shines in complex, client‑driven, multi‑resource scenarios. The best choice depends on the workload, not on which protocol is “better” in the abstract.

Part II: What the Evidence Means

This section is opinionated. Part I was about what the sources say. This part is about what I think it means for the industry based on my experience building API infrastructure for the past several years. Take it as one perspective among many.

Where REST Genuinely Wins

REST is the right choice for a lot of problems.

Simple CRUD with flat resources.
Public APIs where every resource has a stable URL.
Systems where HTTP caching on individual endpoints matters.
Scenarios where the data model is straightforward, and each client needs more or less the same response shape.

REST's ecosystem is mature, and every developer knows that. The tooling is battle-tested. OpenAPI provides typed client generation and machine-readable documentation. For these use cases, adding GraphQL would be adding complexity without proportional benefit.

If you have 12 REST endpoints serving flat resources to a single frontend, and your team is productive, keep what you have.

If you have a single frontend talking to a single backend, and both are TypeScript, do you need REST at all? Tools like tRPC give you end-to-end type safety with zero schema definition, no OpenAPI spec, and no code generation step. Just TypeScript functions on the server, typed calls on the client. For that specific architecture, tRPC is simpler than both REST and GraphQL. The "12 endpoints and a fetch() call" scenario might not need REST any more than it needs GraphQL.

Where GraphQL Genuinely Wins

The problems GraphQL was designed to solve are real, and REST still has no good answer for them.

Relational data across multiple sources. When a single client view needs data from users, orders, products, and reviews, GraphQL fetches it in one typed request. REST either makes multiple round-trips or requires purpose-built batch endpoints that are bespoke, uncacheable, and expensive to maintain.

Self-describing schemas and codegen. The GraphQL schema is the documentation. Because it is tightly coupled to the implementation, that makes drift much harder in practice. GraphQL Codegen produces compile-time validated, fully typed client code specific to each query. OpenAPI can do similar things, but requires maintaining a separate spec file.

Mobile and bandwidth-constrained clients. This is the original problem Facebook solved in 2012. Clients request exactly the fields they need. No over-fetching and no under-fetching. The peer-reviewed study by (Seabra et al. ) found that GraphQL improved performance in two out of three tested applications under moderate workloads, but it did not outperform REST consistently, especially under higher load.

GraphQL Federation Changes the Question Entirely

You may see the argument framed as "12 REST endpoints versus GraphQL complexity." That framing assumes your API surface stays small. For many organizations, it won't.

GraphQL Federation allows organizations to start with a single monolithic GraphQL API and gradually decompose it into independently owned subgraphs as teams grow. All subgraphs compose into a unified supergraph that clients consume as one schema.

Apollo Federation pioneered this pattern, and today multiple vendors provide production-ready Federation routers: Apollo Router (Rust), WunderGraph Cosmo Router (Go, open-source Apache 2.0), The Guild's Hive Gateway (TypeScript), ChilliCream's Hot Chocolate (C#/.NET), and AWS AppSync (managed service). Competition between vendors means teams have choices without being locked into a single provider.

The Composite Schemas Working Group , an official subcommittee of the GraphQL Foundation, is working to standardize how subgraph schemas compose into a unified API.

The specification defines vendor-neutral composition and distributed execution rules, so that subgraphs written against the spec work with any compliant router. This is Federation becoming an open standard, not a single vendor's product.

REST has no equivalent. When REST-based organizations need to compose multiple services behind a unified API, they choose between API Gateways (vendor-specific routing), BFF patterns (bespoke aggregation code per frontend), or OpenAPI merging (flat endpoint lists with no cross-service entity relationships). Each approach is proprietary, and none handles the question: "A User from Service A has Orders from Service B."

Federation answers that question by design.

And here is what I think many people miss: you can have Federation as the composition layer and REST as the consumption layer. Build a federated supergraph to unify APIs across teams. Then expose a REST API on top for clients that want it. This is a pattern we see growing in enterprise deployments. Federation and REST are not opposing choices. They operate at different levels of the stack.

AI Agents Need Structured, Self-Describing APIs

The API consumer is changing. Increasingly, the client calling your API is an AI agent , not a human developer reading docs.

Agents need to discover capabilities, understand types, and request specific fields, all within a limited context window. GraphQL's typed, introspectable schema was built for exactly this interaction pattern. An agent can query the schema to understand what's available, then construct a precise request for exactly the data it needs.

REST with OpenAPI can serve agents, too. But exposing thousands of REST endpoints to an agent overwhelms its context window. A structured graph lets agents search and select precisely what they need.

The industry is moving in this direction. The GraphQL AI Working Group is developing standards for how LLM agents interact with GraphQL APIs.

That said, AI agents will also call REST APIs. Tools like MCP are protocol-agnostic.

The question is how you organize your APIs so agents can find what they need. A federated supergraph provides that organization. A flat list of REST endpoints does not.

The Right Question Is Not Which One Wins

The REST vs. GraphQL debate keeps producing articles that pick one side and build the case. Some pick REST. Plenty of others pick GraphQL. Both sides select favorable benchmarks, ignore inconvenient tradeoffs, and declare the other technology dead or dying.

The evidence does not support either extreme.

REST at 93% adoption (Postman 2025 ) is not under threat from GraphQL. GraphQL, with Gartner predicting 60%+ enterprise adoption by 2027 and 33% of developers already using it alongside REST, is not a niche technology. They coexist because they solve different problems.

The right question is: what shape is your data, who are your consumers, and how will your API surface grow?

For public APIs where third-party developers need to integrate: REST. REST makes it easy to generate SDKs in any language, and every developer already knows how to call a REST endpoint. For flat resources, stable URLs, and simple CRUD: also REST. For a single TypeScript frontend and backend: maybe tRPC. For relational data, multiple consumers with different needs, and cross-team composition: GraphQL. For organizations scaling from one team to many: Federation. For all of the above at the same time: both.

The next time you read a blog post that makes specific technical claims about either technology (including one of my posts), check the sources. Read the original documentation. Look at the methodology behind the benchmarks. The evidence is out there. Use it.

This article was originally published on the WunderGraph blog.

How the Fission Algorithm Works: Top-Down GraphQL Federation Design

WunderGraph — Wed, 15 Apr 2026 17:53:42 +0000

TL;DR

Fission inverts GraphQL Federation. Instead of composing subgraphs into a supergraph, you design the supergraph first and Fission decomposes it into subgraph specs, handling entity keys, directives, and validation automatically.

In a previous post, I argued that Federation's composition model is backwards. It builds the supergraph from the bottom up when it should be designed from the top down.

This post is a technical deep dive into how the Fission algorithm actually does that.

The Problem Fission Solves

To understand Fission, first you need to understand what makes schema changes expensive in Federation.

Consider a federated graph with three subgraphs:

# Subgraph: Users
type User @key(fields: "id") {
  id: ID!
  name: String!
  email: String!
}

type Query {
  user(id: ID!): User
  users: [User!]!
}

# Subgraph: Orders
type User @key(fields: "id") {
  id: ID!
  orders: [Order!]!
}

type Order @key(fields: "id") {
  id: ID!
  total: Float!
  status: OrderStatus!
  createdAt: DateTime!
}

enum OrderStatus {
  PENDING
  SHIPPED
  DELIVERED
}

# Subgraph: Products
type Order @key(fields: "id") {
  id: ID!
  items: [OrderItem!]!
}

type OrderItem {
  product: Product!
  quantity: Int!
}

type Product @key(fields: "id") {
  id: ID!
  name: String!
  price: Float!
}

Composition produces a supergraph where you can query:

query {
  user(id: "1") {
    name
    orders {
      total
      status
      items {
        product {
          name
          price
        }
      }
    }
  }
}

Now a frontend team wants to add shipping tracking. This is their dream query:

query {
  user(id: "1") {
    orders {
      shipping {
        carrier
        trackingNumber
        estimatedDelivery
        currentLocation
      }
    }
  }
}

In the traditional workflow, the frontend team has to figure out:

shipping should be a field on Order, but which subgraph owns Order?
Both the Orders subgraph and the Products subgraph define Order as an entity.
carrier and trackingNumber come from the shipping provider.
estimatedDelivery might come from logistics.
currentLocation requires real-time tracking data.
Should this be a new subgraph? An extension of Orders? Both?

The frontend team can't answer these questions, so the platform team needs to be brought in. Meetings are scheduled and the process begins.

Fission automates the hardest parts of this process.

What Fission Actually Is

Before we walk through an example, it's important to understand what Fission is and what it isn't.

Fission is not just the opposite of composition, a batch algorithm that takes a supergraph and splits it into subgraphs. It's a stateful schema graph engine, an in-memory system that maintains two synchronized views of your federated graph at all times:

The supergraph view — the unified, consumer-facing schema. This is the canonical source of truth for what the API looks like.
The subgraph views — one per service, representing what each team is responsible for implementing.

These two views are kept in sync. When you make a change to either one, Fission will automatically propagate the consequences: renaming a type cascades to every subgraph and every field reference. Adding a type to a subgraph pulls in all its transitive dependencies. Entity @key directives propagate automatically.
@shareable directives are added bidirectionally when fields exist in multiple subgraphs.

Every edit follows the same pattern: validate first, mutate second, update indexes, and return a structured result. If validation fails, no state changes happen. This ensures you never have a half-applied edit.

The key insight is the synchronization contract:

The supergraph view represents the union of all subgraph views,
plus any types and fields not yet assigned to a subgraph.

This means the architect can design the complete API shape first and then decide how to distribute the implementation across subgraphs.

The supergraph doesn't have to be assembled from the bottom up.
It can be designed from the top down.

How It Works in Practice

Let's walk through the shipping example step by step.

Step 1: Design on the Supergraph

The architect adds the new types and fields directly on the supergraph:

# New additions to the supergraph
type Order @key(fields: "id") {
  id: ID!
  shipping: ShippingInfo! # new field
}

type ShippingInfo { # new type
  carrier: String!
  trackingNumber: String!
  estimatedDelivery: DateTime!
  currentLocation: String
}

At this point, ShippingInfo exists in the supergraph but isn't assigned to any subgraph yet. The shipping field on Order is defined but no team is responsible for implementing it.

The supergraph is the API you want.

Step 2: Assign to Subgraphs

The architect assigns the new type to an existing subgraph, or if necessary, creates a new one.

Let's say they assign ShippingInfo and the shipping field on Order to a new "Shipping" subgraph.

When this happens, Fission automatically does several things:

Transitive dependency propagation:
ShippingInfo references String, DateTime, and Boolean.
These are all scalars that are already available. But if ShippingInfo had a field like warehouse: Warehouse!, and the Warehouse type doesn't exist in the Shipping subgraph yet, Fission will automatically pull it in, along with anything Warehouse references. This propagation is cycle-safe; mutual type references don't cause infinite loops.

Entity key propagation:
Order is an entity with @key(fields: "id") in the Orders and Products subgraphs. When the Shipping subgraph extends Order, Fission automatically adds @key(fields: "id") to the Shipping subgraph's Order definition. The entity remains resolvable across subgraph boundaries.

Shareable propagation:
If the shipping field ends up defined in multiple V2 subgraphs, @shareable is added bidirectionally to all subgraphs containing that field, not just the new one. This ensures the rendered SDL is always valid for composition.

Step 3: Continuous Validation

Every edit is validated before it's applied.

Fission enforces a comprehensive set of invariants:

Reference integrity: you cannot remove a type that's still referenced by other fields. The error includes the exact coordinates that still reference it.
Last-child protection: you cannot remove the last field from a type that's still referenced elsewhere.
Key field validity: you cannot rename or change the type of a field that participates in a @key field set. The key selection tree would break.
Type-kind compatibility: you cannot have User as an Object in one subgraph and an Interface in another.
Interface consistency: when a type implements an interface, it must have all the interface's fields with compatible types.

If any validation fails, the edit is rejected and the state remains unchanged. The error message includes enough information for the Hub UI to show exactly what went wrong and suggest a fix.

Cascading Renames

Renaming is the most complex operation, and it's where Fission's
reference tracking really shines.

When a type is renamed at the supergraph level — say Order becomes CustomerOrder — Fission cascades the rename:

Every subgraph containing Order has its node renamed
Every field typed as Order or [Order!]! is updated
Every @key field set referencing Order is regenerated from its selection tree
Interface implementations and union memberships are updated
All reverse indexes are re-keyed

The SDL is not stored as text, it's regenerated from structured state. This means @key(fields: "id") always reflects the current field names. If you rename the id field to orderId, the key directive automatically becomes @key(fields: "orderId").

A Multi-Team Example

Let's trace through a more complex scenario to see how these steps work together.

Starting state: the three subgraphs from above (Users, Orders, Products).

Dream query:

query OrderDetails($orderId: ID!) {
  order(id: $orderId) {
    total
    status
    items {
      product {
        name
        price
        inventory {
          # new
          inStock
          warehouseLocation
        }
      }
    }
    shipping {
      # new
      carrier
      trackingNumber
      estimatedDelivery
    }
    payment {
      # new
      method
      last4
      receiptUrl
    }
  }
}

Three new capabilities: inventory, shipping, and payment.

Step 1: Design on the supergraph

The architect adds all new types and fields to the supergraph:

Product.inventory: InventoryInfo! (new field on existing entity)
InventoryInfo with inStock and warehouseLocation (new type)
Order.shipping: ShippingInfo! (new field on existing entity)
ShippingInfo with carrier, trackingNumber, estimatedDelivery (new type)
Order.payment: PaymentInfo! (new field on existing entity)
PaymentInfo with method, last4, receiptUrl (new type)
Query.order(id: ID!): Order (new root field)

At this point, the supergraph describes the ideal API. None of these new types are assigned to subgraphs yet.

Step 2: Assign to subgraphs

The architect assigns each new type to a subgraph on the Hub canvas:

New item	Assigned to	What Fission automates
`InventoryInfo` + `Product.inventory`	New Inventory subgraph	`Product @key(fields: "id")` is propagated to the Inventory subgraph. Product entity is automatically resolvable.
`ShippingInfo` + `Order.shipping`	New Shipping subgraph	`Order @key(fields: "id")` is propagated. If `ShippingInfo` referenced other types, they'd be pulled in transitively.
`PaymentInfo` + `Order.payment`	New Payments subgraph	`Order @key(fields: "id")` is propagated.
`Query.order`	Orders subgraph	Orders already owns the `Order` entity. Field is added, references are tracked.

The architect decides that Product.inventory goes to a new Inventory subgraph because the Products team doesn't have warehouse data.

Continuous validation

Every assignment is validated as it happens:

Entity keys are resolvable across the new subgraph boundaries
No type-kind conflicts (e.g., Order is an Object in all subgraphs)
Naming conventions pass (Hub's governance layer flags inStock — should it be isInStock? Architect approves the exception)
Reference integrity is maintained

If the architect tried to assign ShippingInfo to a subgraph in a way that would break composition, the edit would be rejected with a specific error before any state changes.

From Design to Subgraph Specs

At any point, Fission can render valid GraphQL SDL from structured state. This means the output reflects every cascading update, renamed field, and propagated directive.

Subgraph SDL Specifications

For each affected subgraph, Fission renders the exact SDL that the team needs to implement:

# New subgraph: Shipping
type Order @key(fields: "id") {
  id: ID!
  shipping: ShippingInfo!
}

type ShippingInfo {
  carrier: String!
  trackingNumber: String!
  estimatedDelivery: DateTime!
}

# New subgraph: Payments
type Order @key(fields: "id") {
  id: ID!
  payment: PaymentInfo!
}

type PaymentInfo {
  method: String!
  last4: String!
  receiptUrl: String!
}

# New subgraph: Inventory
type Product @key(fields: "id") {
  id: ID!
  inventory: InventoryInfo!
}

type InventoryInfo {
  inStock: Boolean!
  warehouseLocation: String!
}

# Modified subgraph: Orders (new root field)
type Query {
  order(id: ID!): Order # new
}

Each new subgraph automatically includes @key(fields: "id") on the entities it extends, because Fission propagated these from the existing subgraphs.

Supergraph Preview

Fission can also render the full supergraph SDL at any time. The architect can verify that the dream query will actually work before any code is written. Because the supergraph is the source of truth, not a composition result.

Design Decisions

A few architectural choices in Fission that are worth explaining:

The supergraph is the source of truth.
In traditional Federation, the supergraph is a side effect of composition. In Fission, it's the canonical representation. Removing a type from a subgraph does not remove it from the supergraph. You can design the complete API shape first, then decide how to distribute implementation. This is backwards from composition.

Fission automates consequences, not decisions.
The architect decides where types and fields belong. Fission automates everything that follows: transitive dependency propagation, entity key propagation, @shareable management, reference tracking, and cascading renames. The goal is to automate the mechanical work and surface the judgment calls to humans.

Validate first, mutate second.
Every edit validates all preconditions before making any state change. If validation fails, the state is unchanged. Because invalid states are caught at design time, the "composition fails after three teams implement their parts" scenario is prevented.

Federation directives are structured state, not text.
@key, @shareable, @inaccessible, @override, and @provides are modeled as structured state with their own selection trees, indexes, and validation rules. When you rename a field that participates in @key(fields: "id name"), the key field set is automatically updated.

Fission tracks the full lifecycle.
From proposal to review to implementation to composition, the entire workflow is tracked in one place. When a subgraph team ships their implementation, it's checked against the original specification. The proposal isn't complete until all specifications are met and the final composition succeeds.

The Bigger Picture

Fission is the algorithmic counterpart to Hub's collaboration model.

Hub provides the canvas, the collaboration workflow, and the governance layer. Fission provides the ability to take a high-level design intent and translate it into concrete, actionable subgraph specifications.

Together, they make it possible to design like a monolith and implement as microservices.

The supergraph is designed as a coherent whole. The implementation is distributed across teams. The algorithm handles the translation between the two.

If you want to see Fission in action, watch the webinar
or schedule a walkthrough.