DEV Community: WunderGraph

AI governance: 11 laws, frameworks, and assurance schemes—and 3 jobs they serve.

WunderGraph — Mon, 28 Sep 2026 14:31:49 +0000

TL;DR

The EU AI Act delayed its high-risk-system duties (Chapter III) to December 2, 2027 for standalone systems and August 2, 2028 for systems inside regulated products. That delay does not pause the rest of the Act. AI literacy and the original Article 5 bans have applied since February 2, 2025; GPAI provider duties since August 2, 2025; and most Article 50 transparency duties (disclose the chatbot, mark synthetic content, notify about emotion recognition) from August 2, 2026. A ninth banned-practice category, Article 5(1) points (ba) and (bb), arrives December 2, 2026. The surrounding laws, frameworks, and assurance schemes do three different jobs, and a certificate in one does not establish compliance in another. ISO 42001 certification, by itself, is not EU AI Act compliance.

Deferred, not cancelled

On August 2, 2026, many EU AI Act provisions began to apply. High-risk systems were the exception.

The Digital Omnibus on AI (Regulation (EU) 2026/1744 ) deferred the core Chapter III duties for high-risk AI systems. Standalone high-risk use cases (Annex III) now apply from December 2, 2027. High-risk AI embedded in already-regulated products (Annex I) now applies from August 2, 2028. The delay is real. It is not a general pause on the Act 2 33.

The Omnibus got its final Council green light on June 29, 2026 1, was dated July 8, published in the Official Journal on July 24, and entered into force July 27, 2026 2.

The Digital Omnibus on AI pushed both Chapter III high-risk deadlines back. That deferral is limited to Chapter III. The Omnibus also makes other, non-deferral changes elsewhere in the Act.

The Commission wanted the delay to start only once the supporting harmonised standards, or other support tools, were ready; however, co-legislators dropped that and locked the dates. December 2, 2027 arrives whether or not anything has been cited in the Official Journal 2 5 6.

What's delayed

High-risk standalone systems (Annex III): December 2, 2027
High-risk systems inside regulated products (Annex I): August 2, 2028
National AI sandboxes (Article 57): August 2, 2027

What's already on the clock

Original Article 5 bans and AI literacy: since February 2, 2025
GPAI provider duties: since August 2, 2025
Most Article 50 transparency duties (chatbots, synthetic-content marking, emotion-recognition notices): August 2, 2026
Ninth banned-practice category (intimate imagery / CSAM): December 2, 2026
GPAI models already placed on the market before August 2, 2025: comply by August 2, 2027

Who it still reaches

If you stop at the delay, you will feel like you can relax. Don't.

The Act is not only for companies headquartered in the EU. It can apply to providers placing AI systems or GPAI models on the EU market, deployers using systems in the EU, and certain providers or deployers outside the EU where an AI system's output is used in the Union. Headquarters is not the test; scope stays subject to Article 2 's exclusions, and it depends on the facts of the system and how it is used 3. Those exclusions cover systems used exclusively for national security, military, or defence purposes; purely personal, non-professional use; and some open-source releases.

What else the Omnibus changed

Most of the Article 50 transparency duties applied from August 2, 2026: disclose the chatbot, mark the synthetic content, and notify people about emotion recognition 2 33.

From December 2, 2026, a ninth banned-practice category arrives (Article 5(1) points (ba) and (bb)): systems that generate or manipulate non-consensual intimate material of an identifiable person, or child sexual abuse material. That is not a blanket ban on generative models. For providers, placing the system on the market or putting it into service is prohibited only where that generation or manipulation is the system's intended purpose, or a reasonably foreseeable and reproducible outcome without adequate safeguards. For deployers, use is prohibited only where they use the system for that purpose 2.

One other grace period: if you are a provider of an AI system — including a general-purpose AI system — that generates synthetic audio, image, video, or text, and you placed it on the market before August 2, 2026, new Article 111(4) gives you until December 2, 2026 to comply with Article 50(2)'s machine-readable marking obligation. It does not delay the rest of Article 50 2.

Penalties follow the duty

No published analysis of the Omnibus reports a change to the Act's maximum penalty tiers (Article 99). A penalty can follow only once the underlying duty applies. The original Article 5 bans have been enforceable since February 2, 2025; the new Article 5(1) points (ba) and (bb) apply from December 2, 2026; and the deferred Chapter III duties apply on their new 2027 and 2028 dates 2 3.

The caps themselves still sit where they did:

Article 5 prohibitions: up to €35M or 7% of global turnover
Most other violations: up to €15M or 3%
Incorrect, incomplete, or misleading information: up to €7.5M or 1%

Whichever is higher in each case, unless you are an SME or a small mid-cap 3. The deferral buys time to build high-risk systems but won't pardon what's already been banned.

