LabHub

Blog

GraphQL Ecosystem 2026 — Apollo / GraphOS / Yoga / urql / Relay / Pothos / Hasura DDN Deep Dive

2026-05-16 · 21 min read · #graphql#apollo#graphos#graphql-yoga#urql#relay#pothos#nexus#hasura#hot-chocolate#gqlgen#strawberry#stellate#federation#deep-dive#english

한국어English日本語

Prologue — "GraphQL is dead" is dead

From around 2023 onward, X (formerly Twitter), Reddit, and Hacker News saw a regular drumbeat of "GraphQL is dead" posts. tRPC was rising fast, skepticism about Netflix's federation case study grew, and Shopify's partial retreat from GraphQL for some new APIs got cited often. A 2024 conference keynote calling GraphQL "an overused tool like microservices" reignited the fight.

As of May 2026, the verdict is relatively clear.

This article maps out what tools sit where in that market, and what you should reach for when starting a new project in 2026. The managed camp (Apollo / GraphOS), The Guild camp (Yoga / Mesh / urql / Pothos), the code-first camp (Relay / Pothos / Nexus), per-language servers (Hasura DDN / Hot Chocolate / gqlgen / Strawberry / graphql-rust), and infra (Stellate) — we look at all of them in one place.

1. The 2026 GraphQL Landscape — After the "GraphQL is dead" Debate

First, the facts of 2025–2026.

Three big arcs underlie all this.

  1. Federation goes mainstream. "One company, one giant single graph" is gone. Domain-scoped subgraphs plus a gateway is the standard.
  2. Code-first rises. Not SDL-first — schemas are inferred from code (TypeScript / Python / .NET). Pothos, Strawberry, Hot Chocolate, and gqlgen all ride this wave.
  3. Coexistence with REST and tRPC. GraphQL holds the BFF / aggregation / federation layer; tRPC and REST do internal and single-server work. The holy war is over.

That is the starting point for everything below.

2. GraphQL vs tRPC vs REST — When to Pick Which

The most common question first. The differences, in one table.

AspectGraphQLtRPCREST (OpenAPI)
SchemaSDL, explicitInferred from TS typesOpenAPI / JSON Schema
Call modelQuery / mutation / subscriptionFunction callHTTP method + URL
Type safetyStrong (codegen)Very strong (type inference)Tool-dependent
LanguagesAll client languagesTS onlyEvery language
CachingNormalized cache, CDN (Stellate)Simple (app cache)HTTP-cache friendly
Best fitMobile, BFF, federationSingle TS fullstackPublic / internal RPC, simple CRUD
Learning curveSteepAlmost noneLow
PayloadClient-definedFunction signatureServer-defined

Decision tree.

  1. Frontend and backend in the same TS monorepo with no other languages — tRPC is fastest.
  2. Mobile or multiple clients (iOS/Android/Web/embedded) where each needs different fields — GraphQL.
  3. Backend split across multiple teams that must look like one API — GraphQL Federation.
  4. Public API, external partner integration, simple CRUD — REST (OpenAPI) is safe.
  5. Internal microservice calls, high throughput — gRPC.

The 2026 reality is that one company has all of them. Public APIs in REST, mobile/web BFFs in GraphQL, inter-service calls in gRPC, single-stack TS services in tRPC. "Pick one" is an old debate.

3. Apollo Server 5 / Client 4 — The Standard

Apollo shipped Server 5 and Client 4 in 2025. The two majors only make sense together.

Apollo Server 5 highlights

A minimal bootstrap.

// server.ts
import { ApolloServer } from '@apollo/server'
import { startStandaloneServer } from '@apollo/server/standalone'
import { typeDefs } from './schema'
import { resolvers } from './resolvers'

const server = new ApolloServer({
  typeDefs,
  resolvers,
  introspection: process.env.NODE_ENV !== 'production',
})

const { url } = await startStandaloneServer(server, {
  listen: { port: 4000 },
  context: async ({ req }) => ({
    user: await getUserFromToken(req.headers.authorization),
  }),
})

console.log(`Apollo Server ready at ${url}`)

Apollo Client 4 highlights

// client.ts
import { ApolloClient, InMemoryCache, HttpLink } from '@apollo/client'

