Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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`). Fix inconsistency in the content-type returned from health checks (the old Lambda used `application/json` instead of `application/health+json` like most other integrations). This new version passes all of the existing integration tests (plus the `testApolloServer` suite from `apollo-server-integration-testsuite/src/ApolloServer.ts` which wasn't being run previously!) essentially out of the box. (I fleshed out the "mock server" implementation which converts from Node http requests to Lambda events a bit more, and changed, but no "core" code or test changes were needed other than fixing the health check `content-type`.) Fixes #5078. Fixes #4951 (because that API is just "Express").
- Loading branch information