The AI Office's bigger beat

The Omnibus also expands and centralizes some of the EU AI Office's market-surveillance and enforcement powers. Amended Article 75(1) makes the Office the only competent enforcer (exclusively competent) in two cases:

The same provider built both the general-purpose model and the system sitting on top of it, or two providers in the same undertaking (the same economic group) did.
The AI system constitutes, or is integrated into, a very large online platform or search engine designated under the Digital Services Act.

That exclusive competence covers the providers of those systems. It covers deployers only when they are also the provider, or form part of the same undertaking 2.

The Office's powers sit in Articles 75a to 75d: it can supervise and investigate, accept binding commitments, run a non-compliance procedure, and, under Article 75c(5), impose periodic penalty payments of up to 5% of average daily income or worldwide annual turnover in the preceding financial year, per day, to compel specified actions such as answering an information request or allowing an inspection 2.

National authorities still handle everything outside that slice, including Annex I product systems, certain Annex III cases, and specified law-enforcement, border, financial, and justice systems. This is a new lever, not a delayed one.

How Anthropic implements the marking rule

Anthropic announced that Claude models launched on or after August 2, 2026 will carry machine-readable markings from launch : an imperceptible text watermark, plus C2PA-signed provenance metadata for PNG, JPG, and SVG. Anthropic says the text watermark travels with copied-and-pasted text and can survive some edits. They are also working to retrofit older models during the transition period, across supported Claude surfaces worldwide 7 8.

Anthropic released a Claude content checker . It reads C2PA credentials in files 32; text-watermark detection is a separate API, in private preview to eligible organizations 7.

A detected mark is evidence that Claude may have processed content, not proof that Claude authored it. The absence of a detectable mark does not establish human authorship. Anthropic lists five reasons a mark may not show up: the model predates marking support; the text was heavily edited, paraphrased, translated, or mixed into other writing; the passage is too short to carry a reliable signal; the file's metadata was stripped by format conversion, re-saving, a screenshot, or some other means; or the content came from a platform, feature, or file type where that marking type isn't supported 7 8.

GPAI, "safety components," and systems already in the field

Two nearer dates survived the Omnibus untouched. General-purpose AI models placed on the market before August 2, 2025 still have to comply by August 2, 2027, which lands before either deferred high-risk date 3.

New Article 6(1a) to (1c) also narrows what counts as a safety component, so some Annex I systems drop out of high-risk altogether rather than getting more time:

6(1a): systems used solely for non-safety-related user assistance, performance optimisation, service efficiency, automation, convenience, or quality control are out.
6(1b): if the system's failure or malfunctioning would endanger health and safety, it still qualifies, even with that carve-out.
6(1c): if a product only has to go through third-party assessment for other risks — in particular radio-spectrum or electromagnetic-interference risks that do not affect health and safety — that does not, by itself, meet the Article 6(1)(b) condition for treating it as high-risk 2.

If a provider treats an Annex III system as not high-risk under the Article 6(3) exception (the derogation), Article 6(4) still requires documenting that assessment before placing the system on the market or putting it into service, and registering it in the EU database (Article 49(2)) 2 3. That is not a universal registration duty. It applies to that classification route. The Commission proposed narrowing it; Council and Parliament kept the documentation and registration. The Omnibus only trims the filing by deleting Annex VIII, section B, points 7 and 9 2 6.

Article 111(2) kept its shape, with one change. It applies to operators of high-risk systems already placed on the market or put into service before Chapter III starts to apply — but only if, from that date, those systems undergo significant changes in their designs. The cutoff is no longer a fixed August 2, 2026. It now tracks when Chapter III applies: December 2, 2027 for Annex III, August 2, 2028 for Annex I. Providers and deployers of high-risk systems intended for public authorities must still take the necessary steps to comply by August 2, 2030 2 3. If your estate is legacy or public-sector, those are your dates.

None of these dates matter without a record of who changed what and when. That record has to live somewhere, and it's usually not where teams think to look.

The deadline is only one document. Around it sit eleven overlapping laws, frameworks, and assurance schemes from different bodies. Most of them landed or were revised in the last two years.

Three jobs, not eleven labels

Stop focusing on the framework and start with the job. There are three:

These 11 laws, frameworks, and assurance schemes collapse into three jobs: prove it, defend it, build it.

The expensive mistake is assuming a certificate in one satisfies another. All three jobs eventually need evidence from somewhere: who touched what, when, and who approved it.

Three artifacts sit on more than one line:

CSA AICM is a security-and-governance control framework. Its associated AI-CAIQ supports self-assessment and third-party evaluation, and CSA provides materials for STAR for AI Level 1 submissions 15.
NIST AI 600-1 reads as security content but sits inside a governance framework.
AIUC-1 is a procurement instrument wearing security clothing. A consortium contributed the controls, but the publisher is an AI underwriting company, which is the tell.

