GraphQL Stacks 2026 — Deep Dive into Apollo Router, Hasura, GraphQL Yoga, Relay, urql, Hot Chocolate, gqlgen, Strawberry, WunderGraph

Prologue — Is GraphQL Dead in 2026?

In 2023, GitHub backed away from GraphQL toward REST in places, and through 2024 a "GraphQL is dead" blog hit the front page about once a month. Yet in 2026, GraphQL is not dead. Far from it — Apollo acquired Stellate, WunderGraph shipped Cosmo Router, Inigo and Grafbase carved out a gateway-as-a-service market, and Mercari, Coupang, LINE Yahoo, Netflix, and GitHub's own internals continue to decompose monoliths through Federation.

GraphQL is not dead. It simply moved out of the "easy API" seat and into the "infrastructure for stitching giant distributed graphs together" seat. For small teams, tRPC is more natural. But organizations that need to express dozens or hundreds of microservices as one graph still pick GraphQL.

This article surveys every major player in the 2026 GraphQL ecosystem. Gateways, DB-first engines, server frameworks, clients, tools, standards, alternative technologies. With real adoption cases from Korean and Japanese companies.

What we cover:

1. The 2026 GraphQL map — who builds, who uses
2. The 2024-25 GraphQL spec and the Composite Schemas WG
3. The "Is GraphQL dead?" debate
4. Federation v2 vs Schema Stitching vs Module Federation
5. Apollo Router — the Rust rewrite of the Federation 2 gateway
6. Apollo Server 4 and Apollo Client 3.11+
7. GraphQL Yoga 5 — The Guild's batteries-included server
8. graphql-mesh and GraphQL Hive
9. Hasura v2 and PostGraphile 5 — the DB-first camp
10. Supabase GraphQL and WunderGraph
11. Stellate, Inigo, Cosmo, Grafbase — gateway wars
12. Relay 18, urql 4, Apollo Client 3.11 compared
13. GraphQL Code Generator and type safety
14. Node.js servers — Mercurius, Pothos, NestJS, TypeGraphQL
15. Python — Strawberry, Ariadne, Graphene
16. Go — gqlgen, graphql-go
17. Rust — async-graphql, juniper
18. JVM, .NET, Ruby, Elixir, PHP, Swift
19. Subscriptions and graphql-ws
20. The N+1 problem and the DataLoader pattern
21. Persisted Queries and trusted operations
22. GraphQL vs REST vs tRPC vs gRPC
23. Korean and Japanese GraphQL adoption
24. References

1. The 2026 GraphQL Map

The big picture first. The tools around GraphQL split into five camps.

Gateway camp — routers that compose multiple subgraphs into a single graph. Apollo Router (Rust, Apollo), Cosmo Router (WunderGraph), Inigo, Stellate (Apollo subsidiary), Grafbase. Apollo Router is the de facto standard for Federation 2, but after its license shift to Elastic v2, Cosmo Router gained traction as the Apache-2.0 alternative.

Server framework camp — define a GraphQL schema and resolvers inside a single service. Apollo Server 4, GraphQL Yoga 5, Mercurius, NestJS GraphQL on Node. Strawberry and Ariadne on Python. gqlgen on Go. Hot Chocolate on .NET. graphql-ruby on Ruby. Absinthe on Elixir.

DB-first camp — auto-generate a GraphQL schema from a database. Hasura v2, PostGraphile 5 (Benjie Gillam), Supabase GraphQL. They cut 90% of code in CRUD-heavy services.

Client camp — call GraphQL from browser or mobile. Apollo Client 3.11+ (market leader), Relay 18 (Meta), urql 4 (Formidable, now The Guild), graphql-request + TanStack Query (DIY), Houdini (SvelteKit). Apollo iOS and Apollo Kotlin own the mobile front.

Standards and tools camp — specs and governance. The GraphQL Foundation hosts the GraphQL WG and the Composite Schemas WG. The Guild ships Hive, Mesh, Tools, and Yoga Server as a coherent open-source bundle. Apollo acquired Stellate to seize the edge-cache market.

