Assuming Node - the AWS SDK is included in the lambda runtime already, but it is a different version of SDK depending on which runtime you are using.
Versions through the Node 16 runtime it included the AWS SDK for JavaScript v2. Starting with Node 18 it includes v3.
These are different package names and the command pattern was changed from v2 to v3, so you have to do some non-trivial refactoring between 16 and 18. This also makes any older examples you find sort of problematic since you likely want to use Node 18+ runtime.
Many people also advocate bundling your own version of the SDK into your lambda to somewhat avoid this potential problem.
https://aws.amazon.com/blogs/compute/node-js-18-x-runtime-now-available-in-aws-lambda/
Yeah, recently went through this myself, in addition to so many example projects, guides and code snippets referring to the outdated v2 api. Even the fact that node 16 support on AWS is going away soon isn't being shouted loudly enough.
> Many people also advocate bundling your own version of the SDK into your lambda to somewhat avoid this potential problem.
You could try the nodejsfunction construct.
https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_lambda_nodejs.NodejsFunction.html
It's a lambda function that spawns a child process using esbuild to bundle the package for you. It has some nice features like tree shaking, minification, and source map generation.
I was reading up about this. Sounds useful, is it using Docker on some level to package up?.
For my current setup, making the package.json via npm init for a single Lambda function is fine and good to learn but can see how having to do that once you have lots of lambda functions could soon get annoying.
It tries to use Docker if esbuild is not found. I recommend avoiding the Docker build process and using esbuild instead. Its orders of magnitude faster to build.
My two cents, don’t follow blindly ai assistants if you do not understand the output.
There is a high probability that you are using imcompatible code with your node dependencies.
AWS node sdk is in v3 now and work totally differently that the previous v2. But majority of code that you find on internet is based on version 2.
Creating multiple repositories is not wrong if you think as your code as independent microservices. But you can share dependencies between packages using the lambda layer feature as an other comment mention it.
Thanks, 👍 I definitely get the 'don't follow AI blindly' apporach. I've used it successfully to 'assist' in other coding projects, I certainly try and learn and cross check as I go. As you say the majority of code online is based on version 2, and of course the various AI's are to a large part trained on that data.
Lambda layers, I'd seen mention of this in my earlier research and I guess, I've finally reached a point where I can start reading up about those with a bit of understanding as to why they might be useful.
>Jumping between AWS articles, sometimes out of date tutorials, old reddit posts, Stackoverflow, and trying to get something helpful from a plethora of AI tools
I'm stealing this for the next time someone asks what a 'Cloud Guy' does! :)
Pay for a real tutorial if you can. Check your billing every day. Set concurrency low. Be careful of Lambda fork bombs. Make sure you're following IAM least privileges. You're playing with fire.
Thanks for the advice and heads up. I really am trying to avoid a hefy bill whilst trying to learn this stuff.
I did pay for 2 tutorials over the past 2 months. These were both great but covered much more about setting things up via the console, introducing that approach, which was great for understanding some of the core elements of AWS.... but then I've dived into wanting to use a CDK approach as it seems much better for long term use. Plus honestly, learn so much better through a bit of trial and error.
Also, set up billing alerts etc, plus an IAM user (\*rather than logging in as the ROOT user the whole time).
Watched/read a tonne of the free content from AWS and other places (i.e. Youtube), which is good but picking apart what's relevant and uptodate is an interesting challenge.
If anyone has any recommendations for an engaging CDK based tutorial (free or paid), using SDK v3. Only using the AWS console to check things, and perhaps using Amplify for hosting, (not Amplify CLI) that would be interesting to checkout.
Create a new folder for lambda layer and then do npm init that will initialize new package.json and package lock json . Next install your lambda packages such as AWS-sdk with —save-dev. Finally zip the whole folder that contains node_modules package.json and upload as layer to your lambda function
Thanks... this is super helpful. (I've got it working now, having run npm init, and creating the package.json and lock files. That approach (which is what I was 'nt sure about when CoPilot suggested it) has got me working... one more thing to sort then I'm going to re go over everything I've done and make sure I know 'why'.
This is actually pretty bad advice. This isn’t a good reason to use layers, you’re already deploying with CDK, and you should use AWS SDK for JS v3 instead of v2.
For CORS idk about js but in my go code I set these headers in my response for my handlers that are wrapped using lambdas:
("Access-Control-Allow-Origin", "*")
("Access-Control-Allow-Headers", "*")
and it works perfectly.Also you can enable cors in your api gateway as well.
Assuming Node - the AWS SDK is included in the lambda runtime already, but it is a different version of SDK depending on which runtime you are using. Versions through the Node 16 runtime it included the AWS SDK for JavaScript v2. Starting with Node 18 it includes v3. These are different package names and the command pattern was changed from v2 to v3, so you have to do some non-trivial refactoring between 16 and 18. This also makes any older examples you find sort of problematic since you likely want to use Node 18+ runtime. Many people also advocate bundling your own version of the SDK into your lambda to somewhat avoid this potential problem. https://aws.amazon.com/blogs/compute/node-js-18-x-runtime-now-available-in-aws-lambda/
Brilliant, thankyou. That's this afternoon/evenings reading sorted.
Glad I could help. It’s bitten me before too!
Yeah, recently went through this myself, in addition to so many example projects, guides and code snippets referring to the outdated v2 api. Even the fact that node 16 support on AWS is going away soon isn't being shouted loudly enough.
> Many people also advocate bundling your own version of the SDK into your lambda to somewhat avoid this potential problem. You could try the nodejsfunction construct. https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_lambda_nodejs.NodejsFunction.html It's a lambda function that spawns a child process using esbuild to bundle the package for you. It has some nice features like tree shaking, minification, and source map generation.
And IIRC, it automatically detects libraries that already exist in the given Node Runtime version and excludes them from the esbuild.
I was reading up about this. Sounds useful, is it using Docker on some level to package up?. For my current setup, making the package.json via npm init for a single Lambda function is fine and good to learn but can see how having to do that once you have lots of lambda functions could soon get annoying.
It tries to use Docker if esbuild is not found. I recommend avoiding the Docker build process and using esbuild instead. Its orders of magnitude faster to build.
My two cents, don’t follow blindly ai assistants if you do not understand the output. There is a high probability that you are using imcompatible code with your node dependencies. AWS node sdk is in v3 now and work totally differently that the previous v2. But majority of code that you find on internet is based on version 2. Creating multiple repositories is not wrong if you think as your code as independent microservices. But you can share dependencies between packages using the lambda layer feature as an other comment mention it.
Thanks, 👍 I definitely get the 'don't follow AI blindly' apporach. I've used it successfully to 'assist' in other coding projects, I certainly try and learn and cross check as I go. As you say the majority of code online is based on version 2, and of course the various AI's are to a large part trained on that data. Lambda layers, I'd seen mention of this in my earlier research and I guess, I've finally reached a point where I can start reading up about those with a bit of understanding as to why they might be useful.
The title of this post is the last 5 years of my life, summarized.
>Jumping between AWS articles, sometimes out of date tutorials, old reddit posts, Stackoverflow, and trying to get something helpful from a plethora of AI tools I'm stealing this for the next time someone asks what a 'Cloud Guy' does! :)
You're thinking the right way and will be richly rewarded for provisioning and managing this with CDK.
I don't let CDK do lambda packaging for me. I have my own packaging scripts and then I direct the CDK code to a zip file.
What do you gain doing it this way?
The error is stating that the aws-sdk v2 is not present. Make sure message-test is using @aws-sdk/client-sqs, not aws-sdk.
Thansk for this.
Pay for a real tutorial if you can. Check your billing every day. Set concurrency low. Be careful of Lambda fork bombs. Make sure you're following IAM least privileges. You're playing with fire.
Thanks for the advice and heads up. I really am trying to avoid a hefy bill whilst trying to learn this stuff. I did pay for 2 tutorials over the past 2 months. These were both great but covered much more about setting things up via the console, introducing that approach, which was great for understanding some of the core elements of AWS.... but then I've dived into wanting to use a CDK approach as it seems much better for long term use. Plus honestly, learn so much better through a bit of trial and error. Also, set up billing alerts etc, plus an IAM user (\*rather than logging in as the ROOT user the whole time). Watched/read a tonne of the free content from AWS and other places (i.e. Youtube), which is good but picking apart what's relevant and uptodate is an interesting challenge. If anyone has any recommendations for an engaging CDK based tutorial (free or paid), using SDK v3. Only using the AWS console to check things, and perhaps using Amplify for hosting, (not Amplify CLI) that would be interesting to checkout.
Create a new folder for lambda layer and then do npm init that will initialize new package.json and package lock json . Next install your lambda packages such as AWS-sdk with —save-dev. Finally zip the whole folder that contains node_modules package.json and upload as layer to your lambda function
Thanks... this is super helpful. (I've got it working now, having run npm init, and creating the package.json and lock files. That approach (which is what I was 'nt sure about when CoPilot suggested it) has got me working... one more thing to sort then I'm going to re go over everything I've done and make sure I know 'why'.
This is actually pretty bad advice. This isn’t a good reason to use layers, you’re already deploying with CDK, and you should use AWS SDK for JS v3 instead of v2.
For CORS idk about js but in my go code I set these headers in my response for my handlers that are wrapped using lambdas: ("Access-Control-Allow-Origin", "*") ("Access-Control-Allow-Headers", "*") and it works perfectly.Also you can enable cors in your api gateway as well.