Documenting the internals/how this works (for Pulumi implementation)

[vha14]

This repo is really fantastic - thank you @ofhouse for your work!

I'm trying to understand the "small" picture - how things work under the hood - with the goal of implementing a version of this in Pulumi. This has been rather challenging due to my lack of familiarity with the Vercel stack and how it's used in this library. Vercel/Next.js documentations don't cover the internals well either - they are meant to be consumed by the users, not (new) developers. It would help me tremendously if there's some description of how this library works by integrating with the Vercel tools. Thanks!

[ofhouse]

Hi, thanks for your kind words, appreciate it 👍

I do not have that much time to explain it in detail now, but I published some insights in this article: Why we self-host our serverless Next.js site on AWS with Terraform.

[vha14]

The blog post you shared is really fantastic - thanks again @ofhouse !!

In other conversations I gathered that Vercel now moved their build pipeline to closed source (I understand given their venture-funded commitments.). In response, both you and blitz.js have forked the current pipeline.

Do you anticipate big challenges in maintaining these forks while aiming for feature parity with Vercel?

[ofhouse]

Hard to say, my prediction is that it will become a little easier to maintain Next.js on AWS Lambda since Vercel decided to drop the build target completely.
That means a custom server and a serverless environment on Vercel both using the same build output (.next/server) from now on (#86).
However a preparation step is still needed to make it runnable on AWS Lambda.

In other conversations I gathered that Vercel now moved their build pipeline to closed source (I understand given their venture-funded commitments.). In response, both you and blitz.js have forked the current pipeline.

Some correction here, Blitz.js has forked the Next.js project (blitz-js/blitz#1990) itself, not the pipeline.
We forked the pipeline (#36) that Vercel was / is using to customize the build output from .next/server to make it runnable inside AWS Lambda.

In general I think the task of keeping feature parity with Vercel will become more difficult since Vercel can always introduce changes to Next.js codebase that break something of our build pipeline (For example: milliHQ/terraform-aws-next-js-image-optimization#19).
This is the downside of the concept. Vercel publishes much of their software as open source, but the development and roadmap stays mostly private.
On the other side they always have to release new features that are exclusive to Vercel to stay relevant, since Netlify also works on a serverless implementation and AWS Amplify also works on serverless support for Next.js behind the scenes.

Vercel also has the advantage that they have full control over the CDN / Router, since they are operating their own network (think they were using CloudFlare before for this task), while we are currently bound to CloudFront. It can handle most of it with the help Lambda@Edge too but is lacking a lot of features compared to their CDN, since AWS has only recently begun to dedicate more resources to CloudFront development.

What makes it so difficult is that Vercel cannot support this kind of projects because they would kill their own business model if they would do this. Competition in this field is currently really hard and everyone could recently see that AWS is eating up a lot of space in the SAAS economy (MongoDB, elasticsearch).
Currently they give Serverless Framework a hard time with Amplify & CDK and I guess they will not stop there.

[vha14]

This is very helpful, thanks for taking the time to explain.

[tlinhart]

@vha14 I'm also interested in getting this to work with Pulumi as that's what we are using for the rest of infrastructure. Have you been successful with that?

[vha14]

Not yet. It's more complicated than I initially thought. I have near zero experience with both tf and vercel's internals, which adds to the challenge. Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Tomáš Linhart ***@***.***> Sent: Saturday, April 17, 2021 9:26:49 AM To: dealmore/terraform-aws-next-js ***@***.***> Cc: Vu Ha ***@***.***>; Mention ***@***.***> Subject: Re: [dealmore/terraform-aws-next-js] Documenting the internals/how this works (for Pulumi implementation) (#72) @vha14<https://github.com/vha14> I'm also interested in getting this to work with Pulumi as that's what we are using for the rest of infrastructure. Have you been successful with that? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#72 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAEBOBJHT5MLH75YAHOI5Y3TJGZETANCNFSM4YZ64UZQ>.

[ofhouse]

I'm going to close this issue because it has been inactive for 30 days ⏳. This helps to find and focus on the active issues.