These five camps shift position every year, which is why the GraphQL ecosystem feels hard to follow.

2. The 2024-25 GraphQL Spec and Composite Schemas WG

The spec itself evolved conservatively between 2024 and 2025. The GraphQL 2024 release candidate (October 2024) consolidated a few things.

• @oneOf input objects — input types where the client must send exactly one field. A long-standing community pattern became a real directive.
• Client-controlled nullability — field! lets the client force non-null, and if the server returns null the client propagates the error to a nullable parent.
• defer / stream — streaming partial results. Reduces first-contentful-paint for heavy queries. Stabilized on both client and server through 2024-25.
• Subgraph composition — the Composite Schemas WG, set up under the GraphQL Foundation in 2025, is working to standardize Apollo Federation 2. WunderGraph, ChilliCream (Hot Chocolate), The Guild, and Apollo all participate.

What the Composite Schemas WG means: Federation 2 is no longer Apollo's private spec. This is why Cosmo Router can claim Federation 2 compatibility legitimately. As of 2026 the standards work is heading for 1.0, with formal adoption targeted in 2027.

3. The "Is GraphQL Dead?" Debate

Several events stacked up in 2023-24.

• GitHub moved some APIs back to REST (precisely: GraphQL was not removed but REST was reintroduced alongside). Reasons cited: cache efficiency on mobile clients, learning curve for third-party integrators.
• Shopify unified the Storefront API on GraphQL but stated it would maintain admin REST for "simple users".
• Inside Meta, as React Server Components landed, observers noted that RSC plus server actions can replace parts of the Relay-plus-GraphQL combo.
• tRPC moved fast in the Node.js full-stack space and emerged as the type-safe API alternative without GraphQL.

These currents converged into the perception that "GraphQL is dead". The reality looks different.

• In the enterprise it is still growing. Netflix DGS, Mercari Apollo Federation, GitHub's internal single graph, Coupang's ELK front, LINE Yahoo Hasura — all expanded between 2024 and 2026.
• Federation 2 became the de facto interface. Even teams that do not write GraphQL themselves often deploy API gateways built on Apollo Router.
• GraphQL moved from "easy API" to "distributed graph composition infrastructure". In that seat, REST, tRPC, and gRPC do not displace it.

Bottom line: GraphQL is not dead. It stepped down from "default option everywhere" to "the tool for a specific problem — composing a distributed graph". If you adopt GraphQL fresh in 2026, first confirm you are in that seat.

4. Federation v2 vs Schema Stitching vs Module Federation

Three ways to combine multiple subgraphs into one.

Schema Stitching (deprecated) — the Apollo Server 2-era approach. The gateway merges each service's schema and resolves conflicts with hand-written resolvers. Hard to operate, replaced by Federation 1, and effectively retired after Federation 2. Some Guild tooling (the stitching module in graphql-tools) is still alive in 2026.

Apollo Federation v1 — released in 2019. Subgraphs are defined with @key, @external, @requires, and @provides directives. The gateway builds a query plan and dispatches to subgraphs.

Apollo Federation v2 — GA in 2022. Cleaned up v1's pain points. Shared types (@shareable), interface objects (@interfaceObject), entry-point overrides (@override), shared input objects — patterns that were awkward in v1 are now standard. The de facto choice in 2026.

Module Federation (Webpack/Rspack) — the name overlaps but the concept does not. This is front-end micro-frontend bundle composition. Do not confuse it with GraphQL Federation.

The biggest decision when adopting Apollo Federation 2 is "how to slice subgraphs". Domain boundaries are the right axis, not data sources. Mercari initially split by database and later refactored to domain-based subgraphs.

5. Apollo Router — the Rust Federation 2 Gateway

Apollo's gateway has two generations.

• Apollo Gateway (Node.js) — shipped in 2019. A Federation gateway in JavaScript. Single-instance throughput plateaued near 1k RPS.
• Apollo Router (Rust) — GA in 2022. A full rewrite in Rust. Same hardware, 10x throughput, p99 latency cut to less than half.

Apollo Router 1.x core features.

