@apollo/[email protected]

Patch Changes

• #7073 e7f524eac Thanks @glasser! - Never interpret GET requests as batched. In previous versions of Apollo Server 4, a GET request whose body was a JSON array with N elements would be interpreted as a batch of the operation specified in the query string repeated N times. Now we just ignore the body for GET requests (like in Apollo Server 3), and never treat them as batched.

• #7071 0ed389ce8 Thanks @glasser! - Fix v4 regression: gateway implementations should be able to set HTTP response headers and the status code.

@apollo/[email protected]

Patch Changes

• #7073 e7f524eac Thanks @glasser! - Never interpret GET requests as batched. In previous versions of Apollo Server 4, a GET request whose body was a JSON array with N elements would be interpreted as a batch of the operation specified in the query string repeated N times. Now we just ignore the body for GET requests (like in Apollo Server 3), and never treat them as batched.

• #7071 0ed389ce8 Thanks @glasser! - Fix v4 regression: gateway implementations should be able to set HTTP response headers and the status code.

• Updated dependencies [e7f524eac, 0ed389ce8]:

  • @apollo/[email protected]

@apollo/[email protected]

Patch Changes

• #7035 b3f400063 Thanks @barryhagan! - Errors resulting from an attempt to use introspection when it is not enabled now have an additional validationErrorCode: 'INTROSPECTION_DISABLED' extension; this value is part of a new enum ApolloServerValidationErrorCode exported from @apollo/server/errors.

@apollo/[email protected]

Patch Changes

• #7035 b3f400063 Thanks @barryhagan! - Errors resulting from an attempt to use introspection when it is not enabled now have an additional validationErrorCode: 'INTROSPECTION_DISABLED' extension; this value is part of a new enum ApolloServerValidationErrorCode exported from @apollo/server/errors.

• #7066 f11d55a83 Thanks @trevor-scheer! - Add a test to validate error message and code for invalid operation names via GET

• #7055 d0d8f4be7 Thanks @trevor-scheer! - Fix build configuration issue and align on CJS correctly

• Updated dependencies [b3f400063]:

  • @apollo/[email protected]

@apollo/[email protected]

Patch Changes

• #7049 3daee02c6 Thanks @glasser! - Raise minimum engines requirement from Node.js v14.0.0 to v14.16.0. This is the minimum version of Node 14 supported by the engines requirement of [email protected].

• #7049 3daee02c6 Thanks @glasser! - Require Node.js v14 rather than v12. This change was intended for v4.0.0 and the documentation already stated this requirement, but was left off of the package.json engines field in @apollo/server inadvertently.

@apollo/[email protected]

Patch Changes

• #7049 3daee02c6 Thanks @glasser! - Raise minimum engines requirement from Node.js v14.0.0 to v14.16.0. This is the minimum version of Node 14 supported by the engines requirement of [email protected].

• Updated dependencies [3daee02c6, 3daee02c6]:

  • @apollo/[email protected]

@apollo/[email protected]

Patch Changes

• #7049 3daee02c6 Thanks @glasser! - Raise minimum engines requirement from Node.js v14.0.0 to v14.16.0. This is the minimum version of Node 14 supported by the engines requirement of [email protected].

• Updated dependencies [3daee02c6, 3daee02c6]:

  • @apollo/[email protected]

@apollo/[email protected]

Initial release of @apollo/usage-reporting-protobuf with support for Apollo Server 4. The version of this plugin designed for Apollo Server 2 and 3 was named apollo-reporting-protobuf. This is an internal implementation detail of Apollo Server and is not intended for general direct use.

@apollo/[email protected]

BREAKING CHANGES

Apollo Server contains quite a few breaking changes: most notably, a brand new package name! Read our migration guide for more details on how to update your app.

Bumped dependencies

The minimum versions of these dependencies have been bumped to provide an improved foundation for the development of future features.

• Dropped support for Node.js v12, which is no longer under long-term support from the Node.js Foundation.
• Dropped support for versions of the graphql library prior to v16.6.0.
  • Upgrading graphql may require you to upgrade other libraries that are installed in your project. For example, if you use Apollo Server with Apollo Gateway, you should upgrade Apollo Gateway to at least v0.50.1 or any v2.x version for full graphql 16 support before upgrading to Apollo Server 4.
• If you use Apollo Server with TypeScript, you must use TypeScript v4.7.0 or newer.

New package structure

Apollo Server 4 is distributed in the @apollo/server package. This package replaces apollo-server, apollo-server-core, apollo-server-express, apollo-server-errors, apollo-server-types, and apollo-server-plugin-base.

The @apollo/server package exports the ApolloServer class. In Apollo Server 3, individual web framework integrations had their own subclasses of ApolloServer. In Apollo Server 4, there is a single ApolloServer class; web framework integrations define their own functions which use a new stable integration API on ApolloServer to execute operations.

Other functionality is exported from "deep imports" on @apollo/server. startStandaloneServer (the replacement for the batteries-included apollo-server package) is exported from @apollo/server/standalone. expressMiddleware (the replacement for apollo-server-express) is exported from @apollo/server/express4. Plugins such as ApolloServerPluginUsageReporting are exported from paths such as @apollo/server/plugin/usageReporting.

The @apollo/server package is built natively as both an ECMAScript Module (ESM) and as a CommonJS module (CJS); Apollo Server 3 was only built as CJS. This allows ESM-native bundlers to create more efficient bundles.

Other packages have been renamed:

