💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

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.

- GraphQL is not dead. But the illusion that it is "the default for every API" is.

- GraphQL has become stronger in its real territory (BFF, mobile clients, federated backends, public APIs).

- Small single backends and internal RPC have gone to tRPC, gRPC, and REST.

- The market is still large. State of JS, JetBrains, and StackOverflow surveys in 2025 show GraphQL usage holding steady at 30–40%.

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.

- **Apollo** is still the market leader. Server 5 (2025) and Client 4 are the standard stack.

- **GraphOS** is Apollo's managed federation platform. Apollo Studio was absorbed into GraphOS.

- **The Guild** is the OSS counterweight. GraphQL Yoga 5, Mesh 1, GraphQL Code Generator, Envelop, GraphQL Hive.

- **urql** (Formidable, with Hasura partial sponsorship later on) is the lightweight Apollo Client alternative. v5 added React 19 / Suspense integration.

- **Relay** is maintained by Meta. v18 ships React 19 / Server Component support.

- **Pothos** is the new standard for TypeScript code-first. Nexus is in effective maintenance mode.

- **Hasura** cleaned up the v2-era problems (scale, lock-in, license shifts) with DDN (2024).

- **Per-language servers** are Hot Chocolate (.NET), gqlgen (Go), Strawberry (Python), and async-graphql / juniper (Rust).

- **Infra** consists of Stellate (GraphQL CDN), Apollo Router, Hive, Inigo, and Tyk's GraphQL proxy.

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.

| --- | --- | --- | --- |

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

- Dropped Node.js 18 and below; ESM-first.

- Consolidated into `@apollo/server` (no more separate `apollo-server-express`, `apollo-server-fastify`).

- Standard integration helpers are `startStandaloneServer`, `expressMiddleware`, `koaMiddleware`.

- Expanded HTTP/2 and gRPC transform support.

- Built-in plugin cleanup (landing page, usage reporting, cache control).

A minimal bootstrap.

// server.ts

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

- React 19 / Suspense are first-class. `useSuspenseQuery` and `useReadQuery` are the new default.

- Cache policy simplified. Normalized cache stays.

- `defer` / `stream` directive support.

- Local state shifts to reactive vars (Apollo Link State is gone).

- Bundle shrink through better tree shaking.

// client.ts

export const client = new ApolloClient({

link: new HttpLink({ uri: '/graphql' }),

cache: new InMemoryCache(),

})

React usage.

