express-graphql vs apollo-server-express vs graphql-yoga
GraphQL Server Libraries
express-graphqlapollo-server-expressgraphql-yoga

GraphQL Server Libraries

GraphQL server libraries provide tools and frameworks to build GraphQL APIs, enabling developers to define the structure of the data required by clients and serve it efficiently. These libraries facilitate the creation of robust, scalable, and flexible APIs that can handle complex queries and mutations while providing a single endpoint for data retrieval. They often integrate seamlessly with existing web frameworks, allowing developers to leverage their existing knowledge and infrastructure. Each library has its unique features and design philosophies, catering to different use cases and preferences in the development community.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package
Downloads
Stars
Size
Issues
Publish
License
express-graphql286,9886,292-555 years agoMIT
apollo-server-express013,94727.6 kB792 years agoMIT
graphql-yoga08,488293 kB1312 months agoMIT

Feature Comparison: express-graphql vs apollo-server-express vs graphql-yoga

Integration

  • express-graphql:

    Express-GraphQL is designed specifically for Express, providing a straightforward way to set up a GraphQL endpoint. It allows for easy integration into existing Express applications and is highly customizable for developers who want to tailor their GraphQL server's behavior.

  • apollo-server-express:

    Apollo Server integrates seamlessly with Express, allowing you to add GraphQL capabilities to your existing Express applications with minimal configuration. It supports middleware and can be easily combined with other Express middleware for enhanced functionality.

  • graphql-yoga:

    GraphQL Yoga is built on top of Express and integrates well with various frameworks. It provides a simple setup process and is designed for ease of use, making it a good choice for developers who want to get started quickly.

Features and Extensibility

  • express-graphql:

    Express-GraphQL is minimalistic and focuses on providing the core GraphQL functionality. While it lacks some advanced features out of the box, it allows developers to extend its capabilities through custom middleware and resolvers, providing flexibility for those who want to build their own solutions.

  • apollo-server-express:

    Apollo Server offers a rich set of features, including built-in support for caching, error handling, and performance tracing. Its extensibility allows developers to create custom directives and middleware, making it suitable for complex applications that require advanced functionality.

  • graphql-yoga:

    GraphQL Yoga comes with sensible defaults and built-in features such as subscriptions, file uploads, and a GraphQL playground for testing queries. Its extensibility allows developers to customize the server easily, making it suitable for a wide range of applications.

Learning Curve

  • express-graphql:

    Express-GraphQL has a relatively gentle learning curve, especially for those already familiar with Express. Its straightforward API and focus on core GraphQL concepts make it accessible for beginners while still allowing for advanced customization.

  • apollo-server-express:

    Apollo Server has a moderate learning curve due to its extensive features and configuration options. However, its comprehensive documentation and community support make it easier for developers to get started and leverage its capabilities effectively.

  • graphql-yoga:

    GraphQL Yoga is designed to be beginner-friendly, offering a simple setup and intuitive API. Its focus on ease of use makes it an excellent choice for developers who are new to GraphQL and want to quickly prototype applications.

Performance

  • express-graphql:

    Express-GraphQL is lightweight and performs well for straightforward use cases. However, performance can vary based on how the server is configured and how efficiently the resolvers are implemented, requiring careful optimization for larger applications.

  • apollo-server-express:

    Apollo Server is optimized for performance, with built-in features for caching and batching requests. It efficiently handles complex queries and can scale to meet the demands of high-traffic applications, making it suitable for production environments.

  • graphql-yoga:

    GraphQL Yoga is designed for performance and scalability, providing features like automatic batching and subscriptions out of the box. Its architecture allows for efficient handling of multiple requests, making it suitable for applications with real-time data requirements.

Community and Ecosystem

  • express-graphql:

    Express-GraphQL benefits from the widespread adoption of Express, which has a vast community and numerous middleware options. While it may not have as many dedicated resources as Apollo, the Express community provides ample support for developers.

  • apollo-server-express:

    Apollo Server has a large and active community, along with a rich ecosystem of tools and libraries. This support network provides developers with extensive resources, tutorials, and third-party integrations, enhancing the development experience.

  • graphql-yoga:

    GraphQL Yoga, while newer, has gained popularity for its simplicity and ease of use. It has a growing community and is increasingly being adopted in various projects, providing a supportive environment for developers.

