Decouple lambda-at-edge deploy logic from nextjs-component

Currently, the Lambda@Edge deploy logic is actually coupled into nextjs-component.

As a first step to making this package more generic and extensible for supporting other serverless platforms (e.g Lambda, Cloudflare), all Lambda@Edge logic should live in the lambda-at-edge package. It would be a plugin and implement two features:

• Build (already done): builds artifacts for deploying to Lambda@Edge. Ex: default-handler, api-handler, assets (building of assets for S3 was recently decoupled from component to lambda-at-edge).
• Deploy: we need to move all deployment logic currently from nextjs-component into lambda-at-edge. Currently, it’s doing all the CloudFront, S3 and Lambda deployment work, but this should really live in lambda-at-edge. Of course, if there’s shared logic (e.g S3 upload logic may be same for Lambda vs. Lambda@Edge), then we’ll put those in the respective internal packages.

As part of this, we can define a standard interface that all plugins should implement.

Afterwards, nextjs-component itself will be very lightweight and simply call the plugin to use based on inputs (e.g lambda-at-edge for now, and others later).

I also suggest to rename lambda-at-edge to lambda-at-edge-plugin to be clearer later on.

[danielcondemarin]

If we go with CDK for Terraform, do we need to remain on Serverless in that case?

We could possibly remove the need for Serverless whilst still supporting serverless components via https://github.com/serverless-components/aws-cloudformation 🤩 Tempting.

[danielcondemarin]

Thanks for the thought out reply, overall sounds very sensible to me 🙂

For example, it doesn’t know to use AWS S3 for retrieving static pages. For that, it would just call a storage accessor interface (which can later be replaced e.g by Rollup.js by the actual implementation when bundling).

This would be quite nice 💯

The proposal to introduce a new platform sounds really good as well. Possibly an easy first candidate would be Lambda + API Gateway.

As an aside: since CDK is from AWS, it would be well-supported for AWS platforms, but maybe others may not be as well supported.

I used CDK as an example. I was trying to convey it would be nice if we supported other deployment / IaC frameworks such as CDK or Terraform.

However, if we use something like CDK, we could enforce all Deploy implementations use the CDK to make it more maintainable overall.

There is an interesting trade-off to consider here. Whilst it makes it easier for us to maintain, it means enforcing a particular way of deploying to users. For example, some people will use CDK, others Terraform etc. Ideally serverless-next.js would provide different entry points for each. That way it integrates nicely with existing tools folks already use for their IaC projects.

CDK for Terraform sounds quite interesting and potentially a really good fit for this project. 👍