Node v18 Released
chenrui333 opened this issue · 104 comments
Even though we are still waiting for node v16 base image, this is the issue tracker for node v18 base image
https://nodejs.org/en/blog/announcements/v18-release-announce/
I’ve been waiting for someone to do this 🤣 thanks
Maybe that way, the Node v18 will be done before past one year.
Best thing you could do to enjoy Node v18 like-features is move to Netlify. They released Edge functions with Deno deploy: https://www.netlify.com/blog/announcing-serverless-compute-with-edge-functions
Do tell Vercel, they may reconsider using AWS lambda images :)
I honestly don't mind receiving flood of email notifications, since we really need to get more ppl to pressure AWS to stay on top of this NodeJS runtime update game.
Maybe that way, the Node v18 will be done before past one year.
Honestly, having a 6 month bake (releasing the april LTS release in around October for lambda) would be a good compromise. gives enough time for tests and means we're only "one version behind"
Honestly, having a 6 month bake (releasing the april LTS release in around October for lambda) would be a good compromise. gives enough time for tests and means we're only "one version behind"
Isn't that what the 6 months between v18 release on 2022-04-19 and v18 becoming LTS on 2022-10-25 is for?
Amazon can start making v18 images available now if they want to have 6 months of testing before offering v18 as LTS.
Honestly, having a 6 month bake (releasing the april LTS release in around October for lambda) would be a good compromise. gives enough time for tests and means we're only "one version behind"
Isn't that what the 6 months between v18 release on 2022-04-19 and v18 becoming LTS on 2022-10-25 is for?
Amazon can start making v18 images available now if they want to have 6 months of testing before offering v18 as LTS.
Yes, that's exactly my point - AWS just also use that same bake time to prepare, then launch the node version as soon as it becomes active LTS
Should be noted as well, that they will be transitioning to Javascript SDK V3 as well for the default SDK.
Like many others I agree with the sentiments, AWS needs to get better on this.
I suggest everyone bug their account managers, technical account managers and log support tickets if you haven’t already.
I went back and dug out the release history of lambda back to node 8. It is not a pretty sight.
The current delay is second only to the delay with the node 10 release, that took until May 13. After Node 10 things got better - Node 12 dropped very promptly, 14 it started to drift back out and with 16 we’re back to at least May.
Interesting to note the other two major cloud providers, ie Google and Azure, did manage to get 16 out in a timely manner.
Node 16:
Node LTS: 2021-10-26
AWS Lambda Release: ???
Google Cloud Functions release: 2021-11-17
Azure Functions release: 2021-11-22
Node 14:
Node LTS: 2020-10-20
AWS Lambda Release: 2021-02-03
Node 12:
Node LTS: 2019-10-22
AWS Lambda Release: 2019-11-18
Node 10:
Node LTS: 2018-10-30
AWS Lambda Release: 2019-05-13
Node 8:
Node LTS: 2017-10-31
AWS Lambda Release: 2018-04-02
@adcreare I mean, it's not like Amazon is a multi-billion dollar company.... oh wait
Thanks all for the keen interest in seeing Node releases land promptly in Lambda.
Regarding Node releases in general, we're tracking the Active LTS release dates in October, not the 'Current' release dates in April. This is because, as stated at https://nodejs.org/en/about/releases/, "Production applications should only use Active LTS or Maintenance LTS releases".
As @adcreare pointed out above, there have been delays between Active LTS and our corresponding GA releases, not least for Node 16 (see #14 for latest status). While I can't give an ETA for Node 18 yet, we do hear your feedback and this is something we're actively working to improve.
@jtuliani Well you could add it as beta status or something, actually node 12 is also not usable in production because it's not supported anymore, but you still have this runtime supported. I think it's nothing bad about thinking of new releases in advance. "Current" version is stable enough for some simple applications. It's a good idea to release it right when it hits lts status.
Having this runtime for lambda doesn't equal using it in production. We might use it in testing instances.
Regarding Node releases in general, we're tracking the Active LTS release dates in October, not the 'Current' release dates in April. This is because, as stated at https://nodejs.org/en/about/releases/, "Production applications should only use Active LTS or Maintenance LTS releases".
Then why is your node 16 image that is just released based on node 16.4, which by your version definition, should not be used in production, because it was released multiple months before the first 16.x LTS version!!!
@jtuliani Well you could add it as beta status or something
This is "close" to what I'd like. i'm thinking more like nodejs18.x-experimental that can only to assigned through the API/CLI and not through the console (currently how 16 is working now). Where, if they are are worried about support, have a flag that needs to be sent via API, "agree_experimental": true when sending a runtime of "*-experimental", where the usage agreement is "use at your own risk".... then when GA is ready or close, they make a nodejs18.x
This would allow us to deploy an experimental version and allow us to fix bugs ahead of the GA releases.
If someone wants to use this for production purposes, that's their issue then as they agreed to the terms.
-experimental feels problematic in that at some point when the runtime goes GA, AWS need to modify a whole bunch of lambda configs to remove the suffix. Published version configurations would then be modified, which should never happen.
That said, agree_experimental: true is a reasonable thing for non-GA runtimes since that would be required for the API to not fail the call, but would leave things in the correct state at GA - the agreement doesn't need to be stored, its implied by the fact that the API accepted the request.
There shouldn't be a need to remove any configs, however it would be more aggressive on the removal of the runtimes. I would just say, create a new GA runtime without the suffix, and either remove the *-experimental runtime immediately or after a month. They already have policy and protocols for deprecation. The only other thing is, I'd probably disallow the runtime's for @edge.
The nice thing about it is. Once a GA is announced then they deprecate and immediately release the "next" LTS version. So, if they have node18.x-experimental... after the GA, they release node18.x runtime, where both runtimes exist, then they release node20.x-experimental and remove node18.x-experimental. Experimentals are just treated as another runtime.
how do customers deal with the fact that they have an -experimental runtime in a published function, but that runtime has been removed?
its easy to say "make the customer do it" but its an impractical answer that leads to unhappy customers. it would be better to use a fixed name that wont change at GA, but force customers to accept its experimental nature pre GA
To some degree i can see your point that they already have a process for deprecating runtimes, but in this instance it would seem more appropriate to not deprecate, but instead automatically onboard in to the non-experimental version at GA since pre GA the runtime may introduce breaking changes but if you're using the runtime pre GA, you presumably want to keep using it post GA.
This would also address @GrahamCampbell's comment on node 16.4 being available pre LTS. This should have required the experimental: true flag to deploy, but would have naturally transitioned at GA without any actions on the part of the customer
but would have naturally transitioned at GA without any actions on the part of the customer
However that's not true, because many major bugs and security issues (such as CVE-2021-22930 and CVE-2021-22931) were fixed since the 16.4 release. 16.4.x is not suitable for production use IMO.
@GrahamCampbell Please can you clarify how you checked the Node 16 version and which region you used? When I tried a simple function to console.log(process.version); just now in eu-west-1, I see the Node version reported as v16.14.0. Thanks!
@barneyparker The same way they handle deprecated versions of runtimes now. https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html#runtime-support-policy
According to documentation
Phase 1 - Lambda no longer applies security patches or other updates to the runtime. You can no longer create functions that use the runtime, but you can continue to update existing functions.
Phase 2 - you can no longer create or update functions that use the runtime.
Lambda does not block invocations of functions that use deprecated runtime versions. Function invocations continue indefinitely after the runtime version reaches end of support.
So I would expect, as a completely separate runtime, it would follow these steps but at a "faster" pace, and there would only be one "experimental" per GA release
Edit the main problem is that the experimental runtime may have a "bug" thats not present in the GA version.
Thanks all for the thoughts on 'preview' runtimes--please keep the ideas flowing. This is also something we're considering (no concrete plans yet). As well as the details of how preview runtimes would work, we're also keen to understand the 'why'...what would you all see as the main benefit(s)? Would you be willing to try runtimes during the preview phase and share feedback?
@jtuliani The Main reason is for developers to deploy a "test" version of their application. This would allow us to iron out any issues with a new version before (90-99%) a GA is deployed. As it is now, when a GA is released, it can be up to a month sometimes for testing and QA teams to work with before we can utilize this in a production environment. Then all that is left is any issues between a "preview" version and the GA runtimes, which should be low.
As the core maintainer of Middy, being able to know what will be included in the runtime when it hits GA will allow myself and other OSS projects to better server the AWS Lambda community. Currently, we need to be over conservative or reactionary with major releases which I feel isn't serving the community as well as it could be. Also, having more lead time mean better planning and less rushing to test and publish a new version once GA is released. Frameworks need to be updated and released before, as @dl748 mentioned, other downstream projects/developers can use them.
I like this idea of having the LTS runtime released via to the API/SDK with a simple changelog in GitHub to know if there are any other changes besides the runtime itself. Then having a switch to GA it once the version transitions to LTS, enabling the console and updating the public docs. I don't think the runtime needs a -experimental suffix, just remove the API flag when no longer needed.
Having access to the latest runtime sooner has additional advantages:
- faster, which lowers costs and can be a competitive edge
- fewer polyfills needed (ie fetch, web stream, etc)
- removal of experimental flags (ie json import)
- simpler and safer build process, js may no longer need to be transpiled
Happy to discuss feedback on preview nodejs runtimes and feature requests I've been collecting over the years. The Middy team is already building a relationship with the AWS Lambda Powertools Typescript team to see how we can better work together to serve the community, would love to do the same with the Lambda nodejs runtime team if there is interest.
@jtuliani Could there maybe be a way to differentiate pre-released runtimes from released ones? Something like the CAPABILITY flags you have to include in some CloudFormation calls to confirm that you know you're doing what you think you're doing? For example, if I tried to execute CreateFunction with a runtime of nodejs18.x but without some kind of IncludePrereleaseRuntimes parameter, I'd get an InvalidParameterValueException (or something). Including that flag lets me select unsupported runtimes, with the full knowledge that what I'm doing isn't (yet) supported. I think it'd provide a good balance of trusting developers/users with the flexibility to do what they want while still making sure you're not fielding support requests for things in pre-release state.
That said, I understand that changing the public API is way harder than some of the other solutions presented. One way around that might be to change the actual name of the runtime to, say, nodejs18.x-pre until it's supported. Anything that makes selecting it a deliberate act that forces acknowledgment of its prerelease status.
I like the idea of implementing Node 18 current and LTS with the same runtime name of nodejs18.x. I see a chance this might make it easier for adjacent software projects to keep their runtime support up to date and implement support by the time Node 18 LTS is released.
For example: Frameworks like Serverless Framework, plugins (like serverless-esbuild) or IDE extensions like Serverless IDE. All of them have/had to add support for the latest runtime and all of them have been blocked/waiting until May 9 to get started, making an already late runtime release take even longer because of the time required for dependencies to follow suit.
If AWS released nodejs18.x before Node 18 LTS, all of those projects could start working on support for it months earlier. And as mentioned before, we all could run and test Node 18 current much earlier to iron out issues. So by the time LTS hits, we could have a much more mature state of support throughout the ecosystem.
FYI As AWS is painfully slow at releasing new versions of node images we build our own lambda layers. We've been running our services on the latest node using layers for number of years now. At the moment we are not even able to do that as Node 18 requires glibc >= 2.28 currently unsupported by Amazon Linux (AL1 and AL2). What I think it means - is that we will not have Node 18 on AWS Lambda until it's operating on Amazon Linux 2022 (also see: https://repost.aws/questions/QUrXOioL46RcCnFGyELJWKLw/glibc-2-27-on-amazon-linux-2).
NodeJS just moved up the EoL for v16 to 2023-09-11! The race is now on for all vendors to release v18 ASAP to ensure customers have sufficient time to upgrade. Hopefully this will force a new release schedule.
I totally agree with @willfarrell that this is becoming much more of a priority right now. Hopefully AWS can prioritise this work
FYI we figured out how to build a custom node 18.X layer on Amazon Linux 2 with the help of AWS support (requires patching node binary with different glibc): https://gist.github.com/pbadenski/2011f2763ca572c2475a37433cb59549
NodeJS just moved up the EoL for v16 to 2023-09-11! The race is now on for all vendors to release v18 ASAP to ensure customers have sufficient time to upgrade. Hopefully this will force a new release schedule.
Probably a good time to migrate from the AWS Linux 2 base image to the AWS Linux 2022 base image too
@pbadenski how are you finding cold starts when using the node18 layer?
I'd be interested to use it, as long as response times didn't suffer
Analysis of 5 days of data shows cold start durations: [min: 1000 ms, avg: 1500 ms, max: 3500 ms]. These can be quite significant, however - we're not that sensitive to cold starts and only 0.5% (1 in 200) of our requests are cold starts.
Hope this helps.
P. S. Thank you for your question - cold starts never been an issue for us, so I've never checked it. I've learnt something! :)
Analysis of 5 days of data shows cold start durations: [min: 1000 ms, avg: 1500 ms, max: 3500 ms]. These can be quite significant, however - we're not that sensitive to cold starts and only 0.5% (1 in 200) of our requests are cold starts.
Hope this helps.
P. S. Thank you for your question - cold starts never been an issue for us, so I've never checked it. I've learnt something! :)
Could you tell me how to best gather metrics on cold (and hot) start times?
PS thank you for checking, very helpful
Analysis of 5 days of data shows cold start durations: [min: 1000 ms, avg: 1500 ms, max: 3500 ms]. These can be quite significant, however - we're not that sensitive to cold starts and only 0.5% (1 in 200) of our requests are cold starts.
Hope this helps.
P. S. Thank you for your question - cold starts never been an issue for us, so I've never checked it. I've learnt something! :)
What is your memory configuration for these metrics?
@jtuliani following up from #14 (comment)
Will you also be updating aws/aws-lambda-nodejs-runtime-interface-client#44 (comment) ? I open-sourced prebuilt packages for amazonlinux:2022, but I need parity between your default aws-lambda-ric and the docker aws-lambda-ric, especially for ESM support.
@fromtheexchange That's a great question regarding the alignment of RICs. This is something we currently plan to address in Node 18.
In addition, the official amazon/aws-lambda-nodejs image on https://hub.docker.com/r/amazon/aws-lambda-nodejs needs to be updated to include the linux/arm64 architecture.
Finally, it may be worth looking into the base image migration to amazonlinux:2022 from amazonlinux:2
Thank you for improving NodeJS support in AWS Lambda 🚀
@fromtheexchange Thank you for the suggestions. We are aware of the AL2 -> AL2022 transition and are working on plans for how to roll this out in Lambda, although at this stage we're not in a position to give a schedule. It's a little complicated because the minimum Linux kernel version is different between AL2 and AL2022.
A general question about AWS Node.js support: What does it mean for AWS to support a Node release AFTER the EOL of that release?
Using Node 16 as an example:
From AWS Lambda adds Node.js 16 -
Node.js 16 is the latest long-term support (LTS) release of Node.js and will be supported for security and bug fixes until April 2024.
Given that Node 16 reaches EOL in September, 2023, how is AWS planning to make security and bug fixes after that date?
@joebowbeer
It seems that AWS just hasn't made any announcements regarding the shortened support period for Node.js.
AWS announcement is May 12, 2022. (see What's New Feed (with filtered about Lambda))
Node.js Announcement is June 8, 2022 (https://nodejs.org/ru/blog/announcements/nodejs16-eol/)
AWS Lambda runtime deprecation policy shows that it can be called after EOL, but I assume it will just be left unpatched.
In general, the schedule for Lambda runtime deprecations tracks the language version they support (there have been exceptions e.g. Python 2.7). Customers should not plan on Lambda runtime support extending beyond the LTS period of the corresponding language version. This applies to the shortened EOL for Node 16.
We recognize that the shortened LTS period for Node 16 will increase demand for early support for Node 18, and are factoring this in to our Node 18 planning.
Is there a status update on when this will be ready or in preview? The next version on Middy, v4, with support for NodeJS 18, AWS SDK v3, and many more requested features is nearly ready in anticipation of an earlier release.
Work on Node 18 support for AWS Lambda is in progress. There are various dependencies which mean we're not able to share an ETA at this time.
Node v19 released. https://nodejs.org/en/blog/release/v19.0.0/
That means v18 is feature stable, right?
Node v19 released. https://nodejs.org/en/blog/release/v19.0.0/
That means v18 is feature stable, right?
The Active LTS is starting 2022-10-25. After this date, it will be feature stable.
In the language of the Node.js team: "New features, bug fixes, and updates that have been audited by the LTS team and have been determined to be appropriate and stable for the release line."
Nodejs v18 is LTS since yesterday, so yep!
Node v19 released. https://nodejs.org/en/blog/release/v19.0.0/
That means v18 is feature stable, right?
Oh wow, seems like AWS is rolling out Node.js 18 for AWS Lambda.
@jtuliani Could you please clarify?
Well spotted, that was quick :)
Yes, we have shipped a Node 18 base container image, which you can use to create and deploy Node 18 functions if using container images as your function deployment format. The remainder of our Node 18 support (managed runtime, SDK, SAM CLI, CDK, AWS CLI, docs etc) will take a few more weeks, and we will make the formal announcement when all those are in place.
Note that the Node 18 image includes the AWS SDKv3 (replacing v2 in Node 16). If you're giving it a try, please bear this in mind.
Well spotted, that was quick :)
Yes, we have shipped a Node 18 base container image, which you can use to create and deploy Node 18 functions if using container images as your function deployment format. The remainder of our Node 18 support (managed runtime, SDK, SAM CLI, CDK, AWS CLI, docs etc) will take a few more weeks, and we will make the formal announcement when all those are in place.
Note that the Node 18 image includes the AWS SDKv3 (replacing v2 in Node 16). If you're giving it a try, please bear this in mind.
Sorry, does this mean Cloudformation can use Node 18 now?
@paul-uz Node.js 18 is currently available only for AWS Lambda functions that use custom container images (Docker). That’s the only aspect where we should expect to see CloudFormation changes.
… (the rest) will take a few more weeks
@paul-uz Node.js 18 is currently available only for AWS Lambda functions that use custom container images (Docker).
… (the rest) will take a few more weeks
Ah lovely thank you. I wasn't sure where Cloudformation came into it you see. Thanks for clarifying.
what linux kernel version is this using?
the same as the node 16 ones i presume. the one al2 uses.
The kernel is not part of the runtime. All Lambda runtimes inherit their kernel from the MicroVM in which they run (see diagram on page 11 of https://docs.aws.amazon.com/pdfs/whitepapers/latest/security-overview-aws-lambda/security-overview-aws-lambda.pdf). Currently, this is kernel v4.14.
Release 1.65.0 of AWS SAM CLI comes with support for Node.js 18.x.
2.51.0 AWS CDK comes with Node.js 18 runtime support as well 🎉 . Keen to see when it's going to be available on codebuild as well.
For CodeBuild see aws/aws-codebuild-docker-images#580
I've build a cdk example that uses the node 18 runtime.
https://github.com/RaphaelManke/cdk-lambda-node-18
Please let us know when to expect:
- Node.js 18 for Lambda@Edge
https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html?icmpid=docs_lambda_rss
Looks like it's hit lambda proper.
Node 18 support in Lambda has shipped!
https://aws.amazon.com/about-aws/whats-new/2022/11/aws-lambda-support-node-js-18/
https://aws.amazon.com/blogs/compute/node-js-18-x-runtime-now-available-in-aws-lambda/
Thank you all for the input and feedback on this thread.
Node.js 16 release: 2021-04-20
Node.js 16 active LTS start: 2021-10-26
AWS Lambda Node 16 support: 2022-05-12
LTS-to-support: 198 days
Node.js 18 release: 2022-04-19
Node.js 18 active LTS start: 2022-10-25
AWS Lambda Node 18 support: 2022-11-18
LTS-to-support: 24 days
That's a big improvement!
I remember a lot of people (myself included) complaining about how Node.js 16 support came very late. Now that Node.js 18 support came in a reasonably timely manner, I feel we need to give credit where it's due 🙂
Congratulations and thanks @jtuliani & team! 🎉
Now, see if AWS can beat the record when Node.js 20 comes out 😜
Great news!
@jtuliani will you and the team update https://github.com/aws/aws-lambda-nodejs-runtime-interface-client to match the Node.js 18 release?
Features described in the blog post, like ES Module support aws/aws-lambda-nodejs-runtime-interface-client#44, do not work. This support is very important for custom docker containers.
Excellent news, and the cherry on the top is that the ESM Module & Lamda Layer issue has also been fixed 🙏
@jlarmstrongiv You're right that the public runtime interface client is not currently in sync with our Node 18 version. It is something we want to address. Can I suggest you file a separate issue for this, for tracking purposes and for others to weigh in with their feedback?
Thank you @paul-uz and @laymonage for your kind words. We're still not where we'd like to be across other languages, but we are continuing our work to improve.
@jtuliani Congratulations on the nodejs v18 runtime release!
Worth calling out that the node.js 18 runtime seems slower than the node.js 16 runtime, any reason why that happened? Thanks!
https://twitter.com/sussmansa/status/1593804631192346624?s=46&t=faTnOE-p9Hnj0qf7-KYT2g
Do you know how to create lambda using node.js 16?
I can't create a lambda edge because nodejs 16 is no more available
Do you know how to create lambda using node.js 16?
I can't create a lambda edge because nodejs 16 is no more available
Why can't you use 18?
Do you know how to create lambda using node.js 16?
I can't create a lambda edge because nodejs 16 is no more availableWhy can't you use 18?
nvm, fixed with
aws lambda update-function-configuration --function-name <funcname> --runtime nodejs16.x
Big congrats to the lambda runtime team on this release! Exciting to see the ESM + Lambda layer now supported.
Middy v4 is now released for nodejs18.x runtime and now uses AWS SDK v3.
I'm curious about the cold start problem pointed out by @chenrui333. Can the AWS team shed some light on this?
@chenrui333 @JacksonGariety We're aware of the reports of longer cold starts on Node 18 and we're investigating the issue. We'll report back once those investigations are complete.
@jtuliani I found this issue, aws/aws-sdk-js-v3#4225, when writing some new functions.
Is this intended behaviour?
I (probably wrongly) assumed that the embedded SDK would work in combination with a local node_modules folder in the function, but it seems like it doesn't.
@jtuliani Any ETA on when node18 will be supported in Lambda@Edge?
@chenrui333 @JacksonGariety We're aware of the reports of longer cold starts on Node 18 and we're investigating the issue. We'll report back once those investigations are complete.
@jtuliani we are also experiencing this. Is there a GitHub issue or somewhere else where we can track the progress on this investigation? This is blocking us from moving away from 16 at the moment.
cc @jtuliani
Regarding cold starts, there's a great article by Yan Cui from a couple of years ago that is still applicable.
TLDR img from the article is attached below.
- even though the numbers mentioned in the article already prove its points, you could further optimize aws-sdk by substituting process.env.* vars aws-sdk depends on (ex. credentials resolution) during minification
For best performance/cold starts, bundle aws-sdk and don't depend on AWS-provided SDK
- you stop to control the version and thus, AWS could either introduce a regression you wouldn't notice until you get an error (instead of testing before deployment) or you would depend on a feature that is not released yet and works locally, but not remotely.
Unfortunately, AWS didn't (or couldn't) listen to the community in the Node.js v16 thread, so we don't have an SDK-free node.js (hopefully soon Bun also) runtime.
Bun support would be a perfect fit for lambda's due to fast cold start, but it's quite a few months from v1 and I doubt AWS will even consider it prior to that.
Bun support would be a perfect fit for lambda's due to fast cold start, but it's quite a few months from v1 and I doubt AWS will even consider it prior to that.
I doubt we'll ever see the likes of Bun or even Deno. Shame.
@jtuliani thank you for the new feature, AWS Lambda runtime management controls.
- does the article mean we are closer to a possibility of selecting (toggling) a runtime node.js/deno/bun at some point in the future?
- since from now on there'd be all versions of node.js available (e.g. 15 versions for node.js 18 as of now), maybe it'd make sense to delight customers by offering a minimal, reasonable for AWS, number of versions for deno & bun
@o-alexandrov Supporting new runtimes such as Deno or Bun would be a separate feature, it's not enabled by runtime management controls. I'm interested to learn more about your use case for Deno and/or Bun. How would they help you?
@jtuliani thank you for considering this request.
imho:
bunwould excite customers due to the performance reasons- community (ex. sharp in this issue) already considers adding support for
bun, so I believe in such performance-critical aspects, likeimage processingbunwould be a good fit forAWS Lambda- especially for
S3 Object Lambda,Lambda@Edge, and hopefully for CloudFront's Edge functions when limits would be higher
- especially for
- community (ex. sharp in this issue) already considers adding support for
denois less attractive to me personally thanbun, I seedenobeing different tonode.jsonly in style rather than anything measurable (including security-related differences)
@jtuliani Has there been any updates on the cold start issue with node.js v18?
@jtuliani Has there been any updates on the cold start issue with node.js v18?
What's the cold start issue?
@jtuliani Has there been any updates on the cold start issue with node.js v18?
What's the cold start issue?
Node 18 has longer cold start in comparison to node 16
@chenrui333 @JacksonGariety We're aware of the reports of longer cold starts on Node 18 and we're investigating the issue. We'll report back once those investigations are complete.
@santiperone Thanks for following up. We have identified the primary cause of the longer cold starts in the Node 18 runtime as thread blocking in a dependency used during initialization. We are evaluating options to resolve this in a future Node 18 runtime update.
@santiperone Thanks for following up. We have identified the primary cause of the longer cold starts in the Node 18 runtime as thread blocking in a dependency used during initialization. We are evaluating options to resolve this in a future Node 18 runtime update.
What's the rough ETA on that update? I hope its sometime this year...
that's excellent news, is it something in the aws lambda runtime interface client?
This was in a newsletter from Node Weekly I received today:
Lambda Cold Starts is a neat page giving a live demonstration of how quickly different AWS Lambda serverless runtimes take to start. Given Node's mature status on Lambda, it does surprisingly poorly?
Seems others have noticed too.
This was in a newsletter from Node Weekly I received today:
Lambda Cold Starts is a neat page giving a live demonstration of how quickly different AWS Lambda serverless runtimes take to start. Given Node's mature status on Lambda, it does surprisingly poorly?
Seems others have noticed too.
How embarrassing.
This is slightly related to performance questions:
Maybe, AWS would kindly consider to provide us with managed by AWS Bun runtime.
any news regarding this issue? is there a ticket we can subscribe to be notified of this progress?
@chenrui333@JacksonGarietyWe're aware of the reports of longer cold starts on Node 18 and we're investigating the issue. We'll report back once those investigations are complete.
@bicatu this ticket is closed, Node.js 18 is available for all Lambda, including Lambda@Edge (support added in January 2023 if I'm not mistaken), some of us just shamelessly pinged AWS here 😅 having an opportunity to be heard
I just created a separate ticket #83 regarding cold starts, so it's in Open state and has less probability of being postponed.
There's still the issue of performance when using the built-in runtime's SDK: https://dev.to/aws-builders/benchmarking-the-aws-sdk-2pd4
@ffxsam funnily enough, I read that same article last night.
Anyone here got a good example/tutorial on using esbuild with Typescript and tree shaking? I can't seem to find anything decent online :/
@ffxsam how to configure esbuild to compile TS and do tree-shaking (and minification).
@paul-uz Tree-shaking is automatic in esbuild, as far as I know. As a test, just create an index.ts file and add a package (like date-fns). Import a function from date-fns, use it in some way, then do:
$ esbuild index.ts --bundle --format=cjs --minify --outfile=min.jsOr --format=esm depending on where you're deploying.
@ffxsam oh sweet. TBH I've simply not yet tried it, as we currently just use TS to compile the JS files, and bundle all the production NPM dependencies in a ZIP.
So, I can use esbuild to compile the TS into JS, at the same time, tree-shaking and minifying everything? So in theory I would end up with a JS file and a trimmed down node_modules folder? Or does esbuild create something else that gets imported?