export const client = new ApolloClient({
  link: new HttpLink({ uri: '/graphql' }),
  cache: new InMemoryCache(),
})

React usage.

import { useSuspenseQuery } from '@apollo/client/react'
import { gql } from '@apollo/client'

const ME = gql`
  query Me {
    me {
      id
      name
      email
    }
  }
`

export function Profile() {
  const { data } = useSuspenseQuery(ME)
  return <div>{data.me.name}</div>
}

Strengths

Weaknesses

4. GraphOS — Apollo's Managed Federation

GraphOS is Apollo's federation platform. Three core components.

  1. Apollo Router — A Rust gateway. Subgraph routing, query planning, caching.
  2. Schema Registry — Central store for subgraph schemas. Change detection, compatibility checks.
  3. Studio (GraphOS UI) — Usage metrics, query analysis, ops tooling.

Apollo Router

Apollo Router replaces the old Node-based Apollo Gateway. Throughput is roughly an order of magnitude higher and memory use is far lower. In 2026, if you are setting up a new federation gateway, it is almost always Router.

# router.yaml
supergraph:
  introspection: false
include_subgraph_errors:
  all: true
telemetry:
  exporters:
    metrics:
      prometheus:
        enabled: true
    tracing:
      otlp:
        enabled: true
        endpoint: http://otel:4317

Pricing model

GraphOS comes in Serverless (free), Dedicated (paid), and Enterprise tiers. The free tier covers small teams, but heavy production traffic forces the paid jump quickly. Apollo's business model rides on GraphOS, and there was a noticeable price hike between 2024 and 2025.

Alternatives

The major GraphOS alternatives are GraphQL Hive (The Guild), Inigo, and Stellate (caching). Hive is OSS and self-hostable; teams that want lighter federation ops often prefer it. Starting fresh in 2026, Apollo Router + Hive is also a perfectly reasonable combo.

5. GraphQL Yoga 5 + Mesh 1 (The Guild) — The Lightweight Camp

The Guild effectively leads the GraphQL OSS ecosystem. Their flagship projects in 2026.

GraphQL Yoga 5

Yoga's tagline is "the best of Express and Apollo Server, but lightweight". v5 is Node 18+, Fetch API based, Bun and Deno compatible, with edge runtime (Vercel / Cloudflare) first-class support.

// yoga.ts
import { createYoga, createSchema } from 'graphql-yoga'
import { createServer } from 'node:http'

const yoga = createYoga({
  schema: createSchema({
    typeDefs: /* GraphQL */ `
      type Query {
        hello: String!
      }
    `,
    resolvers: {
      Query: {
        hello: () => 'Hello from Yoga 5',
      },
    },
  }),
})

createServer(yoga).listen(4000)

GraphQL Mesh 1

Mesh combines multiple sources (REST, gRPC, OpenAPI, JSON Schema, Postgres, MongoDB) into a single GraphQL graph. v1 simplifies config and strengthens federation integration. A common pattern is Mesh-built subgraphs behind Apollo Router.

Strengths

Weaknesses

6. urql 5 (Formidable) — The Apollo Client Alternative

urql is a lightweight client originally from Formidable. It is the first thing people check when they think Apollo is heavy. v5 adds first-class React 19, Suspense, and Server Component support.

Key differences

import { Client, fetchExchange, cacheExchange, Provider } from 'urql'

const client = new Client({
  url: '/graphql',
  exchanges: [cacheExchange, fetchExchange],
})

function App() {
  return (
    <Provider value={client}>
      <Profile />
    </Provider>
  )
}

React component.

import { useQuery } from 'urql'

const ME = `
  query Me {
    me { id name }
  }
`

function Profile() {
  const [result] = useQuery({ query: ME })
  if (result.fetching) return <p>Loading...</p>
  if (result.error) return <p>Error</p>
  return <p>{result.data.me.name}</p>
}

Strengths

Weaknesses

When to pick urql

7. Relay 18 (Meta) — Facebook's Internal Standard

Relay is the GraphQL client Meta built and uses internally. Its philosophy differs from Apollo and urql: "guarantee as much as possible at compile time for performance".

Core concepts

// UserProfile.tsx
import { useFragment, graphql } from 'react-relay'