• Query planner — computes how an incoming query is partitioned across subgraphs.
• Rhai and Coprocessor — custom logic inside the gateway (auth, transform, logging). Rhai is an embedded script, Coprocessor is an out-of-process RPC.
• Telemetry — OpenTelemetry first-class. Traces, metrics, and logs all flow as OTel.
• Query planner cache — caches the plan of the same query.
• Persisted queries — only accepts pre-registered query hashes (security).

License caveat: Apollo Router 1.x shifted to Elastic License v2 in 2024. SaaS resale is forbidden, and use that competes with Apollo's hosted GraphOS is restricted. Teams uncomfortable with that started looking at Cosmo Router, Hot Chocolate Fusion, and The Guild's Hive Router as Apache-2.0 alternatives.

# router.yaml — Apollo Router config
supergraph:
  listen: 0.0.0.0:4000
  introspection: false
telemetry:
  metrics:
    prometheus:
      enabled: true
traffic_shaping:
  router:
    timeout: 30s
  all:
    deduplicate_query: true

6. Apollo Server 4 and Apollo Client 3.11+

Apollo's two other pillars.

Apollo Server 4 (GA in 2023). A single-graph server (can also act as a Federation subgraph). The v3-to-v4 jump separated Express, Fastify, Lambda, and Cloudflare Workers adapters. The core is transport-agnostic.

// Apollo Server 4 minimal
import { ApolloServer } from '@apollo/server'
import { startStandaloneServer } from '@apollo/server/standalone'

const server = new ApolloServer({
  typeDefs: `
    type Query { hello: String }
  `,
  resolvers: {
    Query: { hello: () => 'world' },
  },
})

const { url } = await startStandaloneServer(server, { listen: { port: 4000 } })
console.log(`server ready at ${url}`)

Apollo Client 3.11+ (2024). Market-leading client. Used in React, Vue, Angular, Svelte, and vanilla JS. Core features.

• Normalized cache — responses are stored as a normalized graph. The same object appearing across multiple queries is stored once.
• Reactive — components subscribed to a cache slice re-render automatically when it changes.
• Optimistic UI — update the UI before the server responds, rollback on failure.
• Pagination, fragments, @client local resolvers.

Apollo Client is powerful but heavy (35-40KB gzipped just for the library). For small apps the cost is real, which is where urql and graphql-request earn their place.

7. GraphQL Yoga 5 — The Guild's Batteries-Included Server

Built by The Guild, runs on Node, Bun, and Deno. After a major rewrite in GraphQL Yoga 4 (2023), the codebase settled into v5 across 2024-25.

Core values.

• Web Standards — built on the Fetch API. Runs unchanged on Cloudflare Workers, Deno, Bun, and Vercel Edge.
• Envelop plugins — auth, cache, tracing, cost analysis. Plugs in The Guild's other ecosystem cleanly.
• Subscriptions over SSE — Server-Sent Events for environments where WebSockets are awkward.
• Federation subgraph — works directly as an Apollo Federation 2 subgraph.

The difference from Apollo Server 4 is the "batteries included" depth. Yoga ships more useful defaults, Apollo Server stays more minimal.

// GraphQL Yoga 5
import { createYoga, createSchema } from 'graphql-yoga'
import { createServer } from 'node:http'

const yoga = createYoga({
  schema: createSchema({
    typeDefs: 'type Query { hello: String }',
    resolvers: { Query: { hello: () => 'yoga' } },
  }),
})

createServer(yoga).listen(4000)

8. graphql-mesh and GraphQL Hive

Two other large tools from The Guild.

graphql-mesh — composes REST, gRPC, SOAP, OpenAPI, Postgres, MongoDB, and Federation under a single GraphQL gateway. So even if your back ends are not GraphQL, you can serve a GraphQL gateway. Often deployed as a migration scaffold.

GraphQL Hive — schema registry plus monitoring. Tracks which client uses which field at what frequency. The open-source counterpart to Apollo's GraphOS Studio. Self-hostable.

