apollo-server-lambda: outsource Lambda expertise

Before this change, apollo-server-lambda contained a lot of code that tried to
understand the formats of Lambda event (request) and result (response)
formats. It tried to work with APIGatewayProxy messages of payloadFormatVersion
1.0 and 2.0 as well as ALB.

But understanding the intricacies of the various Lambda message formats isn't
really what the Apollo Server project is about. A pretty large fraction of all
maintenance on Apollo Server in 2021 has gone into tweaking details of the
Lambda event parsing and making the Lambda handler support all AS features
without the help of a library supporting composable middleware.

This PR (targeted for AS3) throws away the laboriously constructed bespoke
Lambda parsing and faux-middleware implementation and replaces it with two
packages that solve these problems for us: `@vendia/serverless-express` which
understands a variety of Lambda input and output formats and converts them to
Express format, and `express`, the most popular Node library for defining HTTP
server behavior. (Note that `@vendia/serverless-express` is not related to the
`serverless` CLI/framework.)

Now `apollo-server-lambda` is just a convenience wrapper around
`apollo-server-express`. It has to deal with the difference in startup logic
between serverless and non-serverless environments, but it doesn't have to
reimplement all of the Lambda and HTTP logic from scratch.

As an added advantage, you can now optionally provide your own express app to
`apollo-server-lambda`. Previously, `apollo-server-lambda` gave no real way to
customize any of its behavior past the particular options we define, because
Lambda doesn't have a built-in middleware framework. Since we are removing some
built-in features like `graphql-upload` integration in AS3, it's important that
we continue a way to add custom behavior to your Lambda server. Letting you
define that custom behavior with a standard Express app seems reasonable.

We recognize that Lambda users generally care strongly about bundle size, so
adding two new dependencies may seem problematic. That said, we don't currently
have a principled way of evaluating Lambda bundle sizes when we make choices in
this project, and compared to other dependencies of Apollo Server, these new
dependencies are not very large. For now, the improvement in maintainability and
flexibility seems worth the bundle size increase. If `apollo-server-lambda`
users want to help out with a new project of focusing on Lambda bundle size
optimization, we can work together to define benchmarks based on realistic
build/bundler conditions, and find other ways to reduce bundle size (eg, there
is a fair amount of low hanging fruit inside `apollo-reporting-protobuf`).

Fixes #5078. Fixes #4951 (because that API is just "Express").

docs/source/deployment/lambda.md

@@ -20,6 +20,7 @@ The following must be done before following this guide:
 
 ---
 
+FIXME see what needs to be improved
 ## Setting up your project
 
 Setting up a project to work with Lambda isn't that different from a typical NodeJS project.

package.json

@@ -89,6 +89,7 @@
     "@types/type-is": "1.6.3",
     "@types/uuid": "8.3.0",
     "@types/ws": "7.4.1",
+    "@vendia/serverless-express": "4.3.7",
     "apollo-link": "1.2.14",
     "apollo-link-http": "1.5.17",
     "apollo-link-persisted-queries": "0.2.2",

packages/apollo-server-core/src/ApolloServer.ts

@@ -305,8 +305,9 @@ export class ApolloServerBase {
     // server.start()` before calling it. So we kick off the start
     // asynchronously from the constructor, and failures are logged and cause
     // later requests to fail (in `ensureStarted`, called by
-    // `graphQLServerOptions`). There's no way to make "the whole server fail"
-    // separately from making individual requests fail, but that's not entirely
+    // `graphQLServerOptions` and sometimes earlier by serverless integrations
+    // where helpful). There's no way to make "the whole server fail" separately
+    // from making individual requests fail, but that's not entirely
     // unreasonable for a "serverless" model.
     if (this.serverlessFramework()) {
       this._start().catch((e) => this.logStartupError(e));
@@ -436,8 +437,10 @@ export class ApolloServerBase {
   // verify that) and so the only cases for non-serverless frameworks that this
   // should hit are 'started', 'stopping', and 'stopped'. For serverless
   // frameworks, this lets the server wait until fully started before serving
-  // operations.
-  private async ensureStarted(): Promise<SchemaDerivedData> {
+  // operations. While it will be called by `graphQLServerOptions`, serverless
+  // integrations may want to also call it earlier in a request if that is
+  // helpful.
+  protected async ensureStarted(): Promise<SchemaDerivedData> {
     while (true) {
       switch (this.state.phase) {
         case 'initialized with gateway':

packages/apollo-server-lambda/README.md

@@ -8,6 +8,8 @@ This is the AWS Lambda integration of GraphQL Server. Apollo Server is a communi
 npm install apollo-server-lambda graphql
 ```
 
+FIXME see what needs to be improved
+
 ## Deploying with AWS Serverless Application Model (SAM)
 
 To deploy the AWS Lambda function we must create a Cloudformation Template and a S3 bucket to store the artifact (zip of source code) and template. We will use the [AWS Command Line Interface](https://aws.amazon.com/cli/).

packages/apollo-server-lambda/package.json

@@ -26,11 +26,11 @@
     "node": ">=12.0"
   },
   "dependencies": {
-    "@apollographql/graphql-playground-html": "1.6.27",
+    "@vendia/serverless-express": "^4.3.7",
     "@types/aws-lambda": "^8.10.76",
     "apollo-server-core": "file:../apollo-server-core",
-    "apollo-server-env": "file:../apollo-server-env",
-    "apollo-server-types": "file:../apollo-server-types"
+    "apollo-server-express": "file:../apollo-server-express",
+    "express": "^4.17.1"
   },
   "devDependencies": {
     "apollo-server-integration-testsuite": "file:../apollo-server-integration-testsuite"