express-graphql vs apollo-server
GraphQL 服务器库
express-graphqlapollo-server类似的npm包:

GraphQL 服务器库

GraphQL 服务器库用于构建和处理 GraphQL API,提供了一种灵活和高效的数据查询方式。它们允许客户端请求所需的数据,避免了传统 REST API 中的过度获取或不足获取问题。Apollo Server 和 Express-GraphQL 是两个流行的选择,各自具有独特的功能和优势,适用于不同的开发需求和场景。

npm下载趋势

3 年

GitHub Stars 排名

统计详情

npm包名称
下载量
Stars
大小
Issues
发布时间
License
express-graphql389,7066,291-555 年前MIT
apollo-server013,94926.6 kB792 年前MIT

功能对比: express-graphql vs apollo-server

集成能力

  • express-graphql:

    Express-GraphQL 作为 Express 中间件,允许开发者在现有的 Express 应用中快速添加 GraphQL 功能。它的集成相对简单,适合已有 Express 生态系统的项目。

  • apollo-server:

    Apollo Server 提供了与多种数据源(如 REST API、数据库、第三方服务等)的无缝集成。它支持数据合并和解析器的灵活配置,使得在复杂的应用中能够高效地聚合数据。

开发者工具

  • express-graphql:

    Express-GraphQL 提供了基本的 GraphiQL 界面,允许开发者在浏览器中测试和调试 GraphQL 查询,但功能相对较少,主要适合简单的开发和测试。

  • apollo-server:

    Apollo Server 附带了 Apollo Studio,一个强大的开发者工具,提供了实时查询、性能监控和调试功能。这使得开发者能够轻松优化和管理 GraphQL API。

性能优化

  • express-graphql:

    Express-GraphQL 的性能优化主要依赖于 Express 的中间件机制,开发者需要手动实现缓存和优化策略,适合对性能有特殊要求的项目。

  • apollo-server:

    Apollo Server 具有内置的缓存机制,可以显著提高查询性能。它支持持久化查询和批处理请求,减少了网络请求的数量,从而提高了响应速度。

社区支持

  • express-graphql:

    Express-GraphQL 也有良好的社区支持,但相对较小,文档和示例数量不及 Apollo Server 丰富。

  • apollo-server:

    Apollo Server 拥有活跃的社区和丰富的文档支持,提供大量的示例和最佳实践,帮助开发者快速上手和解决问题。

学习曲线

  • express-graphql:

    Express-GraphQL 的学习曲线较为简单,特别适合已经熟悉 Express 的开发者。它的 API 设计简单,易于理解和使用,适合快速原型开发。

  • apollo-server:

    Apollo Server 的学习曲线相对平缓,尤其是对于已经熟悉 Apollo Client 的开发者。它的功能丰富,但文档清晰易懂,适合初学者和经验丰富的开发者。

如何选择: express-graphql vs apollo-server

  • express-graphql:

    选择 Express-GraphQL 如果你希望在现有的 Express 应用程序中轻松集成 GraphQL。它提供了一个简单的解决方案,适合小型项目或需要快速原型开发的场景。

  • apollo-server:

    选择 Apollo Server 如果你需要一个功能丰富的 GraphQL 服务器,支持多种数据源集成、实时订阅、缓存和强大的开发者工具。它适合需要快速开发和扩展的项目,尤其是当你使用 Apollo Client 时。

express-graphql的README

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,
});