The reference table

The Reference Table - Google Sheets

docs.google.com

"How you prove it" describes how each item is evidenced, not a common certification type. Cost: 🟢 free, 🟠 paid, ⚪ undisclosed.

The first certification body ANAB-accredited to audit ISO 42001 was Schellman, in September 2024 30. ISO/IEC 42006:2025 followed in July 2025 and set requirements specific to AI-management-system auditors 11. The accredited-auditor pool is barely two years old, and ANAB is one accreditation body among several. Check your certification body's accreditation, and its queue, before you commit to a date.

The most expensive misconception

"We're ISO 42001 certified, so we're EU AI Act compliant."

CSA's April 2026 analysis says it directly: "ISO/IEC 42001 alone does not satisfy the EU AI Act, despite frequent industry shorthand to the contrary." That is CSA's reading, not an EU regulator's formal ruling 9.

ISO 42001 certification is meaningful evidence that an organization operates an AI management system. It is not, on its own, a finding that every AI system the organization provides or deploys meets the EU AI Act. The Act still wants several things at once, at more than one level: classify the system, document it, manage its risks, govern its data, log it, be transparent, keep human oversight in place, watch it after it ships (post-market monitoring), and, where it applies, run a conformity assessment. On top of that sit organization-level quality-management-system duties under Article 17 3 9.

CSA lists the gaps: no per-system regulatory compliance strategy mapping, no pre-determined change management for continuous-learning systems under Article 17(1)(a), no Article 73 serious-incident reporting timetable, generic rather than AI-specific supply-chain provisions, and no structured fundamental-rights consideration, particularly the Article 27 impact assessment certain deployers owe 3 9.

Those missing clocks matter. Under Article 73, providers of high-risk systems report immediately after establishing a causal link, or a reasonable likelihood of one, and in any event within 15 days of the provider or, where applicable, the deployer becoming aware. That clock is two days for a widespread infringement or a serious incident involving critical infrastructure as defined in Article 3(49)(b). Where a death is involved, the report is due immediately after establishing or suspecting a causal relationship, and not later than 10 days after becoming aware 3.

ISO 42001 does not create a presumption of conformity with the Act. Under Article 40, only a harmonised standard cited in the EU Official Journal does that 3 9. The candidate is EN 18286 from CEN-CENELEC JTC 21, published as EN 18286:2026, the first European standard supporting AI Act implementation, covering the Article 17 quality management system for high-risk systems 13. Until a harmonised standard is cited in the Official Journal, a provider audited under ISO 42001 alone will, in CSA's words, "face open questions about whether each of the thirteen Article 17 elements is sufficiently covered, and the answers depend on the auditor's interpretation." 9

Other misconceptions

A taxonomy is not a control set. OWASP Top 10 is not, by itself, a certification or regulatory compliance regime. Name the risks and mitigations you have addressed; the lists name failure modes, not an auditable program 16 17.
NIST AI RMF is not certifiable. Vendors claim "NIST AI RMF compliance" routinely. No such scheme exists. The July 2025 White House AI Action Plan directed a revision of 1.0, but there is no public draft yet 20.
ATLAS is the attacker's view, not a checklist. It catalogs adversary techniques. Useful for red teams, wrong as a compliance to-do list 18.
COSAiS is not a finished control overlay. It is useful for tracking NIST's direction and for federal-aligned planning. There is an August 2025 concept paper and a January 8, 2026 annotated outline covering one of five planned use cases. No finished overlay has been published 22 23.

Where the crosswalks actually exist

Official and real: CSA ships AICM-to-everything mappings with the v1.1 download: ISO 42001, NIST AI RMF, NIST AI 600-1, EU AI Act, BSI AIC4, and AIUC-1, each with a gap analysis, in five mappings (the two NIST crosswalks ship as one) 14 15. OWASP says its LLM Top 10 2026 maps to NIST, MITRE ATLAS, CWE, and its own Agentic Top 10 16. On September 1, 2026, it went further and published a standalone GenAI Security Industry Framework Crosswalk: 51 GenAI vulnerabilities mapped across 25 frameworks, among them ISO 42001, NIST AI RMF, the EU AI Act, MITRE ATLAS, and SOC 2's Trust Services Criteria, free under CC BY-SA 4.0 31.

Hosted by NIST, authored by a vendor: the NIST AI RMF to ISO 42001 crosswalk on NIST's site is credited to Microsoft, not NIST. It's still useful; know what it is 24.

