The Apollo Server 2.0 release candidate dramatically simplifies the API for building a GraphQL server without compromising on features. It's also completely backward compatible, so you don't have to worry about breaking changes when upgrading.
While it's possible to migrate an existing server to the 2.0 release candidate without any changes, we recommend changing to new patterns we're suggesting in order to take advantage of all the latest Apollo Server features, reduce the boilerplate, and enable future flexibility. To learn how to migrate to the 2.0 release candidate from version 1.0, please read the following guide.
> **Note:** In the release candidate of Apollo Server 2.0 only Express and Hapi are supported. Additional integrations will be implemented in the official 2.0 release.
Apollo Server 2.0 ships with the `gql` tag for **editor syntax highlighting** and **auto-formatting** with Prettier. In the future, we will be using it for statically analyzing GraphQL queries, so Apollo Servers requires wrapping your schema with `gql`.
Apollo Server 2.0 simplifies implementing a GraphQL server. Apollo Server 1.0 revolved around providing middleware-based solutions, which had to be added to an application which already existed. These middleware implementations were tied to the HTTP server in use (e.g. `apollo-server-express` for Express implementations, `apollo-server-hapi` for hapi, etc.).
* [**Middleware option**](#Middleware): If the application being migrated implements Apollo Server alongside other middleware, there are some packages which can be removed, but adding the `apollo-server-{integration}` package and switching to using the new `applyMiddleware` API should still simplify the setup. In this case, check the [Middleware](#Middleware) section.
* [**Stand-alone option**](#Stand-alone): If the application being migrated is only used as a GraphQL server, Apollo Server 2.0 _eliminates the need to run a separate HTTP server_ and allows some dependencies to be removed. In these cases, the [Stand-alone](#Stand-alone) option will reduce the amount of code necessary for running a GraphQL server.
With the middleware option used by Apollo Server 1.0 users, it is necessary to install the release candidate version of `apollo-server-express`. To do this, use the `rc` tag when installing:
For starting a production-ready GraphQL server quickly, Apollo Server 2.0 ships with a built-in server, so starting a server (e.g. Express, Koa, etc.) is no longer necessary.
For these cases, it's possible to remove the existing `apollo-server-{integrations}` package and add the new `apollo-server` release candidate. If using Express, this can be done by running:
For middleware that is collocated with the GraphQL endpoint, Apollo Server 2 allows middleware mounted on the same path before `applyMiddleware` is called. For example, this server runs an authentication middleware before GraphQL execution.
For many existing instances of Apollo Server, the schema is created at runtime before server startup, using `makeExecutableSchema` or `mergeSchemas`. Apollo Server 2 stays backwards compatible with these more complex schemas, accepting it as the `schema` field in the server constructor options. Additionally, Apollo Server 2 exports all of `graphql-tools`, so `makeExecutableSchema` and other functions can be imported directly from Apollo Server.
Apollo Server 1 allowed request headers to be used in the construction of the GraphQL options. Apollo Server 2 allows constructor to create the context based upon the request.
```js
//old way
graphqlExpress((req, res) => ({
schema: myGraphQLSchema,
context: {
token: req.headers['auth-token'],
},
}))
//new way
new ApolloServer({
schema: myGraphQLSchema,
context: ({req, res}) => ({
token: req.headers['auth-token'],
}),
});
```
For most other functions that might have required access to the middleware arguments, such as `formatParams`, `formatError`, and `formatResponse`, it is possible to create a `graphql-extension`.
For more complicated use cases, the `ApolloServer` class can be extended to override the `createGraphQLServerOptions` function to create parameters based on the same argument that's passed to the context.
<h2id="log-function">Replacing `logFunction`</h2>
Apollo Server 2 removes the `logFunction` in favor of using `graphql-extensions`, which provides a more structured and flexible way of instrumenting Apollo Server. The explanation of how to do this more granular logging, can be found in the [metrics section](./features/metrics.html)
<h2id="graphiql">Replacing GraphiQL</h2>
Apollo Server 2 ships with GraphQL Playground instead of GraphiQL and collocates the gui with the endpoint. GraphQL playground can be customized in the following manner.
// These will be defined for both new or existing servers
typeDefs,
resolvers,
});
server.applyMiddleware({
app, // app is from an existing express app
gui: {
endpoint?: string
subscriptionEndpoint?: string
tabs: [
{
endpoint: string
query: string
variables?: string
responses?: string[]
headers?: { [key: string]: string }
},
],
}
});
app.listen({ port: 4000 }, () =>
console.log(`🚀 Server ready at http://localhost:4000${server.graphqlPath}`)
)
```
Some Apollo Server 1 implementations use a custom version of GraphiQL, which can be added to Apollo Server 2 as a middleware or ported to use the [React version of GraphQL Playground](https://www.npmjs.com/package/graphql-playground-react).