const ME = gql`

query Me {

me {

name

}

export function Profile() {

const { data } = useSuspenseQuery(ME)

return <div>{data.me.name}</div>

}

Strengths

- The most mature. Almost every pattern is documented.

- Tight integration with federation tooling (Rover, Studio, Router).

- Enterprise support.

Weaknesses

- Bundle is still large. Client alone is 50KB+ compressed.

- The "Apollo is heavy" reputation has stuck; new teams check urql first.

- Apollo Studio's absorption into GraphOS shrank the free tier.

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** — Lightweight GraphQL server. Apollo Server alternative.

- **GraphQL Mesh 1** — Automatically converts various sources (REST, OpenAPI, gRPC, DB) to GraphQL.

- **Envelop** — GraphQL server plugin framework.

- **GraphQL Code Generator** — Schema to TS / Java / Swift code generation.

- **Hive** — Schema registry and observability (the GraphOS alternative).

- **GraphQL Tools** — schema stitching, mocking, scalars, and other utilities.

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

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

- Lightweight. Yoga is under half the size of Apollo Server.

- Web-standard based (Request / Response). It runs everywhere.

- OSS, no commercial lock-in.

Weaknesses

- Federation ops require installing Hive separately (not as integrated as GraphOS).

- Documentation is not as rich as Apollo's.

- Enterprise support leans on The Guild's consulting.

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

- ~10KB bundle (about 1/5 of Apollo Client).

- Exchange (middleware) based. Cache, auth, retry, etc. are composed pieces.

- Defaults to a document cache. Normalized cache is opt-in via `@urql/exchange-graphcache`.

const client = new Client({

url: '/graphql',

exchanges: [cacheExchange, fetchExchange],

})

function App() {

return (

)

}

React component.

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

- Small. A natural fit for bundle-sensitive mobile web and embed widgets.

- Simple API. New users get productive in 30 minutes.

- Supports React, Vue, Svelte, and Preact.

Weaknesses

- Normalized cache is a separate package. Default is document cache (per-query keying).

- No federation ops tooling (client only).

- Community is roughly 1/10 the size of Apollo's.

When to pick urql

- Embed widgets and marketing sites where bundle matters.

- Simple pages that do not need normalization.

- Small teams who find Apollo Client's complexity too much.

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

- **Fragment colocation** — A component declares the fields it needs itself.

- **Compiler** — Analyses and optimises queries at build time. Persisted queries are auto-generated.

- **Store** — A normalized client-side database.

- **Suspense + Concurrent** — Deep integration with React 18+ Suspense and Concurrent Mode.

- **GraphQL server requirements** — Connection spec (cursor-based pagination), Node interface (global ID), etc.

// UserProfile.tsx

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

- React 19 / Server Component support.

- Relay Resolvers GA — derived fields on the client side.

- Data-driven Dependencies (DDD) — components and data payloads fetched together.

- Live Queries in beta.

Strengths

- Best performance on huge apps. Battle-tested at Meta on Facebook, Instagram, WhatsApp.

- Build-time analysis. Minimal runtime overhead.

- Deepest Concurrent React integration.

Weaknesses

- Learning curve is steep. Three to five times Apollo.

- Server must follow Relay conventions (Connection, Node).

- Overkill for small teams.

When to pick Relay

- Large SPAs with hundreds of screens.

- Data-intensive apps like Facebook, Pinterest, Linear.

- Teams with many ex-Meta engineers.

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

const builder = new SchemaBuilder({})

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

builder.objectType(User, {

fields: (t) => ({

id: t.exposeID('id'),

}),

})

builder.queryType({

fields: (t) => ({

me: t.field({

type: User,

resolve: () => ({ id: '1', name: 'Alice' }),

}),

})

export const schema = builder.toSchema()

Pothos strengths

- Best-in-class type safety. Even resolver return types are inferred.

- Rich plugin ecosystem — Prisma, Drizzle, Relay, Federation, Scope Auth.

- No codegen step needed.

- First-class federation (Subgraph) support.

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

const builder = new SchemaBuilder<{

PrismaTypes: PrismaTypes

}>({

plugins: [PrismaPlugin],

prisma: { client: prisma },

})

builder.prismaObject('User', {

fields: (t) => ({

id: t.exposeID('id'),

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.

- A single giant metadata file blocked team collaboration.

- Multi-DB and non-DB sources felt awkward.

- Cloud and OSS license shifts shook the community.

- Performance and scaling were operational headaches.

DDN (Data Delivery Network)

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

- **Per-subgraph metadata** — Domain teams work independently.

- **Data Connectors** — Postgres, ClickHouse, MongoDB, REST, gRPC, all as first-class.

- **Local-first** — CLI-based local development; GitOps friendly.

- **GraphQL Federation compatible** — DDN subgraphs can sit behind Apollo Router.

Strengths

- Automatic CRUD on top of a DB is still unbeatable. You can have a fullstack backend in a few days.

- Permissions are declarative in SDL.

- Strong for scenarios that combine multiple sources into one graph.

Weaknesses

- v2 to v3 (DDN) migration is essentially a rewrite.

- Cloud pricing is still considered expensive.

- High-freedom business logic eventually splits out into its own service.

When to pick Hasura DDN

- Back-office or admin consoles with a clear, CRUD-heavy data model.

- Teams that need to merge many DBs and SaaS APIs into a single graph.

- Rapid prototyping.

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

Beyond JS / TS, here is the language landscape.

Hot Chocolate (.NET — ChilliCream)

- De facto standard in .NET. v14 ships in 2026.

- Code-first by default. Attribute-based schema definition.

- Federation, Subscriptions, Persisted Queries — all supported.

- Comes with the Banana Cake Pop IDE.

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)

- Most popular in Go. SDL-first plus code generation.

- Write SDL in `schema.graphqls`, run `gqlgen generate` to produce resolver interfaces.

- DataLoader, Federation, Subscriptions supported.

- Maintained by 99designs / Vista.

Strawberry (Python)

- The fastest-growing Python library, replacing Graphene.

- Type-hint based code-first. Decorators define the schema.

- Excellent Django / FastAPI integration.

- Federation and Subscriptions supported.

@strawberry.type

class User:

id: strawberry.ID

@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)

- Rust splits between **async-graphql** (more active) and **juniper** (older standard).

- async-graphql covers Federation, Subscriptions, and Apollo Tracing.

- Pairs with Actix, Axum, Warp, Rocket web frameworks.

- Performance is overwhelming. That is why people pick Rust for GraphQL servers.

Per-language picks

| Language | First choice | Notes |

| --- | --- | --- |

| TypeScript / Node | Apollo Server 5 or GraphQL Yoga 5 + Pothos | Apollo Router for federation |

| Python | Strawberry | Graphene is legacy |

| Go | gqlgen | Almost monopoly |

| .NET | Hot Chocolate | Almost monopoly |

| Rust | async-graphql | juniper is conservative |

| Java / Kotlin | DGS (Netflix) or graphql-java | DGS for Spring Boot |

| Ruby | graphql-ruby (maintained by GitHub) | Used by Shopify and GitHub |

| Elixir | Absinthe | Almost 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

- **Per-query cache** — Key is query hash plus variables; the result is cached.

- **Edge cache** — Responses served from PoPs around the world.

- **Automatic invalidation** — Tracks which types a mutation changes and expires related cache entries.

- **Rate limiting / Persisted queries** come along too.

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

- Big payoff for mobile apps and home screens that hit the same GraphQL queries repeatedly.

- Adds caching with almost no backend change.

- Works with any client — Apollo, urql, Relay.

Weaknesses

- Paid SaaS, priced on traffic.

- Per-user response queries get poor cache efficiency.

- Replaceable with your own stack (Apollo Router + Redis + Varnish).

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

- `@key(fields: "id")` — Defines an entity's identifier.

- `@extends` — Extends a type from another subgraph.

- `@external` / `@requires` / `@provides` — Declare field dependencies.

- `@shareable` — Allows the same field to be defined by multiple subgraphs.

- `@inaccessible` — Excludes a field from external exposure (internal use only).

Subgraph example (Users)

type User @key(fields: "id") {

id: ID!

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

- **Split by domain** — Team equals subgraph is the most common mapping.

- **One owner per shared entity** — User is owned by the Users subgraph; others extend it.

- **CI integration** — Each PR runs a Rover schema check; incompatible changes are blocked.

- **Incremental adoption** — Breaking a monolithic graph into subgraphs is usually a quarter-long project.

Anti-patterns

- **Splitting too finely** — More than 20 subgraphs is operationally painful.

- **Exposing every entity everywhere** — Use `@inaccessible` liberally.

- **Deep cross-subgraph dependencies** — A query that bounces five hops ruins latency.

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 {

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)

- Run over WebSocket or SSE.

- Apollo Server recommends `graphql-ws` (the legacy `subscriptions-transport-ws` is deprecated).

- On serverless (Vercel, Cloudflare Workers), SSE or pub/sub (Ably, Pusher) combos are common.

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

- Adopted in some internal services from around 2017.

- External SaaS like Channel Talk also exposes partial GraphQL APIs.

- Group companies including Kakao Style (Zigzag) use GraphQL heavily for BFFs. Apollo Server + Apollo Client is common.

- Kakao tech blog has multiple posts on federation and caching.

LINE (LY Group)

- LINE's mobile messaging uses GraphQL internally for some APIs.

- After the LY (LINE × Yahoo!) merger, some Yahoo! Japan services adopted GraphQL too.

- The LINE engineering blog has federation case studies.

Mercari

- Mercari adopted GraphQL relatively early (around 2019 for mobile clients).

- GraphQL acts as a BFF on top of microservices backends; federation case studies are public on the Mercari engineering blog.

- Subsidiaries like Souzoh use the same stack.

ZOZO

- ZOZO Technologies adopts GraphQL in some new services.

- Codegen-based workflow (Apollo + graphql-codegen + TypeScript).

- Used as a BFF in apps like WEAR.

Common patterns

- **Mobile BFF** — Pick only the fields each iOS / Android app needs, hence GraphQL.

- **Legacy integration** — GraphQL Mesh or federation gateways sit on top of REST / gRPC microservices.

- **Apollo dominant, Yoga / Pothos rising** — New projects increasingly pick Pothos.

- **Internal schema registry** — Self-hosted Hive is common in Japan as a GraphOS alternative.

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

- [GraphQL Official Site](https://graphql.org/)

- [Apollo GraphQL Docs](https://www.apollographql.com/docs/)

- [Apollo Server 4/5 Migration Guide](https://www.apollographql.com/docs/apollo-server/migration)

- [Apollo Client React Docs](https://www.apollographql.com/docs/react/)

- [GraphOS Overview](https://www.apollographql.com/graphos)

- [Apollo Router Docs](https://www.apollographql.com/docs/router/)

- [The Guild — GraphQL Yoga](https://the-guild.dev/graphql/yoga-server)

- [The Guild — GraphQL Mesh](https://the-guild.dev/graphql/mesh)

- [The Guild — GraphQL Hive](https://the-guild.dev/graphql/hive)

- [The Guild — Envelop](https://the-guild.dev/graphql/envelop)

- [GraphQL Code Generator](https://the-guild.dev/graphql/codegen)

- [urql Official Site](https://commerce.nearform.com/open-source/urql/)

- [Relay Official Site](https://relay.dev/)

- [Pothos GraphQL](https://pothos-graphql.dev/)

- [Nexus GraphQL](https://nexusjs.org/)

- [Hasura DDN Docs](https://hasura.io/docs/3.0/)

- [ChilliCream Hot Chocolate](https://chillicream.com/docs/hotchocolate/)

- [gqlgen (Go)](https://gqlgen.com/)

- [Strawberry (Python)](https://strawberry.rocks/)

- [async-graphql (Rust)](https://async-graphql.github.io/async-graphql/en/index.html)

- [Juniper (Rust)](https://graphql-rust.github.io/juniper/)

- [Stellate](https://stellate.co/)

- [GraphQL Federation Spec](https://www.apollographql.com/docs/federation/)

- [Persisted Queries (Apollo)](https://www.apollographql.com/docs/router/configuration/persisted-queries/)

- [GraphQL @defer / @stream Spec](https://github.com/graphql/graphql-spec/blob/main/rfcs/DeferStream.md)

- [graphql-ws](https://github.com/enisdenjo/graphql-ws)

- [State of GraphQL 2024 (The Guild)](https://stateofgraphql.com/)

- [Kakao Tech Blog](https://tech.kakao.com/)

- [LINE Engineering Blog](https://engineering.linecorp.com/)

- [Mercari Engineering Blog](https://engineering.mercari.com/)

- [ZOZO TECH BLOG](https://techblog.zozo.com/)