const UserProfileFragment = graphql`
  fragment UserProfile_user on User {
    name
    avatarUrl
  }
`

export function UserProfile({ user }: { user: UserProfile_user$key }) {
  const data = useFragment(UserProfileFragment, user)
  return <h1>{data.name}</h1>
}

What is new in Relay 18

Strengths

Weaknesses

When to pick Relay

8. Pothos — TypeScript Code-First Schema Builder

Pothos (formerly GiraphQL) is a TypeScript library for defining GraphQL schemas code-first. Between 2024 and 2025 it pushed Nexus aside to become the de facto standard.

What "code-first" means and why it helps

A traditional SDL-first workflow looks like this.

  1. Write types in SDL in schema.graphql.
  2. Generate TS types with graphql-codegen.
  3. Import those types in resolvers.

That is a two-step change for every edit. Code-first flips it.

  1. Write the schema with a builder API in TS.
  2. The builder generates SDL automatically.

A Pothos example

// schema.ts
import SchemaBuilder from '@pothos/core'

const builder = new SchemaBuilder({})

const User = builder.objectRef<{ id: string; name: string }>('User')

builder.objectType(User, {
  fields: (t) => ({
    id: t.exposeID('id'),
    name: t.exposeString('name'),
  }),
})

builder.queryType({
  fields: (t) => ({
    me: t.field({
      type: User,
      resolve: () => ({ id: '1', name: 'Alice' }),
    }),
  }),
})

export const schema = builder.toSchema()

Pothos strengths

Comparison with Nexus

Nexus came first and was the standard for a while. But Pothos has stronger inference, and Nexus maintainer activity dropped, so it effectively handed over the crown. New projects nearly all go Pothos.

Prisma integration example

import SchemaBuilder from '@pothos/core'
import PrismaPlugin from '@pothos/plugin-prisma'
import { prisma } from './prisma'

const builder = new SchemaBuilder<{
  PrismaTypes: PrismaTypes
}>({
  plugins: [PrismaPlugin],
  prisma: { client: prisma },
})

builder.prismaObject('User', {
  fields: (t) => ({
    id: t.exposeID('id'),
    name: t.exposeString('name'),
    posts: t.relation('posts'),
  }),
})

Prisma models become GraphQL types almost automatically, and the plugin handles N+1 for you.

9. Hasura DDN — A New Architecture

Hasura became well known for auto-generating GraphQL APIs over Postgres, SQL Server, BigQuery and friends. By v2, several problems had piled up.

DDN (Data Delivery Network)

Announced in 2024, Hasura DDN is the new architecture that addresses v2's limits.

Strengths

Weaknesses

When to pick Hasura DDN

10. Hot Chocolate (.NET) / gqlgen (Go) / Strawberry (Python) / graphql-rust

Beyond JS / TS, here is the language landscape.

Hot Chocolate (.NET — ChilliCream)

public class Query
{
    public Book GetBook() =>
        new Book { Title = "C# in Depth", Author = new Author { Name = "Jon Skeet" } };
}

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

var app = builder.Build();
app.MapGraphQL();
app.Run();

gqlgen (Go — 99designs)

Strawberry (Python)

import strawberry

@strawberry.type
class User:
    id: strawberry.ID
    name: str

@strawberry.type
class Query:
    @strawberry.field
    def me(self) -> User:
        return User(id="1", name="Alice")

schema = strawberry.Schema(query=Query)

graphql-rust (async-graphql / juniper)

Per-language picks

LanguageFirst choiceNotes
TypeScript / NodeApollo Server 5 or GraphQL Yoga 5 + PothosApollo Router for federation
PythonStrawberryGraphene is legacy
GogqlgenAlmost monopoly
.NETHot ChocolateAlmost monopoly
Rustasync-graphqljuniper is conservative
Java / KotlinDGS (Netflix) or graphql-javaDGS for Spring Boot
Rubygraphql-ruby (maintained by GitHub)Used by Shopify and GitHub
ElixirAbsintheAlmost monopoly

11. Stellate — GraphQL CDN Caching

Caching is one of GraphQL's classic weaknesses. The same query yields different responses depending on variables, and all requests are POSTs, so standard HTTP caching is hard. Stellate is a GraphQL-native CDN built for this.

