Restore "batteries-include" ApolloServer (v4)

[trevor-scheer]

This PR (re) introduces the "batteries-included" version of ApolloServer. This server manages an express instance internally, meaning it is explicitly not configurable. This is intended to be a nice getting started experience, but more complicated use cases should "eject" to the expressMiddleware (i.e. serving various paths, installing other middlewares, etc.)

The usage is as follows:

import { ApolloServer, standaloneServer } from "@apollo/server";

interface MyContext {
  token: string;
}

const apolloServerInstance = new ApolloServer<MyContext>({
  typeDefs,
  resolvers,
});
const { url } = await standaloneServer(apolloServerInstance, {
  context: async (req, _res) => ({
    token: await getTokenForRequest(req),
  }),
}).listen({ port: 4000 });

console.log(`ApolloServer listening at: ${url}`);

standaloneServer returns an ApolloServerStandalone instance. The intention is to await the call to listen() on this class. The listen() method accepts the same arguments that http.Server's listen() method does (in the options form only).

Additionally, this PR introduces a new public function on the ApolloServer class, addPlugin. This function can be used to add plugins to ApolloServer (only in its initialized state). This enables us to use the drain http server plugin with the approach we've taken since the ApolloServer instance (and its plugins) are instantiated before the httpServer is, which the drain plugin needs a reference to. This API enables other "standalone server" authors to do the same if they choose.

Fixes #6085

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 4558722:

Sandbox	Source
Apollo Server Typescript	Configuration
Apollo Server	Configuration

[glasser]

looking great

[glasser]

At first I was surprised that the zillion tests that show "post to /graphql" don't break but I guess it's because we ignore the path. I think maybe a follow-up PR could replace all the /graphql with / in the tests?

[glasser]

It might make sense to update the integration test's API to take an URL instead of an http.Server (are there any uses of the httpServer that can't be replaced by an URL? supertest can). That way we could support integrations that somehow don't literally use an http.Server (maybe some serverless things might work that way?) as long as they can serve at an URL. I think this could be a follow-up PR though!

[glasser]

Not quite sure why the sample code is showing that try/catch though (which logs the last line even on error) rather than just

import { ApolloServer, standaloneServer } from "@apollo/server";

interface MyContext {
  token: string;
}

const apolloServerInstance = new ApolloServer<MyContext>({ typeDefs, resolvers });
const { url } = await standaloneServer(apolloServerInstance, {
  context: async (req, _res) => ({ token: await getTokenForRequest(req) }),
}).listen({ port: 4000 });
console.log(`ApolloServer listening at: ${url}`);

(also the example doesn't work due to having non-base context but no context function)

[trevor-scheer]

Updated example to remove try/catch, but we agreed sync the context is actually fine. Will follow up in a separate PR with those changes!

[trevor-scheer]

At first I was surprised that the zillion tests that show "post to /graphql" don't break but I guess it's because we ignore the path. I think maybe a follow-up PR could replace all the /graphql with / in the tests?

Resolved in #6425