How to Choose: express-graphql vs apollo-server-express vs graphql-yoga

  • express-graphql:

    Select Express-GraphQL if you prefer a lightweight, minimalistic approach to integrating GraphQL into an existing Express application. It's suitable for developers who want full control over their GraphQL implementation without additional overhead.

  • apollo-server-express:

    Choose Apollo Server if you need a comprehensive solution with built-in support for features like caching, subscriptions, and schema stitching. It's ideal for applications that require advanced GraphQL capabilities and a rich ecosystem of tools and integrations.

  • graphql-yoga:

    Opt for GraphQL Yoga if you want an easy-to-use, flexible server that comes with sensible defaults and built-in support for features like subscriptions and file uploads. It's great for rapid development and prototyping, especially for those new to GraphQL.

README for express-graphql

GraphQL HTTP Server Middleware

npm version Build Status Coverage Status

Create a GraphQL HTTP server with any HTTP web framework that supports connect styled middleware, including Connect itself, Express and Restify.

Installation

npm install --save express-graphql

TypeScript

This module includes a TypeScript declaration file to enable auto complete in compatible editors and type information for TypeScript projects.

Simple Setup

Just mount express-graphql as a route handler:

const express = require('express');
const { graphqlHTTP } = require('express-graphql');

const app = express();

app.use(
  '/graphql',
  graphqlHTTP({
    schema: MyGraphQLSchema,
    graphiql: true,
  }),
);

app.listen(4000);

Setup with Restify

Use .get or .post (or both) rather than .use to configure your route handler. If you want to show GraphiQL in the browser, set graphiql: true on your .get handler.

const restify = require('restify');
const { graphqlHTTP } = require('express-graphql');

const app = restify.createServer();

app.post(
  '/graphql',
  graphqlHTTP({
    schema: MyGraphQLSchema,
    graphiql: false,
  }),
);

app.get(
  '/graphql',
  graphqlHTTP({
    schema: MyGraphQLSchema,
    graphiql: true,
  }),
);

app.listen(4000);

Options

The graphqlHTTP function accepts the following options:

  • schema: A GraphQLSchema instance from GraphQL.js. A schema must be provided.

  • graphiql: If true, presents GraphiQL when the GraphQL endpoint is loaded in a browser. We recommend that you set graphiql to true when your app is in development, because it's quite useful. You may or may not want it in production. Alternatively, instead of true you can pass in an options object:

    • defaultQuery: An optional GraphQL string to use when no query is provided and no stored query exists from a previous session. If undefined is provided, GraphiQL will use its own default query.

    • headerEditorEnabled: An optional boolean which enables the header editor when true. Defaults to false.

  • rootValue: A value to pass as the rootValue to the graphql() function from GraphQL.js/src/execute.js.

  • context: A value to pass as the context to the graphql() function from GraphQL.js/src/execute.js. If context is not provided, the request object is passed as the context.

  • pretty: If true, any JSON response will be pretty-printed.

  • extensions: An optional function for adding additional metadata to the GraphQL response as a key-value object. The result will be added to the "extensions" field in the resulting JSON. This is often a useful place to add development time metadata such as the runtime of a query or the amount of resources consumed. This may be an async function. The function is given one object as an argument: { document, variables, operationName, result, context }.

  • validationRules: Optional additional validation rules queries must satisfy in addition to those defined by the GraphQL spec.

  • customValidateFn: An optional function which will be used to validate instead of default validate from graphql-js.

  • customExecuteFn: An optional function which will be used to execute instead of default execute from graphql-js.

  • customFormatErrorFn: An optional function which will be used to format any errors produced by fulfilling a GraphQL operation. If no function is provided, GraphQL's default spec-compliant formatError function will be used.

  • customParseFn: An optional function which will be used to create a document instead of the default parse from graphql-js.

  • formatError: is deprecated and replaced by customFormatErrorFn. It will be removed in version 1.0.0.

In addition to an object defining each option, options can also be provided as a function (or async function) which returns this options object. This function is provided the arguments (request, response, graphQLParams) and is called after the request has been parsed.

The graphQLParams is provided as the object { query, variables, operationName, raw }.

app.use(
  '/graphql',
  graphqlHTTP(async (request, response, graphQLParams) => ({
    schema: MyGraphQLSchema,
    rootValue: await someFunctionToGetRootValue(request),
    graphiql: true,
  })),
);

HTTP Usage

Once installed at a path, express-graphql will accept requests with the parameters:

  • query: A string GraphQL document to be executed.

  • variables: The runtime values to use for any GraphQL query variables as a JSON object.

  • operationName: If the provided query contains multiple named operations, this specifies which operation should be executed. If not provided, a 400 error will be returned if the query contains multiple named operations.

  • raw: If the graphiql option is enabled and the raw parameter is provided raw JSON will always be returned instead of GraphiQL even when loaded from a browser.

GraphQL will first look for each parameter in the query string of a URL:

/graphql?query=query+getUser($id:ID){user(id:$id){name}}&variables={"id":"4"}