The biggest difference between Hive and Apollo Studio is the license. Hive is MIT open source, Studio is SaaS only. Organizations that must self-host (public sector, finance, healthcare) typically pick Hive.

9. Hasura v2 and PostGraphile 5 — DB-First Camp

The "auto-generate a GraphQL schema from a DB" pattern.

Hasura v2 — the most famous DB-first gateway, written in Haskell. Supports PostgreSQL, MySQL, MS SQL Server, BigQuery, Snowflake, and more. Roles, permission rules, Actions (custom business logic), Remote Schemas (merge other GraphQL services), Events (DB change to webhook) are all first class. Licensed under Apache-2.0 (open source).

PostGraphile 5 (Benjie Gillam) — Postgres-only. PostGraphile leans deep into Postgres introspection. Smart Tags, custom plpgsql function to GraphQL field mapping. Across 2024-25 it had a major rewrite to v5 (the Grafast engine). Its standout is solving the N+1 problem through plan-based execution rather than DataLoader.

When DB-first fits: services with more CRUD than business logic, admin tools, internal tools, MVP-stage products. Once business logic thickens you end up writing code by hand, and that is when teams migrate to Apollo Server or Yoga.

10. Supabase GraphQL and WunderGraph

Supabase GraphQL — Supabase auto-exposes a GraphQL endpoint on top of its Postgres. Internally it uses the pg_graphql extension, which executes SQL inside Postgres to satisfy GraphQL, eliminating the N+1 problem. The downside is that the permission model is tied to Postgres RLS.

WunderGraph — started as a Federation gateway and has since grown into a closer-to-full-stack BaaS. Built around Cosmo Router, Cosmo Studio, and Cosmo CDN. Its signature is exposing RPC-style APIs alongside GraphQL. With the "Operations" concept, clients do not send raw GraphQL queries but invoke registered operations.

# WunderGraph operations pattern — clients pre-register on the server
query Users {
  users {
    id
    name
  }
}

11. Stellate, Inigo, Cosmo, Grafbase — Gateway Wars

The GraphQL gateway market diversified visibly between 2024 and 2026.

Stellate (formerly GraphCDN) — acquired by Apollo in 2023. Caches GraphQL responses at CDN edges. POST requests are not normally cacheable on CDNs, but Stellate caches them by query hash.

Inigo — gateway plus security plus observability, sold as SaaS. An Apollo Router alternative. Written in Rust.

Cosmo Router (WunderGraph) — Apache-2.0. Federation 2 compatible. Picked by teams uncomfortable with Apollo Router's license. Bundled with Cosmo Studio (dashboard) and CDN.

Grafbase — edge GraphQL platform. Self-hosted gateway plus schema registry plus edge cache. Runs on Cloudflare Workers.

Hot Chocolate Fusion — ChilliCream's (.NET) Federation-compatible gateway. The Apollo Router of the .NET world.

Hive Router — a new Apache-2.0 gateway from The Guild, integrated with GraphQL Hive.

Decision axes in the gateway market: license (Apache vs Elastic), Federation compatibility (most are Federation 2), edge support (Cloudflare, Vercel, Fastly), observability (Hive vs Studio).

12. Relay 18, urql 4, and Apollo Client 3.11 Compared

The decisive differences between the three clients.

Apollo Client 3.11 — market leader. Every feature. Normalized cache. Downside: bundle size (35-40KB gzip).

Relay 18 (Meta) — Facebook's internal client. Fragment-driven. Components declare fragments for the fields they need, and Relay assembles the optimal query. The compiler normalizes and optimizes queries at build time. Steep learning curve, but the most efficient choice at extreme scale. Used at Meta, parts of GitHub, parts of Stripe.

urql 4 (Formidable, now The Guild) — minimal. Default bundle 5-10KB gzip. The Exchange system plugs in normalized caching, auth, and retry. Scales from tiny apps to large apps incrementally.

graphql-request + TanStack Query — DIY. graphql-request is a minimal fetch-based client. TanStack Query owns caching, retries, and subscriptions. Lightest possible setup, but you write GraphQL-specific features like normalized caching by hand.

