[Question] Splitting `tf-next build`

[jd-carroll]

First off, thank you for pulling this together! This tool is exactly the type of resource I was looking for and saved me hours/days of time. However... I do not use Terraform. And I generally feel that there is too much happening in the tf-next build command.

Why would it not make sense to support a pattern that looks something like:

• $ next build
• $ tf-next build-manifest // defines all of the static/dynamic routes and assets
• $ tf-next package // creates the zip artifacts for lambda functions
• $ tf-next bundle-tf -- or -- $ tf-next bundle-cdk ... // outputs what tf-next build current outputs
  Note: part of this will be me figuring out how to help contribute any changes

The basic idea being, let Next be responsible for building the initial assets. Even if this requires custom config in the next.config.js file (this is exactly what next build is best at). Then assemble all of the artifacts from that build into a single manifest which describes all of the possible routes. The last two steps could either be separate or combined but they would be responsible for creating something deployable to the cloud.

The code which creates that deployment could have adaptors for different clouds (e.g. AWS vs Azure) and separate adaptors for separate infra packages (e.g. Terraform vs CDK).

Thoguhts?

[ofhouse]

The general vision for this project is always to make building and deployment as modular as possible.
Therefore we have this split between the CLI (which is responsible for creating the build) and the Terraform part (which is responsible for deploying the whole thing to AWS).

Splitting the build part of the CLI in more granular steps (manifest, package) is tricky since both steps are tied together (We copied this part directly from Vercel) in many ways.
The functions, assets and routes are building an atomic deployment at Vercel and so do they here.

Historically Next.js needed some extra treatment for making it work with serverless environments (required a custom Next.js config).
In Next.js 11.0.8 they changed this, so that the way to build is basically:

1. Run next build: Created build output in .next/ (assets + manifest files)
2. Serverless build: Takes the manifest files and assets from .next/ and generates routes + Lambdas from it
3. Deploy it to AWS

This means you could theoretically run next build and tf-next build in two separate steps in the future, work for it is done here: #89

---

With the multiple deployments feature in mind this is how the architecture of this project will look in the future:

The idea is to decouple the deployment process for resources that are always available (e.g. CloudFront, S3, SQS, etc.) and resources that are created / upgraded for each deployment (e.g. Lambdas).
tf-next deploy and the dynamic deployment layer then communicate over some REST-API which would also open it to more providers (like Azure).

The general idea is to use the Cloud provider(s) in the module that have the best support for Next.js' features.
For Next.js 11 this was AWS. With the introduction of Edge functions in Next.js 12, this has now changed so that a combination of AWS + Cloudflare would be the best option for now.

[jd-carroll]

@ofhouse Thanks for the information it sounds like our general thought processes are aligned. Are you looking for any input / assistance in #89? Happy to help in some way, but also understand the complexity (IMO) of the build and deployment process.

[ofhouse]

Difficult to say, the idea of #89 is to reverse engineer Vercel's solution and bring it back to our fork.
The builder they use nowadays is simply an advanced version of what we use currently.

I can say that the reverse engineering part is already finished.
What's currently blocking me, is the licensing part. Since their builder is not publicly available we have to develop our own solution and cannot simply copy & paste it.

[ofhouse]

CDK based deployment layer is now available in the main branch. Closing this for now.