Experiment: Break up next deployment into two lambdas@edge, behind cloudfront

# Architecture


## Notes

Use the [`lambda-at-edge`](https://github.com/serverless-nextjs/serverless-next.js/tree/master/packages/libs/lambda-at-edge) library to break up next into two lambdas:

- `default-lambda` that contains all the pages
- `api-lambda` that contains just the api routes

Pre-rendered and other static assets are extracted from the `.next` build and are uploaded to S3.

Cloudfront cache behaviours are then configured to send the requests along to either these lambdas or to fetch static assets that were uploaded to S3 (no lambda hit necessary).

## Pros

- AWS deployment is nearly identical to local server (with the proviso that cloudfront forwards on expected cookies or other original request headers e.g. `referrer`)
- Fast to deploy
- Global deployment on lambda@edge that promises lowest latency to end users
- Cloudfront cache plays well with webpack "chunks" generated by next build

## Cons

- The deployment as configured in terraform is complex (900+ lines of terraform)
- Requires deeper knowledge of next internals (page routing, dynamic page routing, static generation, api routes, webpack chunks etc.). These details could easily change when upgrading next
- lambda@edge puts cloudwatch logs in the AZ closest to the user that made the request. So additional work might be needed to aggregate logs
- Cold starts seem very slow (5-10 seconds), but I've not looked into this much yet