Houdini — for SvelteKit, Kit, and Vite. Compile-time codegen minimizes runtime cost.

13. GraphQL Code Generator and Type Safety

GraphQL has its own type system but does not bridge to TypeScript automatically. The bridge is GraphQL Code Generator (The Guild).

• Generates TypeScript types from the server schema.
• Generates argument and result types for the client's query functions.
• Generates React hooks, Vue composables, Svelte stores.

# codegen.yml
schema: ./schema.graphql
documents: ./src/**/*.graphql
generates:
  src/gql/:
    preset: client
    plugins: []

With @graphql-codegen/client-preset, the graphql() tag function infers types at compile time. The same approach delivers typed queries for Apollo Client, urql, and graphql-request alike.

14. Node.js Servers — Mercurius, Pothos, NestJS, TypeGraphQL

The Node.js ecosystem has too many server choices. Sorting them out.

graphql-js — the reference JavaScript implementation. The base of every other library. Too low level to use directly.

Apollo Server 4 — the most common. Transport agnostic.

GraphQL Yoga 5 (The Guild) — Web Standards, batteries included.

Mercurius — the Fastify family. Runs the same code faster than Apollo Server. Natural fit when Fastify is already in place.

Pothos (formerly GiraphQL) — code-first, TypeScript-first. Define the schema in TS code and the SDL is generated automatically. Type inference is excellent so IDE autocomplete is nearly perfect. Quickly gained ground from 2024 onward.

TypeGraphQL — decorator-driven. NestJS-style classes plus decorators define the schema. v2 (2024) was a major rewrite.

NestJS GraphQL — the NestJS framework's GraphQL module. Runs on Apollo Server or Mercurius. The de facto enterprise Node standard.

// Pothos minimal
import SchemaBuilder from '@pothos/core'

const builder = new SchemaBuilder({})
builder.queryType({
  fields: (t) => ({
    hello: t.string({ resolve: () => 'world' }),
  }),
})

export const schema = builder.toSchema()

15. Python — Strawberry, Ariadne, Graphene

Three Python players.

Strawberry GraphQL — dataclass-plus-decorator style. The most modern and the fastest-growing share between 2024 and 2026. First-class integration with FastAPI, Django, and Flask. Federation 2 support. Integrates with Apollo Studio and Hive.

# Strawberry minimal
import strawberry

@strawberry.type
class Query:
    @strawberry.field
    def hello(self) -> str:
        return "world"

schema = strawberry.Schema(query=Query)

Ariadne — schema-first. Write SDL directly, register resolvers as functions. Integrates with Django and FastAPI. Slightly more explicit than Strawberry.

Graphene — the old library. Brought GraphQL to Python first. Rich integrations with Django, Flask, SQLAlchemy, but updates slowed after v3. Most new projects go to Strawberry.

16. Go — gqlgen, graphql-go

The Go ecosystem is relatively consolidated.

gqlgen (99designs, now community). Schema-first, with code generation. Write SDL and gqlgen produces Go structs and resolver interfaces. Type safety at compile time. The de facto Go standard in 2026.

// gqlgen generated resolver shape
func (r *queryResolver) Hello(ctx context.Context) (string, error) {
    return "world", nil
}

graphql-go (graphql-go/graphql) — older. Schemas defined in Go code (code-first). Most new projects go to gqlgen.

gophers/graphql-go — another option. SDL plus resolver function matching is simple, popular for small projects.

17. Rust — async-graphql, juniper

Rust also consolidates around two players.

async-graphql 7 — the most active Rust GraphQL server. DataLoader, subscriptions, Federation 2, Apollo Studio tracing all supported. Integrates with virtually every Rust web framework (Actix, Axum, Warp, Poem).

// async-graphql minimal
use async_graphql::{Object, Schema, EmptyMutation, EmptySubscription};

struct Query;

#[Object]
impl Query {
    async fn hello(&self) -> &'static str { "world" }
}

let schema = Schema::new(Query, EmptyMutation, EmptySubscription);

juniper — older Rust library. The most popular before async-graphql arrived. Still maintained, but new projects trend toward async-graphql.

