Architecture

image

Notes

Use the 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