• apollo-datasource-rest is now @apollo/datasource-rest.
• apollo-server-plugin-response-cache is now @apollo/server-plugin-response-cache.
• apollo-server-plugin-operation-registry is now @apollo/server-plugin-operation-registry.
• apollo-reporting-protobuf (an internal implementation detail for the usage reporting plugin) is now @apollo/usage-reporting-protobuf.

Removed web framework integrations

Prior to Apollo Server 4, the only way to integrate a web framework with Apollo Server was for the Apollo Server project to add an official apollo-server-x subclass maintained as part of the core project. Apollo Server 4 makes it easy for users to integrate with their favorite web framework, and so we have removed most of the framework integrations from the core project so that framework integrations can be maintained by users who are passionate about that framework. Because of this, the core project no longer directly maintains integrations for Fastify, Hapi, Koa, Micro, AWS Lambda,Google Cloud Functions, Azure Functions, or Cloudflare. We expect that community integrations will eventually be created for most of these frameworks and serverless environments.

Apollo Server's support for the Express web framework no longer also supports its older predecessor Connect.

Removed constructor options

• The dataSources constructor option essentially added a post-processing step to your app's context function, creating DataSource subclasses and adding them to a dataSources field on your context value. This meant the TypeScript type the context function returns was different from the context type your resolvers and plugins receive. Additionally, this design obfuscated that DataSource objects are created once per request (i.e., like the rest of the context object). Apollo Server 4 removes the dataSources constructor option. You can now treat DataSources like any other part of your context object. See the migration guide for details on how to move your dataSources function into your context function.
• The modules constructor option was just a slightly different way of writing typeDefs and resolvers (although it surprisingly used entirely different logic under the hood). This option has been removed.
• The mocks and mockEntireSchema constructor options wrapped an outdated version of the @graphql-tools/mocks library to provide mocking functionality. These constructor options have been removed; you can instead directly incorporate the @graphql-tools/mock package into your app, enabling you to get the most up-to-date mocking features.
• The debug constructor option (which defaulted to true unless the NODE_ENV environment variable is either production or test) mostly controlled whether GraphQL errors responses included stack traces, but it also affected the default log level on the default logger. The debug constructor option has been removed and is replaced with includeStacktraceInErrorResponses, which does exactly what it says it does.
• The formatResponse constructor option has been removed; its functionality can be replaced by the willSendResponse plugin hook.
• The executor constructor option has been removed; the ability to replace graphql-js's execution functionality is still available via the gateway option.

Removed features

• Apollo Server 4 no longer responds to health checks on the path /.well-known/apollo/server-health. You can run a trivial GraphQL operation as a health check, or you can add a custom health check via your web framework.
• Apollo Server 4 no longer cares what URL path is used to access its functionality. Instead of specifying the path option to various Apollo Server methods, just use your web framework's routing feature to mount the Apollo Server integration at the appropriate path.
• Apollo Server 4's Express middleware no longer wraps the body-parser and cors middleware; it is your responsibility to install and set up these middleware yourself when using a framework integration. (The standalone HTTP server sets up body parsing and CORS for you, but without the ability to configure their details.)
• Apollo Server no longer re-exports the gql tag function from graphql-tag. If you want to use gql, install the graphql-tag package.
• Apollo Server no longer defines its own ApolloError class and toApolloError function. Instead, use GraphQLError from the graphql package.
• Apollo Server no longer exports error subclasses representing the errors that it creates, such as SyntaxError. Instead, it exports an enum ApolloServerErrorCode that you can use to recognize errors created by Apollo Server.
• Apollo Server no longer exports the ForbiddenError and AuthenticationError classes. Instead, you can define your own error codes for these errors or other errors.
• The undocumented __resolveObject pseudo-resolver is no longer supported.
• The requestAgent option to ApolloServerPluginUsageReporting has been removed.
• In the JSON body of a POST request, the variables and extensions fields must be objects, not JSON-encoded strings.
• The core Apollo Server packages no longer provide a landing page plugin for the unmaintained GraphQL Playground UI. We have published an Apollo Server 4-compatible landing page plugin in the package @apollo/server-plugin-landing-page-graphql-playground, but do not intend to maintain it further after this one-time publish.

Modified functionality

• The context function is now provided to your integration function (such as startStandaloneServer or expressMiddleware) rather than to the new ApolloServer constructor.
• The executeOperation method now directly accepts a context value, rather than accepting the arguments to your context function.
• The formatError hook now receives the original thrown error in addition to the formatted error.
• Formatted errors no longer contain the extensions.exception field containing all enumerable properties of the originally thrown error. If you want to include more information in an error, specify them as extensions when creating a GraphQLError. The stacktrace field is provided directly on extensions rather than nested under exception.
• All errors responses are consistently rendered as application/json JSON responses, and the formatError hook is used consistently.
• Other changes to error handling outside of resolvers are described in the migration guide.
• The parseOptions constructor option only affects the parsing of incoming operations, not the parsing of typeDefs.

Plugin API changes

• The field GraphQLRequestContext.context has been renamed to contextValue.
• The field GraphQLRequestContext.logger is now readonly.
• The fields GraphQLRequestContext.schemaHash and GraphQLRequestContext.debug have been removed.
• The type GraphQLServiceContext has been rena...

@apollo/[email protected]

Initial release of @apollo/server-plugin-response-cache with support for Apollo Server 4. The version of this plugin designed for Apollo Server 2 and 3 was named apollo-server-plugin-response-cache.