Core ideas

Usage

You register a GraphQL endpoint with Stellate and get a CDN URL in front of it. Clients call the Stellate URL instead of the origin. Query responses are cached for seconds to minutes, and mutations automatically invalidate related entries.

Strengths

Weaknesses

12. Federation 2 + Subgraph Composition Patterns

GraphQL Federation composes multiple subgraphs (graphs of independent services) into one supergraph. Apollo defined the spec; v2 stabilised it.

Key directives

Subgraph example (Users)

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

type Query {
  me: User
  user(id: ID!): User
}

Subgraph example (Orders)

extend type User @key(fields: "id") {
  id: ID! @external
  orders: [Order!]!
}

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

The gateway (Apollo Router) composes both subgraphs into a supergraph, and the query planner splits a query like me { orders { total } } across the two subgraphs.

Operational patterns for subgraph composition

Anti-patterns

13. Persisted Queries / Defer / Stream / Live Queries

The advanced GraphQL features that stabilised in 2025–2026.

Persisted Queries

Clients send only a hash instead of the full query, and the server runs a pre-registered query. Two effects.

  1. Network savings — Mobile clients do not ship large query payloads every time.
  2. Security — Clients cannot send arbitrary queries; attack surface shrinks.

Apollo Persisted Queries, Hive Persisted Documents, Relay Persisted Queries are all variations on the same idea. It is effectively mandatory for mobile and embed clients.

@defer / @stream

Instead of sending a big response in one shot, send part first and stream the rest.

query Profile {
  me {
    id
    name
    ... on User @defer {
      slowField
    }
  }
}

The server responds in chunks (multipart/mixed), sending part of the data first. Initial render time on large pages drops significantly. Apollo Server 5, Yoga 5, and Hot Chocolate all support this.

Live Queries

Whenever the result of a query changes, the server pushes the update. Similar to Subscriptions but — Subscriptions explicitly subscribe to channels, whereas with Live Queries the client just sends a regular query and the server detects changes and re-pushes.

Relay 18 supports it in beta; Yoga and Hot Chocolate have experimental implementations. Standardisation is still in flight, but it is compelling for chat and dashboards.

Subscriptions (recap)

14. Real-World Usage in Korea (Kakao, LINE) and Japan (Mercari, ZOZO)

How big companies in Korea and Japan use GraphQL, based on public sources.

Kakao

LINE (LY Group)

Mercari

ZOZO

Common patterns

The big-picture stack — "Apollo Server + federation + Apollo Router + internal or SaaS registry" — is similar in both countries. The difference is that Korea is dominated by Kakao / Naver-style large in-house backends, while Japan is dominated by mobile commerce BFFs at Mercari / ZOZO.

Conclusion — If You Are Picking GraphQL Fresh in 2026

The one-liner recommendations.

  1. New single Node / TS server — Yoga 5 + Pothos + Prisma. Client is urql or Apollo.
  2. New Node / TS federation — Apollo Server 5 + Apollo Router + GraphOS or Hive. Client is Apollo Client 4.
  3. Meta-scale large SPA — Relay 18 + Pothos. Self-managed infra.
  4. Mobile BFF — Apollo Server 5 + Apollo Client 4 + Persisted Queries + Stellate.
  5. Python — Strawberry + FastAPI / Django. For federation, place it behind Apollo Router.
  6. Go — gqlgen + DataLoader. Any client works.
  7. .NET — Hot Chocolate 14. There is almost no other choice.
  8. Rust — async-graphql + Axum. When performance really matters.
  9. Auto CRUD on top of a DB — Hasura DDN. But push high-freedom business logic into a separate service.

And the one thing that matters most: "GraphQL or not" is no longer a single decision. A normal 2026 company has GraphQL (mobile BFF), tRPC (TS fullstack), REST (public API), and gRPC (internal RPC) all at once. GraphQL is not dead — it just found its place.

References

Read the original: https://www.youngju.dev/blog/culture/2026-05-16-graphql-ecosystem-2026-apollo-graphos-yoga-urql-relay-pothos-hasura-ddn-deep-dive.en

Comments

No comments yet.

Sign in to leave a comment