search

serverless-nextjs / serverless-next.js

⚡ Deploy your Next.js apps on AWS Lambda@Edge via Serverless Components
MIT License
4.47k stars 457 forks source link

Support for Serverless Components GA? #380

Open rrooding opened 4 years ago

rrooding commented 4 years ago

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

danielcondemarin commented 4 years ago

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

hnprashanth commented 4 years ago

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

thiagozf commented 4 years ago

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 commented 4 years ago

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

danielcondemarin commented 4 years ago

@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 commented 4 years ago

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

rrooding commented 4 years ago

Any update on this?

dphang commented 4 years ago

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.

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 commented 4 years ago

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.

chasejfen commented 3 years ago

Is there any update on this? Willing to help if needed.

I think having this in registry, and Serverless dashboard would be very helpful.

mnapoli commented 2 years ago

@dphang hi, Serverless Framework maintainer here. I know it's been an old issue, but I'd love to chat with you. We can maybe help on #2320 to see if there are better solutions for the long term, and I would also love to show you a few ideas we have on our roadmap and see if they could be useful here.

Here's my email: matthieu.napoli at serverless dot com, or you can also find me on the serverless Slack: serverless.com/slack

marcoschicote commented 2 years ago

@dphang hi, Serverless Framework maintainer here. I know it's been an old issue, but I'd love to chat with you. We can maybe help on #2320 to see if there are better solutions for the long term, and I would also love to show you a few ideas we have on our roadmap and see if they could be useful here.

Here's my email: matthieu.napoli at serverless dot com, or you can also find me on the serverless Slack: serverless.com/slack

is this collaboration happening? I would like to see it move forward and how some of the bugs in this project get solved.

mnapoli commented 2 years ago

I haven't gotten news from maintainers yet. Here's a quick overview of what we're exploring:

It looks like this could be a great match here, as the current implementation is built on Components v1 (beta), but its limitations are pushing you into other solutions like CDK.

dphang commented 2 years ago

I haven't gotten news from maintainers yet. Here's a quick overview of what we're exploring:

  • can we provide a "component" approach like Serverless Components v1 beta (completely open source, no SaaS account required, deploys locally on everyone's machine, etc.), which is the engine used here, that could integrate directly with Serverless Framework
  • can we integrate with AWS CDK
  • etc.

It looks like this could be a great match here, as the current implementation is built on Components v1 (beta), but its limitations are pushing you into other solutions like CDK.

Thanks for reaching out! Sorry I had missed this earlier as I’ve been busier this year and I’m the only maintainer and it’s been a handful just maintaining both the build, deployment and next.js routing logic. I’ll reach out to you in the coming week to discuss more.

yes, it’ll definitely be ideal if we can maintain the current flow where things are built, packaged and deployed locally. One pain point right now is maintaining custom deployment logic eg for static infrastructure like api gateway, lambda, s3, cloudfront etc which would be easier with things like CDK. I remember the previous maintainer had explored v2 before briefly but seemed like it was not feasible / a big lift to do so. I’d definitely like to make a variety of deployment options available (Serverless framework, CDK, CDK for Terraform, Serverless stack etc) but try to make the deploy logic here simpler (deferring to CDK, Serverless for the heavy lifting, etc) so we can focus on core Next.js routing logic / compatibility layer logic between AWS Lambda / Lambda