Could you still support deploy nextjs 9 using lambda not lambda edge?

[lxgzmy]

for some technology constrains, we still want to use lambda to render the nextjs apps, but not lambda edge, but the plugin move complete to component way to deploy nextjs 9 and only apply to lambda edge, is there a way we can deploy the app like nextjs8 by using plugin and we can employ the frontend library nextjs 9?

[SarKurd]

Too bad serverless-nextjs-plugin is no longer maintained, components is too immature and not well maintained, Serverless team don't give enough support to it.

I'd stay with serverless-nextjs-plugin if it had support for Next9

I hope @danielcondemarin add support for Next9

[danielcondemarin]

Too bad serverless-nextjs-plugin is no longer maintained, components is too immature and not well maintained, Serverless team don't give enough support to it.

I'd stay with serverless-nextjs-plugin if it had support for Next9

I hope @danielcondemarin add support for Next9

I am considering adding support for AWS CDK as an alternative to folks that don't use the Serverless Framework or Components. However, I'd like to keep the architecture the same using Lambda@Edge etc. @lxgzmy Can you elaborate why you'd prefer not using Lambda@Edge?

[gbwashleybrown]

Too bad serverless-nextjs-plugin is no longer maintained, components is too immature and not well maintained, Serverless team don't give enough support to it. I'd stay with serverless-nextjs-plugin if it had support for Next9 I hope @danielcondemarin add support for Next9

I am considering adding support for AWS CDK as an alternative to folks that don't use the Serverless Framework or Components. However, I'd like to keep the architecture the same using Lambda@Edge etc. @lxgzmy Can you elaborate why you'd prefer not using Lambda@Edge?

@danielcondemarin One reason not to use Lambda@Edge is the lack of environment variables

[derekacosta]

Adding to that ^^^ not everyone need Lambda@Edge, or serverless components (while it helps with dev spinning stuff up quickly, also mean we have to change our architecture to accommodate for components). Additionally, domain support for domains not registered through route 53 is a pain as well though that is a serverless components issue.

[me4502]

I definitely agree that at least providing an alternative to Serverless Components (even if it sticks with Lambda@Edge, which is probably a good idea anyway), mainly due to the lack of maturity of Serverless Components at this stage.

For example, the lack of remote state storage makes it somewhat painful to setup in a CI/CD pipeline.

[alaingoga]

In our case we use different CDN so CloudFront is not an option right now. We need to deploy nextjs v9 as a regular lambda, not @edge

[crash7]

I'm using the next-aws-lambda in order to render next.js pages inside a normal lambda, since I don't either want to use Lambda@Edge (or serverless-components).

You will have to patch the event to adapt it to your lambda, but you can use the default-lambda-handler as a starting point.

Maybe a separate package/feature for an existing one that provides compatibility layers for @Edge events, APIGateway or ALB events may help covering different use cases?

[danielcondemarin]

Maybe a separate package/feature for an existing one that provides compatibility layers for @edge events, APIGateway or ALB events may help covering different use cases?

That was the idea behind creating a separate package for the API GW -> Lambda compat layer on the first place. I still need to do the same for CF Edge. Basically would be pulling next-aws-cloudfront out of the next-component package (PRs welcome for that 🙂). ALB -> Lambda is an interesting proposition I'd like to look into at some point.

[crash7]

Would be nice to be able to use the packages even if you are not using serverless-components, so the people like me that just need some pieces can benefit of the building blocks you create. Is this what you have in mind in the long-run? I eat AWS Lambda for breakfast 😎so I can help for sure.

[danielcondemarin]

Would be nice to be able to use the packages even if you are not using serverless-components, so the people like me that just need some pieces can benefit of the building blocks you create. Is this what you have in mind in the long-run? I eat AWS Lambda for breakfast 😎so I can help for sure.