18. JVM, .NET, Ruby, Elixir, PHP, Swift

Other language ecosystems in one pass.

JVM — graphql-java (the low-level core), DGS Framework (Netflix's Spring integration), Sangria (Scala). DGS being open-sourced made it the de facto JVM standard.

.NET — Hot Chocolate 13 (ChilliCream). The most popular. Code-first. Federation 2 (Hot Chocolate Fusion). GraphQL.NET is older but Hot Chocolate is the modern standard.

// Hot Chocolate minimal
public class Query {
    public string Hello() => "world";
}

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddGraphQLServer().AddQueryType<Query>();
var app = builder.Build();
app.MapGraphQL();
app.Run();

Ruby — graphql-ruby. Built by GitHub, the de facto Ruby standard. Shopify and GitHub themselves use it deeply.

Elixir — Absinthe. Phoenix integration. Functional-style schema-first that flows naturally. Subscriptions ride on Phoenix Channels.

PHP — Lighthouse (Laravel integration), webonyx/graphql-php (the low level), GraphQLite (works with Symfony, Laravel, and Slim).

Swift / Apple — Apollo iOS (Apollo's official iOS client). graphql-swift is effectively dead. On iOS, Apollo iOS is the only practical choice.

19. Subscriptions and graphql-ws

How to transport GraphQL subscriptions.

graphql-ws protocol — The Guild's new WebSocket protocol. Replaces the old Apollo subscriptions-transport-ws. The de facto standard in 2026.

SSE (Server-Sent Events) — the alternative pushed by GraphQL Yoga and The Guild. Natural in environments where WebSockets are awkward (serverless, edge, behind certain firewalls). HTTP/2 based.

HTTP multipart — the transport behind defer and stream.

// graphql-ws message flow (concept)
client -> connection_init
server -> connection_ack
client -> subscribe (id, query, variables)
server -> next (id, payload) (repeated)
server -> complete (id)

Recommendation: for new projects, go with the graphql-ws protocol. Apollo's old protocol is deprecated. SSE is an attractive alternative if serverless or edge is your priority.

20. The N+1 Problem and DataLoader

The most common GraphQL server trap.

# This one-line query becomes hundreds of DB calls in a naive resolver
query {
  posts {
    id
    author { name }
  }
}

With 100 posts, the author lookup fires 100 separate queries. That is the N+1 problem.

DataLoader pattern (Facebook, 2016). Batch IDs that arrive in the same tick into one DB call, then redistribute results by ID.

// DataLoader minimal
import DataLoader from 'dataloader'

const userLoader = new DataLoader(async (ids) => {
  const users = await db.user.findMany({ where: { id: { in: ids } } })
  return ids.map((id) => users.find((u) => u.id === id))
})

// inside the resolver
const author = await userLoader.load(post.authorId)

Why this pattern won: it works. Nearly every GraphQL server framework supports DataLoader first-class (async-graphql, gqlgen, Strawberry, Hot Chocolate alike).

PostGraphile 5's Grafast takes a different approach. Plan-based execution — build an execution plan immediately when a query arrives and avoid N+1 without DataLoader. Cleaner conceptually, but significantly more complex to implement.

21. Persisted Queries and Trusted Operations

GraphQL's security model is tricky. Clients can send any query, so a malicious client could exhaust the server with heavy queries.

Automatic Persisted Queries (APQ) — the client sends only a query hash; if the server does not know it, the client follows up with the full query. Goal: cache efficiency and smaller payloads. Security benefit is weak.

Trusted Documents / Persisted Operations — only queries pre-registered with the server may run. Unfit for external public APIs but the strongest security model for trusted clients like mobile and web. WunderGraph Operations, Relay persisted queries, Apollo Trusted Documents are the same idea.

Query Complexity / Depth Limit — pre-compute the cost of a query and reject it if it exceeds the limit. graphql-shield, graphql-cost-analysis, and Apollo Router's Limits plugin.

// depth limit example (graphql-depth-limit)
import depthLimit from 'graphql-depth-limit'

server.use({ validationRules: [depthLimit(10)] })

22. GraphQL vs REST vs tRPC vs gRPC

The 2026 big picture.

Where each one fits:

• Public APIs and external integrations to REST plus OpenAPI
• Internal full-stack TS apps to tRPC
• Mobile clients that often need different data shapes to GraphQL
• Service-to-service to gRPC plus grpc-web, or Connect (Buf)
• Tens to hundreds of services into one graph to GraphQL Federation 2

The 2026 consensus is that GraphQL is not the answer everywhere. But where "distributed graph composition" is the actual job, GraphQL is still close to the only choice.

23. Korean and Japanese GraphQL Adoption

Korea

• Coupang — runs a GraphQL gateway on some front-end pages (especially the ELK-powered search result page). Mobile apps requiring varied data shapes drove the choice.
• Toss — composes microservices via Apollo Federation in select internal services. Runs its own gateway.
• NCsoft — adopted GraphQL for internal inventory and game-data management, on top of gqlgen.
• Kakao — uses GraphQL in some services (ads, payments). Heavy use in internal tools and admins.
• Naver Clova — uses GraphQL in parts of its AI tooling as a RAG data graph.

Japan

• Mercari — the headline Apollo Federation 2 adopter. Decomposed microservices into dozens of subgraphs. Regular conference talks.
• LINE Yahoo — uses Hasura broadly for internal tools and admins. About 90% of internal Postgres-backed tools sit on Hasura.
• CyberAgent — Go microservices on gqlgen. Used in ad and game back ends.
• DeNA — graphql-ruby on Rails in parts of mobile game back ends.
• Money Forward — announced Apollo Federation adoption in accounting and payments domains (2024).

Common pattern: both Korean and Japanese teams follow the path "start with a single graph, then decompose to Federation once the business grows". Starting on Federation from day one is rare.

24. References

Spec and standards

• GraphQL spec: https://spec.graphql.org/
• GraphQL Foundation: https://graphql.org/foundation/
• Composite Schemas WG: https://github.com/graphql/composite-schemas-wg
• Federation v2 spec: https://www.apollographql.com/docs/federation/

Apollo

• Apollo Router: https://www.apollographql.com/docs/router/
• Apollo Server 4: https://www.apollographql.com/docs/apollo-server/
• Apollo Client: https://www.apollographql.com/docs/react/
• Stellate (formerly GraphCDN): https://stellate.co/

The Guild

• GraphQL Yoga: https://the-guild.dev/graphql/yoga-server
• GraphQL Hive: https://the-guild.dev/graphql/hive
• graphql-mesh: https://the-guild.dev/graphql/mesh
• GraphQL Code Generator: https://the-guild.dev/graphql/codegen
• graphql-ws: https://github.com/enisdenjo/graphql-ws

DB-first

• Hasura: https://hasura.io/
• PostGraphile 5: https://postgraphile.org/
• Supabase GraphQL: https://supabase.com/docs/guides/graphql

WunderGraph and Cosmo

• WunderGraph: https://wundergraph.com/
• Cosmo Router: https://cosmo-docs.wundergraph.com/

Server frameworks

• Strawberry GraphQL: https://strawberry.rocks/
• gqlgen: https://gqlgen.com/
• async-graphql: https://async-graphql.github.io/
• Hot Chocolate: https://chillicream.com/docs/hotchocolate/
• DGS (Netflix): https://netflix.github.io/dgs/
• Absinthe: https://hexdocs.pm/absinthe/
• graphql-ruby: https://graphql-ruby.org/
• Pothos: https://pothos-graphql.dev/

Clients

• Relay: https://relay.dev/
• urql: https://commerce.nearform.com/open-source/urql/
• Houdini: https://houdinigraphql.com/

Tools and patterns

• DataLoader: https://github.com/graphql/dataloader
• graphql-shield: https://github.com/dimatill/graphql-shield

This article is current as of May 2026. The gateway market and the Composite Schemas WG are both moving fast. The next inflection point will be when Apollo Federation's standards work reaches 1.0.