jetbridge / cdk-nextjs

Deploy a NextJS application using AWS CDK
https://constructs.dev/packages/cdk-nextjs-standalone
Apache License 2.0
276 stars 46 forks source link

Default AssetDeployment Slow #117

Closed bestickley closed 1 year ago

bestickley commented 1 year ago

The default NextJsAssetsDeployment uses 128MB of memory. That results in (in my experience) a 46 sec. upload for a 3MB site. Could we increase the default memory to maybe 1024MB to speed it up? I'd think that's a good default. I'd be ok with higher.

Also, after doing a little research, it looks like first the BucketDeployment construct is used to download the s3 files from the CDK assets bucket and then upload them into the Nextjs static site bucket. Then NextjsS3EnvRewriter downloads the files from the static site bucket (again), replaces environment variables, and then re-uploads to static site bucket. Is that correct?

What if instead there was 1 custom resource that downloaded files from CDK assets bucket, replaced environment variables, and then uploaded to static site bucket? I could take a shot at this in the next couple weeks. I would utilize this.

revmischa commented 1 year ago

I believe the BucketDeployment uploads the files from your local machine to S3 into the static site bucket. We only upload them once. We don't know the CF token resolved values when we upload the files which is why we have to run the rewriter after most of the deployment has finished. If you have another idea to work around it, would be curious to hear it.

I think SST's NextjsSite used to do this but it might not do it anymore. We should ask in the discord how they accomplished that.

revmischa commented 1 year ago

But sure by all means increase the memory, no downside there

revmischa commented 1 year ago

Ok I think NextjsSite does it with this script https://github.com/serverless-stack/sst/blob/master/packages/sst/src/constructs/SsrSite.ts#L729

bestickley commented 1 year ago

I will also make sure we're following open-next's recommendation for object meta-data headers: Hashed: public,max-age=31536000,immutable Unhashed: public,max-age=0,s-maxage=31536000,must-revalidate

Additionally, I'll ensure we're running open-next only when assets should be built, not on every synth which it does now. I'll use this for reference.

With this method, we should be able to remove SSM Params so we're using less resources. We'll pass the unresolved values as Properties to the custom resource. When the Lambda function code runs, it will have resolved values.