If not found in the query-string, it will look in the POST request body.

If a previous middleware has already parsed the POST body, the request.body value will be used. Use multer or a similar middleware to add support for multipart/form-data content, which may be useful for GraphQL mutations involving uploading files. See an example using multer.

If the POST body has not yet been parsed, express-graphql will interpret it depending on the provided Content-Type header.

  • application/json: the POST body will be parsed as a JSON object of parameters.

  • application/x-www-form-urlencoded: this POST body will be parsed as a url-encoded string of key-value pairs.

  • application/graphql: The POST body will be parsed as GraphQL query string, which provides the query parameter.

Combining with Other Express Middleware

By default, the express request is passed as the GraphQL context. Since most express middleware operates by adding extra data to the request object, this means you can use most express middleware just by inserting it before graphqlHTTP is mounted. This covers scenarios such as authenticating the user, handling file uploads, or mounting GraphQL on a dynamic endpoint.

This example uses express-session to provide GraphQL with the currently logged-in session.

const session = require('express-session');
const { graphqlHTTP } = require('express-graphql');

const app = express();

app.use(session({ secret: 'keyboard cat', cookie: { maxAge: 60000 } }));

app.use(
  '/graphql',
  graphqlHTTP({
    schema: MySessionAwareGraphQLSchema,
    graphiql: true,
  }),
);

Then in your type definitions, you can access the request via the third "context" argument in your resolve function:

new GraphQLObjectType({
  name: 'MyType',
  fields: {
    myField: {
      type: GraphQLString,
      resolve(parentValue, args, request) {
        // use `request.session` here
      },
    },
  },
});

Providing Extensions

The GraphQL response allows for adding additional information in a response to a GraphQL query via a field in the response called "extensions". This is added by providing an extensions function when using graphqlHTTP. The function must return a JSON-serializable Object.

When called, this is provided an argument which you can use to get information about the GraphQL request:

{ document, variables, operationName, result, context }

This example illustrates adding the amount of time consumed by running the provided query, which could perhaps be used by your development tools.

const { graphqlHTTP } = require('express-graphql');

const app = express();

app.use(session({ secret: 'keyboard cat', cookie: { maxAge: 60000 } }));

const extensions = ({
  document,
  variables,
  operationName,
  result,
  context,
}) => {
  return {
    runTime: Date.now() - context.startTime,
  };
};

app.use(
  '/graphql',
  graphqlHTTP((request) => {
    return {
      schema: MyGraphQLSchema,
      context: { startTime: Date.now() },
      graphiql: true,
      extensions,
    };
  }),
);

When querying this endpoint, it would include this information in the result, for example:

{
  "data": { ... }
  "extensions": {
    "runTime": 135
  }
}

Additional Validation Rules

GraphQL's validation phase checks the query to ensure that it can be successfully executed against the schema. The validationRules option allows for additional rules to be run during this phase. Rules are applied to each node in an AST representing the query using the Visitor pattern.

A validation rule is a function which returns a visitor for one or more node Types. Below is an example of a validation preventing the specific field name metadata from being queried. For more examples see the specifiedRules in the graphql-js package.

import { GraphQLError } from 'graphql';

export function DisallowMetadataQueries(context) {
  return {
    Field(node) {
      const fieldName = node.name.value;

      if (fieldName === 'metadata') {
        context.reportError(
          new GraphQLError(
            `Validation: Requesting the field ${fieldName} is not allowed`,
          ),
        );
      }
    },
  };
}

Disabling introspection

Disabling introspection does not reflect best practices and does not necessarily make your application any more secure. Nevertheless, disabling introspection is possible by utilizing the NoSchemaIntrospectionCustomRule provided by the graphql-js package.

import { specifiedRules, NoSchemaIntrospectionCustomRule } from 'graphql';

app.use(
  '/graphql',
  graphqlHTTP((request) => {
    return {
      schema: MyGraphQLSchema,
      validationRules: [...specifiedRules, NoSchemaIntrospectionCustomRule],
    };
  }),
);

Other Exports

getGraphQLParams(request: Request): Promise<GraphQLParams>

Given an HTTP Request, this returns a Promise for the parameters relevant to running a GraphQL request. This function is used internally to handle the incoming request, you may use it directly for building other similar services.

const { getGraphQLParams } = require('express-graphql');

getGraphQLParams(request).then((params) => {
  // do something...
});

Debugging Tips

During development, it's useful to get more information from errors, such as stack traces. Providing a function to customFormatErrorFn enables this:

customFormatErrorFn: (error) => ({
  message: error.message,
  locations: error.locations,
  stack: error.stack ? error.stack.split('\n') : [],
  path: error.path,
});