Apollo Server Express vs Express-GraphQL vs GraphQL Yoga: Architectural Comparison

When building a GraphQL API in Node.js, the server layer is critical. It handles parsing requests, validating queries, executing resolvers, and sending responses. While apollo-server-express, express-graphql, and graphql-yoga all serve this purpose, they differ significantly in maintenance status, architecture, and developer experience. Let's break down the technical realities of each.

🛑 Maintenance Status: Active vs Deprecated

The first thing an architect must check is whether a library is safe to use long-term.

express-graphql is deprecated.

• The maintainers have officially archived the project.
• It does not support newer GraphQL specifications or modern HTTP standards (like GET requests for queries).
• Using it introduces security and compatibility risks.

// express-graphql: Deprecated usage (Do not use)  
const { graphqlHTTP } = require('express-graphql');
app.use('/graphql', graphqlHTTP({ schema }));

apollo-server-express is actively maintained (as part of Apollo Server 4).

• Apollo Server 3 reached End of Life (EOL) in 2024.
• Version 4 requires a slightly different setup, focusing on standalone servers or explicit middleware integration.
• Backed by Apollo Graph Platform.

// apollo-server-express: Apollo Server 4 usage  
const { ApolloServer } = require('@apollo/server');
const { expressMiddleware } = require('@apollo/server/express4');

const server = new ApolloServer({ typeDefs, resolvers });
await server.start();
app.use('/graphql', expressMiddleware(server));

graphql-yoga is actively maintained.

• Maintained by The Guild, a group known for modern GraphQL tooling.
• Regularly updated to match the latest GraphQL specs.
• Designed to be runtime agnostic (Node, Cloudflare, Vercel, etc.).

// graphql-yoga: Current usage  
import { createYoga } from 'graphql-yoga';
import { createServer } from 'http';

const yoga = createYoga({ schema });
const server = createServer(yoga);
server.listen(4000);

⚙️ Setup Complexity: Configuration vs Convention

How much code do you need to write to get a server running?

express-graphql was minimal but rigid.

• Required manual handling of many HTTP details.
• No built-in support for subscriptions or file uploads without extra work.

// express-graphql: Manual setup  
app.use('/graphql', graphqlHTTP({
  schema: mySchema,
  graphiql: true, // Built-in IDE but limited
}));

apollo-server-express is feature-heavy.

• Requires defining plugins for many advanced features.
• Apollo Server 4 separates the server logic from the framework integration more clearly than v3.

// apollo-server-express: Plugin configuration  
const server = new ApolloServer({
  typeDefs,
  resolvers,
  plugins: [ /* Custom plugins for logging, etc. */ ]
});

graphql-yoga aims for zero-config.

• Comes with GraphiQL, CORS, and body parsing built-in by default.
• You often don't need to install additional middleware for basic functionality.

// graphql-yoga: Zero-config features  
const yoga = createYoga({
  schema,
  // GraphiQL is enabled by default in dev
  // CORS is handled automatically
});

🌐 Runtime Flexibility: Node.js vs Edge

Where can you deploy your code?

express-graphql is tied to Node.js.

• Relies heavily on the Express request/response objects.
• Cannot run on edge runtimes like Cloudflare Workers easily.

// express-graphql: Node/Express specific  
// Requires Express app instance
app.use('/graphql', ...);

apollo-server-express is primarily Node.js focused.

• While Apollo has serverless offerings, the express package specifically targets Node environments.
• Moving to edge runtimes usually requires switching to a different Apollo package.

// apollo-server-express: Node specific  
// Tightly coupled with Express middleware pipeline
await server.start();

graphql-yoga is runtime agnostic.

• Built on top of whatwg-fetch standards.
• The same code can often run on Node, Deno, or Edge functions without changes.

// graphql-yoga: Agnostic handler  
// Works as a standard Web Fetch API handler
export const handler = (req) => yoga.handleRequest(req);

🔌 Extensibility: Plugins vs Built-ins

How do you add features like authentication, logging, or subscriptions?

express-graphql has no plugin system.

• You must write custom middleware for everything.
• Subscriptions require a separate implementation (often subscriptions-transport-ws, which is also deprecated).

// express-graphql: Custom middleware  
app.use('/graphql', (req, res, next) => {
  // Manual auth logic
  next();
}, graphqlHTTP({ schema }));

apollo-server-express relies on a robust plugin system.

• Great for enterprise needs (logging, tracing, cache control).
• Subscriptions require apollo-server-plugin or separate WebSocket handling.

// apollo-server-express: Plugin system  
const server = new ApolloServer({
  typeDefs,
  resolvers,
  plugins: [
    { async requestDidStart() { /* Logging logic */ } }
  ]
});

graphql-yoga includes many features out-of-the-box.

• Subscriptions, file uploads, and deferred queries are often built-in.
• Uses GraphQL Envelop plugins for extensibility, which are lightweight and composable.

// graphql-yoga: Built-in features  
const yoga = createYoga({
  schema,
  // Subscriptions and uploads often work without extra config
  // Plugins use the envelop standard
  plugins: [ /* envelop plugins */ ]
});

🤝 Similarities: Shared Ground

Despite their differences, all three share core GraphQL fundamentals.

1. 📜 Schema Definition

• All use the GraphQL Schema Definition Language (SDL).
• Resolvers are mapped similarly across all packages.

// Shared Schema Definition  
const typeDefs = `#graphql
  type Query {
    hello: String
  }
`;

// Shared Resolver Pattern  
const resolvers = {
  Query: {
    hello: () => 'world'
  }
};

2. 🔍 GraphiQL Interface

• All support an in-browser IDE for testing queries.
• graphql-yoga and apollo-server-express enable this by default in development.

// All support GraphiQL  
// apollo-server-express: Enabled by default in dev
// graphql-yoga: Enabled by default in dev
// express-graphql: Enabled via `graphiql: true`

3. 🛡️ Context Injection

• All allow passing a context object to resolvers.
• Used for auth users, database connections, etc.

// Shared Context Pattern  
// apollo-server-express
context: ({ req }) => ({ user: req.user })

// graphql-yoga
context: ({ req }) => ({ user: req.user })

// express-graphql
context: { user: req.user }

📊 Summary: Key Differences

💡 The Big Picture

express-graphql is a legacy tool.

• It served the community well in the past but is now unsafe for production.
• Action: Migrate away from this immediately if found in an existing codebase.

apollo-server-express is the enterprise choice.

• Best for teams needing Apollo Studio, complex caching, or existing Apollo infrastructure.
• Requires more configuration but offers deep observability.

graphql-yoga is the modern standard.

• Best for new projects, especially those targeting serverless or edge deployments.
• Reduces boilerplate and adheres strictly to the GraphQL spec.

Final Thought: For most new Node.js projects today, graphql-yoga offers the best balance of simplicity and power. However, if your organization relies heavily on Apollo's commercial tooling, apollo-server-express remains a solid, supported choice. Avoid express-graphql entirely.