-
Notifications
You must be signed in to change notification settings - Fork 19
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
EOL announcement #97
Comments
Ahoj! Sad to here that, but the reasons make sence. We currently use your library to build Next.js projects but Open-Next looks promising and evene migration couldn't be so hard. It's unfortunate to hear about EOL, but the reasons make sense. Currently, we are using your library to build Next.js projects and deploy them to AWS with our custom Terraform configs. However, Open-Next looks promising, and I believe that migrating to it may not be too challenging. And thanks for you work on this library. |
To address complexity concern, I was able to create lambda-only implementation of NextJS deployment to AWS. See: https://github.com/sladg/lambda-server-adapter/blob/master/examples/Next.md. I will probably publish terraform module later on to deal with optional plugins such as Cloudfront, certificates, faster image optimiser, etc. |
After testing of open-next and SST I will be deprecating this package in foreseeable future in favour of SST and Open-Next.
Reasons are as following:
Currently only one concern in mind:
One future issue I came by with current package as well as open-next
node_modules
for Lambda's environment. Binary-specific dependencies get's bundled locally on host OS and might not be compatible with Lambda's runtime. This is industry-wide problem solvable by Docker and pipelines, however, not compatible with SST's dev experience.Cheers!
Jan
The text was updated successfully, but these errors were encountered: