-
Notifications
You must be signed in to change notification settings - Fork 151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Question] Splitting tf-next build
#245
Comments
The general vision for this project is always to make building and deployment as modular as possible. 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. Historically Next.js needed some extra treatment for making it work with serverless environments (required a custom Next.js config).
This means you could theoretically run 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). The general idea is to use the Cloud provider(s) in the module that have the best support for Next.js' features. |
Difficult to say, the idea of #89 is to reverse engineer Vercel's solution and bring it back to our fork. I can say that the reverse engineering part is already finished. |
CDK based deployment layer is now available in the main branch. Closing this for now. |
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 whattf-next build
current outputsNote: 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 whatnext 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?
The text was updated successfully, but these errors were encountered: