GraphQL Yoga vs. Apollo Server: Which Server for Which Project

1. The Node.js GraphQL server landscape and why the choice has consequences

Setting up a GraphQL server in Node.js today means choosing more than a library, it means choosing an entire operating philosophy: how plugins are wired in, how errors are handled, how tightly the server is coupled to a specific vendor, and how easily it can later be swapped for another framework like Fastify or Next.js. GraphQL Yoga and Apollo Server are by far the two most widely used options in the Node.js ecosystem, and they pursue different priorities.

GraphQL Yoga, built by The Guild team also behind GraphQL Mesh and envelop, positions itself as a lean, spec-compliant core that deliberately ships a minimal base and adds functionality only through plugins. Apollo Server takes the opposite path: an integrated, all-in-one package with built-in Federation support, tracing and a close, though optional, connection to the commercial Apollo Studio platform.

2. GraphQL Yoga: the envelop plugin system and standards compliance

The core of GraphQL Yoga is deliberately kept small and strictly implements the GraphQL-over-HTTP specification, including correct content negotiation, server-sent events for subscriptions, and WHATWG Fetch compatible request and response objects. As a result, the same Yoga server runs almost unchanged on Node.js, Deno, Bun, Cloudflare Workers or Vercel Edge Functions, because it requires no Node-specific APIs.

Additional functionality such as caching, rate limiting, persisted queries or response validation is not built into the core, it is added through the envelop plugin system, which exposes every step of execution, from parsing through validation to execution, as a swappable hook. That keeps the core testable and small, but it requires teams to deliberately assemble the right envelop plugins instead of getting them preconfigured.

import { createYoga, createSchema } from 'graphql-yoga'
import { useResponseCache } from '@envelop/response-cache'
import { createServer } from 'node:http'

const yoga = createYoga({
  schema: createSchema({
    typeDefs: /* GraphQL */ `
      type Query {
        products: [Product!]!
      }
      type Product {
        id: ID!
        name: String!
      }
    `,
    resolvers: {
      Query: {
        products: () => productRepository.findAll(),
      },
    },
  }),
  plugins: [
    useResponseCache({ session: () => null, ttl: 5_000 }),
  ],
})

createServer(yoga).listen(4000)

3. Apollo Server: ecosystem, plugins and Studio integration

Apollo Server ships a plugin system out of the box that hooks into the request lifecycle, requestDidStart, willSendResponse and similar hooks, and can send tracing data straight to Apollo Studio through it without extra configuration. That built-in observability offering is one of the main reasons many teams stick with Apollo Server once they start relying on Apollo Studio for schema checks and performance metrics.

The framework itself is strongly oriented around the Apollo ecosystem: Apollo Client, Apollo Router for Federation and Apollo GraphOS as a managed platform all mesh seamlessly, which reduces friction for a team that wants to use the entire Apollo stack anyway. Teams that want to stay deliberately vendor-neutral tend to experience that tight integration as extra coupling instead.

import { ApolloServer } from '@apollo/server'
import { startStandaloneServer } from '@apollo/server/standalone'

const typeDefs = `#graphql
  type Query {
    products: [Product!]!
  }
  type Product {
    id: ID!
    name: String!
  }
`

const resolvers = {
  Query: {
    products: () => productRepository.findAll(),
  },
}

const server = new ApolloServer({ typeDefs, resolvers })

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

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

4. Performance and bundle size compared

In both independent and self-run benchmarks, GraphQL Yoga usually edges ahead on simple requests, mostly thanks to its leaner core and the absence of tracing instrumentation enabled by default. Apollo Server enables more built-in middleware by default depending on version, for example for landing page rendering or usage reporting, which can show up in latency under very high load unless those features are explicitly disabled.

For the vast majority of projects, the difference amounts to single-digit milliseconds per request, practically irrelevant next to the latency caused by database access or external services anyway. What matters more than raw performance is usually bundle size when deploying to edge platforms, where Yoga's smaller core brings real advantages in cold-start times.

5. Federation support: Apollo Server and Yoga in a supergraph context

Apollo Server supports Federation natively through @apollo/subgraph and can run as a subgraph behind an Apollo Router without detours, including automatic entity resolution and schema validation against the Federation specification. That makes Apollo Server the obvious choice once a team is already building a distributed, federated architecture with Apollo tooling.

GraphQL Yoga can also act as a Federation subgraph, but it needs the additional @graphql-tools/federation package or a combination with GraphQL Mesh, which means an extra configuration step but no limitation in actual functionality. In mixed environments, Yoga and Apollo subgraphs can even be combined behind the same Federation router without issues, because the specification is server-independent.

import { createYoga } from 'graphql-yoga'
import { buildSubgraphSchema } from '@graphql-tools/federation'
import { parse } from 'graphql'

const typeDefs = parse(/* GraphQL */ `
  extend schema
    @link(url: "https://specs.apollo.dev/federation/v2.3",
          import: ["@key"])

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

const schema = buildSubgraphSchema({ typeDefs, resolvers: {
  Product: {
    __resolveReference: (ref) => productRepository.findById(ref.id),
  },
}})

const yoga = createYoga({ schema })

6. Plugin ecosystem: envelop plugins vs. Apollo Server plugins

The envelop ecosystem around GraphQL Yoga now offers well over fifty ready-made plugins for topics like rate limiting, persisted operations, response caching, Sentry integration or OpenTelemetry, all freely composable and, independent of the server used, also usable in other envelop-compatible setups. This modularity lets a project enable exactly the features it needs without carrying unused code.

Apollo Server plugins are tied more closely to the Apollo Server lifecycle model and mainly cover observability, caching and validation, but with deep, officially maintained integration into Apollo Studio. Teams that value official support and version guarantees from a single vendor tend to find more consistently maintained plugins with Apollo Server, teams that want maximum modularity benefit more from the more open envelop ecosystem.

import { envelop, useSchema } from '@envelop/core'
import { useRateLimiter } from '@envelop/rate-limiter'
import { usePersistedOperations } from '@envelop/persisted-operations'
import { useOpenTelemetry } from '@envelop/opentelemetry'

const getEnveloped = envelop({
  plugins: [
    useSchema(schema),
    useRateLimiter({ identifyFn: (ctx) => ctx.request.ip }),
    usePersistedOperations({ getPersistedOperation: (hash) => store.get(hash) }),
    useOpenTelemetry({ resolvers: true, variables: false }),
  ],
})

7. Developer experience: GraphiQL, error handling and the landing page

GraphQL Yoga ships a built-in GraphiQL interface with an explorer by default, reachable at the server endpoint without any extra configuration, including automatically generated schema documentation. Errors are formatted according to the official GraphQL-over-HTTP specification, which makes client-side error handling more predictable than with servers that use their own, undocumented error format.

Apollo Server offers a similarly comfortable development interface with Apollo Sandbox, which additionally stores history and variable presets once an Apollo Studio account is connected. For teams without Apollo Studio access, the Sandbox remains usable locally, but it loses part of its added value compared to Yoga's simpler, but fully local, GraphiQL interface.

8. Migration effort between GraphQL Yoga and Apollo Server

Since both servers use the same GraphQL schema and the same resolver signatures, the actual business-logic code stays almost unchanged during a migration. The effort concentrates on three areas: context setup, which runs through a context function with access to req in Apollo Server and works very similarly but with WHATWG request objects in Yoga, the plugin setup, which has to be assembled from scratch, and the deployment configuration.

In practice, migrating a mid-sized server usually takes one to three days, and the biggest time sink is not the code itself but rebuilding the observability chain, when a team previously relied on Apollo Studio and now has to build an equivalent solution through OpenTelemetry and an envelop plugin.

// Apollo Server context function
const server = new ApolloServer({ typeDefs, resolvers })
await startStandaloneServer(server, {
  context: async ({ req }) => ({
    userId: verifyToken(req.headers.authorization),
  }),
})

// GraphQL Yoga equivalent, using a WHATWG Request object
const yoga = createYoga({
  schema,
  context: async ({ request }) => ({
    userId: verifyToken(request.headers.get('authorization')),
  }),
})

9. Decision guide: which server fits which project type

For teams already embedded in the Apollo ecosystem, running a federated architecture with Apollo Router, or valuing a managed Studio platform with schema checks, Apollo Server is usually the smoother choice. For teams looking for the leanest, most standards-compliant server without vendor lock-in, especially for edge platform deployments, GraphQL Yoga is often the better foundation.

The table below compares the key decision criteria.

10. Summary

11. FAQ: GraphQL Yoga and Apollo Server: The Essentials at a Glance