Stale: NIST's own EU mapping sits inside its OECD/EU/EO13960 crosswalk, dated January 26, 2023, and it maps the 2021 proposal, superseded by Regulation (EU) 2024/1689 [24](Stale: NIST's own EU mapping sits inside its OECD/EU/EO13960 crosswalk, dated January 26, 2023, and it maps the 2021 proposal, superseded by Regulation (EU) 2024/1689 24.

Not published by AICPA: ISO 42001 to SOC 2. AICPA's Trust Services Criteria mapping page lists no AI, ISO 42001, or NIST AI RMF mapping at all, and does not name the other mappings it offers on the public page 25 26. There is also no AI-specific SOC 2; teams typically map AI controls into the common criteria and the Processing Integrity category.

CSA AICM maps to six other frameworks in five mappings, each with a gap analysis. The dashed lines are the stale or vendor-authored crosswalks; AICPA publishes no AI mapping for SOC 2.

Where to start

We found no standards body that publishes a "start here" recommendation. Every prescriptive starting-point claim we did find came from a vendor with a product to sell. So treat this as our editorial judgment:

Where to start, in order: two free frameworks now, then NIST AI RMF, ISO 42001, EU AI Act Chapter III, COSAiS for horizon scanning, and AIUC-1 only when it applies to you.

What the API layer contributes

These frameworks define the controls and evidence an organization needs. They don't tell engineering how to produce that evidence. That gap is where the API layer matters. A federated graph records which services expose which data, how schemas change, and who approves those changes. Where identity, access controls, and audit logging are configured, it records who changed the graph; client identification labels requests with the client name and version the caller sends 27.

Hub governs the workflow around the graph. Where proposal checks and ownership are enabled, checks run before a proposal ships, and type and subgraph ownership decides who signs off, with graph admins able to approve anything 28. Where configured, Cosmo's graph pruning flags fields deleted without being deprecated first, on a configurable grace period, and a separate operations check fails a deletion while real client traffic still uses the field 29. The result is an approval and change history teams can inspect later.

Cosmo is not an AI-governance product and should not be positioned as one. It can contribute evidence by governing the APIs, schemas, access paths, change approvals, and client traffic an AI-enabled application uses. Whether that evidence is sufficient depends on the applicable system, role, risk classification, and control requirement.

References

Sources verified September 4, 2026; corrections re-verified September 8, 2026.

[1] Council of the EU. "Artificial intelligence: Council gives final green light to simplify and streamline rules." Press release, 29 June 2026.

[2] EUR-Lex. "Regulation (EU) 2026/1744 of 8 July 2026 (Digital Omnibus on AI), amending Regulation (EU) 2024/1689." In force 27 July 2026. Cited for the amended wording of Articles 5, 6, 57, 75 to 75d, 99, 111 and 113, and Annex VIII.

[3] EUR-Lex. "Regulation (EU) 2024/1689 (AI Act)." Articles 2, 4, 5, 6, 17, 27, 40, 43, 49, 50, 73, 99, 111.

[4] Cloud Security Alliance. "EU AI Act's High-Risk Deadline: Deferred, Not Cancelled." 1 August 2026. Interpretation and practical context, not a substitute for the amending regulation.

[5] Gibson Dunn. "EU AI Act Omnibus Agreement: Postponed High-Risk Deadlines and Other Key Changes." 27 May 2026, pre-adoption analysis, used for legislative-history context only.

[6] Cooley. "Digital AI Omnibus Delays Key Deadlines, Introduces New Rules." 3 August 2026, used for legislative-history context only.

[7] Anthropic. "How Claude's text watermark works."

[8] Anthropic. "How Claude marks AI-generated content."

[9] Cloud Security Alliance. "EU AI Act Compliance: prEN 18286 and ISO 42001." 28 April 2026. CSA's analysis of the ISO 42001 / AI Act relationship, not an EU regulator's ruling.

[10] ISO/IEC 42001:2023, "Information technology. Artificial intelligence. Management system." Published December 2023, edition 1, CHF 225.

[11] ISO/IEC 42006:2025, "Requirements for bodies providing audit and certification of artificial intelligence management systems." Published July 2025.

[12] Vanta. "ISO 42001 certification costs: A structural breakdown." Vendor estimate, cited as illustrative only.

[13] CEN-CENELEC. "EN 18286 in the spotlight: supporting compliance with the AI Act." 31 July 2026.

[14] Cloud Security Alliance. "AI Controls Matrix v1.1: Strengthening the Foundation for Trustworthy AI." 14 July 2026.

[15] Cloud Security Alliance. "AI Controls Matrix v1.1" artifact and mapping bundle.

[16] OWASP GenAI Security Project. "OWASP GenAI LLM Top 10 2026." Released 3 August 2026, CC BY-SA 4.0.

[17] OWASP GenAI Security Project. "OWASP Top 10 for Agentic Applications." 9 December 2025.

