Serverless-next.js: Support for Serverless Components GA?

[rrooding]

Are there any plans on supporting the new way of working of Serverless Components?

[danielcondemarin]

Yep I’m already working on it. Expect an RFC soon 👍🏻

[hnprashanth]

Looking forward to this! I really really really need this!

[thiagozf]

I would love to help with this request. I've migrated some building blocks like aws-cloudfront and aws-s3 to the new version and patched aws-lambda to output the function version. Probably submitting a PR to Serverless after writing some tests. If there is anything I could do to get this out, hit me up.

[rrooding]

If I can also help speed along things, let me know!

[danielcondemarin]

@rrooding @thiagozf Thanks for offering to help 🙏
There are a couple of issues I'd like to have fixed for serverless-components v2 release. More specifically https://github.com/danielcondemarin/serverless-next.js/issues/397 and https://github.com/danielcondemarin/serverless-next.js/issues/378.
There may be other things to do, I'll update on this thread 👍

[ivoreis]

Hi @danielcondemarin, are any other issues blocking this that need help?

[rrooding]

Any update on this?

[dphang]

I think @danielcondemarin and I are now weighing the pros/cons between continuing on Serverless Components GA vs. using something like CDK for Terraform (we are currently looking at prototyping the latter).

The reason for the latter is so there's better support for infrastructure state management (it seems Serverless may, in the future, be strongly tied to having a Serverless account / Serverless state management, whereas with the latter, you can use it without having a Terraform account and store state on: S3, GCP, etc. or also Terraform.) + more configurability (using TypeScript to define and also programmatically update infrastructure) and generally Terraform has a vaster and more updated ecosystem for infrastructure providers. We are also not really using many pieces of Serverless itself except for the deploy/remove command and some subcomponents (e.g S3). For example, we've had to import aws-cloudfront and domain component and make custom updates to it since the ones from Serverless weren't well maintained; but we'd like to not have to be managing this.

We will probably create a new issue to detail this plan. I expect probably it can be in v2 of this component. No specific timeline from me yet, but I'd love to work on this and see if something can be out by early Q1 2021.

• Genericizing component to support more providers (e.g creating lambda-at-edge-plugin, lambda-plugin) instead of having all logic right now coupled with Lambda@Edge.
• First-class support for infrastructure state management via CDK for Terraform or other proper IaC

These two do go hand-in-hand. I am working on (1) to separate the deployment logic from nextjs-component into lambda-at-edge package. And afterwards will be separating core routing logic outside of Lambda@Edge package. Then, we can look into how we can deploy using another IaC like CDK for Terraform instead of the existing deploy code (which mostly runs custom logic to call the AWS SDK anyway).

[dphang]

RE: above, to clarify, I think actually the idea is not to forgo Serverless Components GA, I think we can and should still support it for its conveniences (e.g monitoring, logging, dashboards in the future), but also introduce good ways of managing IaC. I think both can co-exist but essentially, we want to make this component more platform-agnostic and supporting different ways of deploying, i.e not tied to Serverless, if you wish. I think we should still have support for Serverless Components GA, but it would require careful thought and architecting to ensure we aren't too tightly coupled with Serverless Components - which it is currently.