I've now decoupled most of the responsibility to deploy to Lambda@Edge from the serverless component. There is now a separate package for creating the Lambda@Edge handlers plus a bunch of other things -> https://github.com/danielcondemarin/serverless-next.js/tree/master/packages/lambda-at-edge It's not complete but I plan to keep on adding to it.

[yamitzky]

+1, because Lambda@Edge has disadvantage:

• Creating new CloudFront environment takes too long. It is difficult to deploy a new environment per branch such as amplify console.
• It is hard to know when deploying to Edge was actually completed.

[emhagman]

Another reason not to use Lambda@Edge is that you cannot connect to things inside your VPC. @danielcondemarin Could you explain what needs to change for someone who might want to submit a PR? I would definitely take a weekend to do this if I had the basic blueprint for what you'd want.

If I understand correctly, we would need to use the API Gateway for normal lambdas so when you say Basically would be pulling next-aws-cloudfront out of the next-component package do you mean removing references to "lambda@edge" inside component.ts and making it generic to be used with either aws-cloudfront or aws-apigateway essentially?

[dphang]

Yes, Lambda makes sense as the next platform to support. @danielcondemarin and I had some brief chats about making this component. more platform-agnostic. Though I think we still need to genericize the code a little more to support any platform (not just Lambda or Lambda@Edge) in general as the core routing logic is tied to Lambda@Edge. We really should be doing this way to make this component the most maintainable, generic and flexible:

• Core routing, SSR, etc. logic specific to Next.js serverless mode that is platform-agnostic, i.e it only knows about Node.js (or even less) specific stuff, and doesn't know anything about AWS or other platforms.
• Plugin to build and produce build artifacts for a platform (e.g handlers, assets directories, etc.). We already have Rollup.js to bundle code which we can use. E.g for Lambda@Edge we can configure Rollup.js to create a bundle including core logic, Lambda@Edge compatibility layer (converts between Node.js req/res and CloudFront events, storage backend (S3) with the core logic to produce a compatible handler.
• Plugin to deploy the above artifacts to the specific platform. For example, the Lambda@Edge deployer knows to update CloudFront, upload to Lambda@Edge, upload to S3, etc.

Right now I am trying to decouple build & deploy steps (have a PR out to generate assets as part of build) which is kind of loosely-related work. Next I will try to separate out core serverless Next.js logic from Lambda@Edge handler itself, so we can have the core logic that any platform plugin can use to build its own handler. Then after we should be able to more easily build Lambda support.

@emhagman I think if you want to, you can help create the lambda plugin (or at least the build + deploy steps). Maybe create a new package @sls-next/lambda-plugin which will do build & deploy. Ex, you can assume the core logic will be extracted from Lambda@Edge package (I can help work on that as part of general work on this). I would think it would go something like this:

• Build part of the plugin will build Lambda artifacts: handler (probably one handler for pages, and one for API), assets to be uploaded to S3
  • Handler itself should be built using Rollup.js to bundle: core logic, Lambda-specific compatibility layer (e.g to convert between Node.js req/res and Lambda request/responses, Lambda storage backend (probably S3) all bundled into a handler + all SSR code needed.
  • Assets built that will be uploaded later to S3.
• Deploy part of the plugin will deploy to AWS
  • Upload Lambda package
  • Upload assets to S3
  • Setup API gateway
  • Setup domain, certificates, etc.

Though we did not finalize the interface for plugins, you can probably add some initial code to do build/deploy work and we can refactor it a bit once finalized.

If you want to help with Lambda support, you can probably ask @danielcondemarin for an invite to our channel to discuss more. We are re-thinking infrastructure management so maybe we can try to deploy Lambda using CDK for Terraform (depends on finalization)

[gerbyzation]

A little time has passed so curious how this has evolved? Any help needed? We're running into the problem as well that we can't connect to our VPC and access internal services.

[sladg]

Hey! Looking into it as well. Main issue with Lambda@Edge being LOOONG deployment times and lack of environment variables.

Any updates or plans?

PS. I don't mind support for later versions of Next only.