[18] MITRE ATLAS. atlas-data releases, v2026.05, 27 May 2026

[19] Cloud Security Alliance. "Cloud Security Alliance Extends AI Assurance Leadership Into Agentic AI With Addition of AIUC-1 Certification to STAR Registry." 30 June 2026.

[20] NIST. "AI Risk Management Framework (AI RMF 1.0)." January 2023. Revision directed by the White House "America's AI Action Plan" , July 2025.

[21] NIST AI 600-1. "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile." July 2024.

[22] NIST CSRC. "SP 800-53 Control Overlays for Securing AI Systems (COSAiS): publications." Annotated outline, 8 January 2026.

[23] NIST CSRC. "COSAiS use cases."

[24] NIST AIRC. "Crosswalks to the NIST AI Risk Management Framework (AI RMF 1.0)."

[25] AICPA & CIMA. "2017 Trust Services Criteria (with revised points of focus, 2022)."

[26] AICPA & CIMA. "Get mappings relevant to the trust services criteria."

[27] WunderGraph Cosmo docs. "Security and compliance" , "RBAC" , "Groups" , "SSO" , "Audit log" , "Changelog" , and "Client identification"

[28] WunderGraph Hub docs. "Propose and review" and "Assign ownership"

[29] WunderGraph Cosmo docs. "Graph pruning" — deprecation-before-deletion and grace periods — and "Schema checks" — the operations check against client traffic, 7-day default window, configurable per namespace.

[30] Schellman. "Schellman Becomes First ISO 42001 ANAB Accredited Certification Body." 24 September 2024.

[31] OWASP GenAI Security Project. "GenAI Security Industry Framework Crosswalk." Released 1 September 2026, CC BY-SA 4.0.

[32] Anthropic. "Check if a file was made with Claude."

[33] European Commission. "AI Act." Shaping Europe's digital future. Last update 3 August 2026.

Understanding the N+1 Problem in GraphQL (and Why It’s Not Just GraphQL)

WunderGraph — Wed, 29 Jul 2026 23:02:05 +0000

TL;DR

The N+1 problem is a general data-access anti-pattern that can appear in REST, resolver-based GraphQL, and federated GraphQL at different layers of the stack. WunderGraph’s breadth-first loading approach can help batch cross-subgraph work at the router layer, but it does not remove the need for batching inside subgraphs. Even when the router batches entity references, a subgraph can still reintroduce N+1 if its reference resolvers fetch one record at a time. DataLoader is a common resolver-level fix that provides scheduling-window batching plus request-scoped caching, but joins, eager loading, denormalized views, or a single set-based query can be better when the access pattern is predictable. Detection usually means correlating a GraphQL operation with repeated backend calls using database logs, traces, or APM tools. Traces may surface symptoms before they identify the root cause.

A single API request can quietly fan out into hundreds of backend calls. That is the N+1 problem, and it shows up in REST, monolithic GraphQL, and federated GraphQL alike. The shape is the same in each case. What changes is where the repeated work lands — on the client, at the router, inside a subgraph, or in the database.

This post expands on Claim 4 from our GraphQL vs REST fact-check , which argued that different API styles do not eliminate complexity. They move it to different layers. N+1 is one of the clearest examples: in REST it often appears as many client-side requests, in GraphQL as resolver fan-out inside a single operation, and in federation as work distributed across router and subgraph layers.

You can read more about this shift in Where Does API Complexity Live?

What the N+1 Problem Is

The N+1 pattern is one query to fetch a list, plus one additional query per item to fetch related data. A single GraphQL operation can trigger one backend call or hundreds, depending on how resolvers are implemented.

The N+1 problem happens when your API fetches a list of items using one query, and then issues an additional query for each item in the list.2

In resolver-based GraphQL servers, execution does not automatically batch sibling field resolvers, so repeated data access can be introduced easily and the cost of each field's fetch isn't coordinated by default. 2 The same pattern can appear in REST clients, ORMs, and batch APIs whenever related data is loaded one item at a time instead of via set-based operations.3 4

A Concrete N+1 Example in Monolithic GraphQL

A common example is a User type with a one-to-many posts field. A naive implementation wires two resolvers:

Query.users runs SELECT * FROM posts WHERE user_id = ? once per user (N queries).

For 50 users, the server issues 51 backend calls.

Here's what that looks like in code — and how DataLoader can fix it:

// import DataLoader from 'dataloader';

// Naive resolvers (N+1)
const resolvers = {
  Query: {
    users: () => db.users.findAll(), // 1 query
  },
  User: {
    posts: (user) =>
      db.posts.findAllByUserId(user.id), // N queries
  },
};

// Batching with DataLoader (request-scoped)
const createPostsLoader = () =>
  new DataLoader(async (userIds) => {
    const posts = await db.posts.findAllByUserIds(userIds); // 1 batched lookup

    const postsByUserId = new Map();

    for (const post of posts) {
      const list = postsByUserId.get(post.userId) ?? [];
      list.push(post);
      postsByUserId.set(post.userId, list);
    }

    return userIds.map((id) => postsByUserId.get(id) ?? []);
  });

// createContext runs per request, not once globally
const createContext = () => ({
  postsLoader: createPostsLoader(),
});

const resolversWithLoader = {
  Query: {
    users: () => db.users.findAll(),
  },
  User: {
    posts: (user, _, ctx) => ctx.postsLoader.load(user.id),
  },
};

With a request-scoped DataLoader, those 50 User.posts resolver calls can be batched into one posts lookup, reducing the backend work from 51 calls to 2: one call for users and one call for posts.

The N+1 Problem in GraphQL Federation

N+1 in federated GraphQL is easy to misread as a gateway problem. WunderGraph’s breadth-first loading approach can help batch cross-subgraph work at the router layer, but it does not remove the need for batching inside subgraphs. Even when the router batches entity references, a subgraph can still reintroduce N+1 if its reference resolvers fetch one record at a time, for example when __resolveReference or nested resolvers fan out per entity.

Understanding the GraphQL federation N+1 problem requires separating two concerns: router vs subgraph batching.

Router layer. When Cosmo Router resolves a federated query, it may send a batch of entity representations to a subgraph in a single request (the _entities query). WunderGraph’s breadth-first loading approach is one implementation strategy.
Subgraph layer. Inside the subgraph, __resolveReference resolves entity references, but whether those references are processed efficiently depends on the subgraph’s implementation. If the resolver performs a datastore lookup per entity representation rather than batching those lookups, the subgraph reintroduces N+1 even though the router sent a single batched request.

Cross-subgraph dependencies via @requires can increase the amount of coordinated work. When a field in one subgraph depends on data from another, the router fetches the required fields first and passes them to the dependent subgraph as part of the entity representation. Each hop is a chance for subgraph-internal N+1 if reference resolvers aren't batched. A query that crosses multiple subgraphs can still generate many backend calls if each __resolveReference or nested resolver performs single-row lookups.

A federated N+1 example

Here's the pattern in concrete terms. An accounts subgraph owns User, and a posts subgraph owns Post:

# accounts subgraph: owns User
type User @key(fields: "id") {
  id: ID!
  name: String!
}

# posts subgraph: owns Post and contributes User.posts
type Post {
  id: ID!
  title: String!
  author: User!
}

type User @key(fields: "id") {
  id: ID!
  posts: [Post!]!
}

The posts subgraph contributes the posts field to the User entity, so it resolves that field even though accounts owns the rest of User. When a client queries { users { posts { title } } }, the router fetches users from accounts, then sends a batch of user representations to posts to resolve their posts. That batch arrives at the posts subgraph as a single _entities query.

The problem happens inside posts in this version:

// posts subgraph: naive User.posts resolver (N+1)
const resolvers = {
  User: {
    // called once per user in the batch, so N DB calls
    posts: (user) => db.posts.findAllByUserId(user.id),
  },
};

// posts subgraph: batched User.posts resolver (fixed)
const createPostsLoader = () =>
  new DataLoader(async (userIds) => {
    const posts = await db.posts.findAllByUserIds(userIds); // 1 batched lookup
    const byUser = new Map();
    for (const post of posts) {
      const list = byUser.get(post.userId) ?? [];
      list.push(post);
      byUser.set(post.userId, list);
    }
    return userIds.map((id) => byUser.get(id) ?? []);
  });

// in context factory (per request)
const resolversWithLoader = {
  User: {
    posts: (user, _args, ctx) => ctx.postsLoader.load(user.id),
  },
};

The router may look efficient because it sends a batched _entities request, but that does not guarantee efficient work inside the subgraph. The subgraph can still issue N DB calls unless the User.posts resolver uses a DataLoader or equivalent. The fix is the same as in monolithic GraphQL: batch at the layer where the repeated fetches actually happen, which in this case is inside the subgraph.

Why the N+1 Problem Actually Hurts

N+1 usually becomes a production problem when lists grow, traffic increases, or many requests hit the same resolver path at once. The extra calls compete for database connections, worker threads, and upstream service capacity.

In production, the failure mode is usually not just “one request got slower.” The extra calls can amplify tail latency, increase timeout rates, and put pressure on shared infrastructure.

Why N+1 Is Not Unique to GraphQL

N+1 is a data-fetching pattern: a similar “one request for the list, one request per item” shape can show up in plain SQL, ORMs, and REST clients as well as in GraphQL.

Plain SQL

const users = await db.query("SELECT id, name FROM users");

for (const user of users) {
  user.posts = await db.query(
    "SELECT id, title FROM posts WHERE user_id = ?",
    [user.id]
  );
}

This is the classic N+1 pattern in relational databases. It runs one query to fetch all users, then one additional query per user to fetch posts.

ORM with lazy loading

// Query 1: fetch all users
const users = await User.findMany();

for (const user of users) {
  // Hidden query per user: fetch posts for this one user
  console.log(user.name, await user.posts());
}

This looks clean, but a lazily loaded user.posts() can hide a separate query per user under the hood.

A client calling REST endpoints

// Request 1: fetch users
const users = await fetch("/api/users").then((res) => res.json());

const result = [];

for (const user of users) {
  // Hidden/accidental N requests: fetch posts once per user
  const posts = await fetch(`/api/users/${user.id}/posts`).then((res) =>
    res.json()
  );

  result.push({
    id: user.id,
    name: user.name,
    posts,
  });
}

Here the N+1 shows up as client-side REST calls instead of backend resolver calls: one request for the collection, then N requests for per-user posts. This is a similar N+1 shape to GraphQL; the difference is whether the fan-out happens on the client, in resolvers, or at another backend layer.

REST can exhibit the same anti-pattern when a client or backend issues one request for a collection and then one request per item, but that is an implementation pattern rather than a property of REST itself. REST can also hide the same pattern server-side when a gateway or backend endpoint fans out to fetch related records one at a time.4 In typical monolithic GraphQL servers, N+1 is hidden behind a single client request and shows up as backend fan‑out inside the resolver layer. Clients can also create an N+1 pattern by issuing multiple related operations instead of one broader operation, although the more characteristic GraphQL case is resolver-level backend fan-out. This pattern makes it easier to ship accidentally and harder to observe unless you are watching backend query counts, subgraph calls, traces, or APM data.

DataLoader Rules That Matter in Practice

Create loaders per request. Instantiate loaders inside the request context, not globally. GraphQL.js examples typically create loaders per request, and Netflix DGS documents its data loaders as request-scoped by default.2 5
Replace per-item fetches with .load(). In resolvers that fetch related data by key, call ctx.loader.load(id) instead of querying the database directly.
Issue related loads together. DataLoader provides scheduling-window batching plus request-scoped caching: it batches .load(id) calls issued within the same scheduling window and dispatches them together as a batch.6 Code can use .load() and still fail to batch if each load is awaited before the next one is issued. Use Promise.all(ids.map((id) => loader.load(id))) when loading multiple IDs in the same resolver. Awaiting each load before issuing the next one, including in a for-loop, usually prevents batching.
Return results in key order. The batch function receives an array of keys and must return results aligned to the input keys. Fetch by set, group the results, then map them back to the original key order, and choose a missing-value policy that fits your loader, such as null or an error.

Alternatives and Complements to DataLoader

DataLoader is a common resolver-level fix, but joins, eager loading, denormalized views, or a single set-based query can be better when the access pattern is predictable.

ORM eager loading. Many ORMs can fetch parents and children together using joins, subqueries, or select-in loading. This can replace per-row lazy loads without adding DataLoader to every resolver.

Set-based queries. For stable, read-heavy access patterns, a single set-based SQL query using joins, CTEs, or a denormalized view can be simpler and faster than a chain of DataLoaders. This fixes N+1 at the data-access layer instead of patching it at the resolver layer.

WunderGraph’s breadth-first loading. WunderGraph’s breadth-first loading can help batch cross-subgraph work at the router layer instead of every team wiring loaders by hand, but it does not remove the need for batching inside subgraphs.

If the data can be fetched efficiently in one set-based query, use the query. If the ORM can eager-load the relationship cleanly, use the ORM.

How Cosmo addresses this

Cosmo can address one class of N+1 problem at the router/planner layer by batching execution across subgraph boundaries, but that does not automatically eliminate N+1 inside subgraphs, where resolvers may still issue one datastore call per entity or rely on unbatched data access.

True N+1 detection still requires request traces, subgraph call counts, or backend query logs, even when router-level batching is in place, and even when planner-level algorithms reduce some categories of fan-out.

Learn more in our breadth-first data loading post .7

Detecting N+1 in Practice

Detecting N+1 is less about spotting GraphQL syntax and more about correlating one operation with the backend work it triggers. The clearest signal is the same backend call repeated many times with different IDs inside a single GraphQL operation.

Tracing and APM tools can show the same pattern from the request side: one GraphQL operation fans out into many database calls, REST calls, or subgraph requests. In federated graphs, subgraph request counts are especially useful because N+1 may appear at the router boundary, inside a subgraph, or both.

Specifically: a span pattern that scales linearly with entity count is a strong sign that reference resolution is still happening per entity. If query latency scales roughly linearly with list size, same problem. Router traces may still look fine at a glance, or only show indirect symptoms such as elevated latency or high subgraph span counts, while the exact per-entity fan-out stays hidden inside the subgraph.

Track tail latency and backend-call counts per operation where your telemetry supports it.

The Practical Takeaway

DataLoader is a common resolver-level fix: joins, eager loading, denormalized views, or a single set-based query can be better when the access pattern is predictable; WunderGraph’s breadth-first loading can reduce cross-subgraph fan-out as a complement.1 7
**Federation can move N+1 to a different layer, so router-level batching and subgraph-level batching both matter. **Even when the router batches entity references, a subgraph can still reintroduce N+1 if its reference resolvers fetch one record at a time.1
In resolver-based GraphQL servers, the default execution model makes N+1 easy to introduce, not inevitable. Avoiding it requires deliberate choices at the resolver, data-access, or planner layer.

That is the real answer to Claim 4 in our GraphQL vs REST fact-check: GraphQL can make N+1 easier to create, but the fix is not “use REST.” The fix is usually to batch or reshape data access at the layer where the repeated work is created, and to be explicit about which layer owns that work, as we argue in the API complexity post.

Originally published on the WunderGraph publications:
https://wundergraph.com/blog/graphql-n-plus-1-problem

References

[1] Apollo GraphQL. "Handling the N+1 Problem." https://www.apollographql.com/docs/graphos/schema-design/guides/handling-n-plus-one

[2] GraphQL.js. "Solving the N+1 Problem with DataLoader." https://www.graphql-js.org/docs/n1-dataloader/

[3] REST API Tutorial. "What is N+1 Problem in REST?" https://restfulapi.net/rest-api-n-1-problem/

[4] Kheyrollahi, A. "Web APIs and the n+1 Problem." InfoQ. https://www.infoq.com/articles/N-Plus-1/

[5] Netflix DGS Framework. "Data Loaders (N+1)." https://netflix.github.io/dgs/data-loaders/

[6] GraphQL Foundation. "DataLoader" (reference implementation). https://github.com/graphql/dataloader

[7] WunderGraph. "Dataloader 3.0: A new algorithm to solve the N+1 Problem." https://wundergraph.com/blog/dataloader_3_0_breadth_first_data_loading

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.

DEV Community: WunderGraph

AI governance: 11 laws, frameworks, and assurance schemes—and 3 jobs they serve.

TL;DR

Deferred, not cancelled

What's delayed

What's already on the clock

Who it still reaches

What else the Omnibus changed

Penalties follow the duty

The AI Office's bigger beat

How Anthropic implements the marking rule

GPAI, "safety components," and systems already in the field

Three jobs, not eleven labels

The Reference Table - Google Sheets

The most expensive misconception

"We're ISO 42001 certified, so we're EU AI Act compliant."

Other misconceptions

Where the crosswalks actually exist

Where to start

What the API layer contributes

Related reading

References

Understanding the N+1 Problem in GraphQL (and Why It’s Not Just GraphQL)

TL;DR

What the N+1 Problem Is

A Concrete N+1 Example in Monolithic GraphQL

The N+1 Problem in GraphQL Federation

A federated N+1 example

Why the N+1 Problem Actually Hurts

Why N+1 Is Not Unique to GraphQL

Plain SQL

ORM with lazy loading

A client calling REST endpoints

DataLoader Rules That Matter in Practice

Alternatives and Complements to DataLoader

How Cosmo addresses this

Detecting N+1 in Practice

The Practical Takeaway

References

The Three Bottlenecks AI Can't Code Away

Why AI Coding Tools Aren't Making Engineering Teams Faster

How API Coordination Becomes the Bottleneck in Large Engineering Orgs

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

Why AI-Generated Code Is Slowing Down Code Review

How GraphQL Federation Solves Coordination, Governance, and Review

When You Don't Need GraphQL Federation

How to Get the 10x Productivity Gain from AI

Where Does API Complexity Live?

The Scenario

How do API architectures handle data from multiple services?

REST

Why does REST push data fetching to the client?

How does REST handle caching and security?

Why are contract management and governance fragmented in REST?

GraphQL

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

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

Why can GraphQL governance become a bottleneck?

Federated GraphQL

Why does GraphQL federation introduce new complexity?

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

Why does federation create a governance bottleneck?

Fission

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

How does Fission reduce governance overhead?

What new complexity does Fission introduce?

The Responsibility Map

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

Responsibility Map - Google Sheets

Why doesn't any API architecture eliminate complexity?

What This Means

Which API architecture is the best choice?

What is the real question behind REST vs GraphQL?

How WunderGraph Helps

References

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

Disclaimer

Summary

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

Part I: What the Evidence Says