Improve AWS Lambda experience

[Lms24]

I investigated AWS lambda support in the last couple of days and found multiple issues we should tackle to improve the SDK/Usage experience with our @sentry/aws-serverless SDK and AWS Lambda layer:

General AWS Lambda Support

Beta Give feedback

1. fix(aws-serverless): Only auto-patch handler in CJS when loading awslambda-auto #12392
   +0
   
2. fix(aws-serverless): Only start root span in Sentry wrapper if Otel didn't wrap handler #12407
   +0
   
3. fix(aws-serverless): Add op to Otel-generated lambda function root span #12430
   +0
   
4. ref(aws-lambda): Restructure and improve AWS Lambda SDK documentation sentry-docs#10655
   +0
   

ESM Lambda Support

Beta Give feedback

1. test(e2e): Add e2e test for AWS lambda in ESM mode #12833
   +0
   
2. Investigate why Otel Http Instrumentation doesn't record spans
3. ref(aws-lambda): Restructure and improve AWS Lambda SDK documentation sentry-docs#10655
   +0
   

ESM Lambda Layer

Beta Give feedback

1. Create ESM Lambda Layer #12856
   0 of 9
   Feature: Serverless Package: aws-serverless +2
   

[G-Rath]

Not sure if you're already tracking this or what, but fwiw it looks like switching to @sentry/aws-serverless adds an extra 2.2mb to my lambdas - it doesn't sound like a stated or expected goal, and I imagine some "new" size is in new feature stuff, but it still feels like a weird jump given #11052 says "removes all GCP related code".

Something else I find telling is that installing @sentry/serverless only adds 19 packages whereas @sentry/aws-serverless adds 82 on my project apparently - again, not the end of the world and I've not done any digging, but thought you might be interested 🙂

The lambdas themselves are typescript based, compiled with serverless v3 + tsc as per https://github.com/ackama/serverless-aws-template

[Lms24]

@G-Rath the increase in dependencies and size is caused by us switching to OpenTelemetry for instrumentation. By default, the our AWS Serverless SDK does not include performance instrumentation (e.g. for databases like postgres). However, if you only use tsc to build your functions I'm fairly sure that some unused code and dependecies are not tree-shaken out. Meaning your build might be larger than it has to be.

Have you looked into bundlers like rollup? they should be able to tree-shake out all unused code.

That being said, I have never heard of sls before so not sure if it does any optimizations under the hood. My reference is basically manually zipping up a lambda function including its node_modules and deploying it with the AWS CLI. In this workflow, I know for sure that no code elimination is done at all.

[G-Rath]

@Lms24 thanks for following up so quickly, and sorry for my delay in responding.

You're right that neither tsc or sls do treeshaking - so far we've not used any tree shaking for our serverless functions as they're small enough, fast enough, and non-critical in their current form, and everytime I've looked at bundler integrations for serverless they've always seemed overly complex relative to that; totally accept those that downside is by our choice so if you've focused on optimizing size based on treeshaking that's fair (though I'm still a little sad that "us switching to " has resulted in such a huge leap but oh well that is what it is).

I have never heard of sls before so not sure if it does any optimizations under the hood

sls is the short cli command for the serverless framework - the main optimization v3 does out of the box is allow you to exclude whole files but that's part of the whole "you're not treeshaking" thing since it lets you axe "not javascript" kind of files emass rather than anything surgical.

(on an aside, it's a great way to get that "eehhh wat" feeling as you go through the list of file extensions in your node_modules - you (won't) be surprised at what stray files get captured in published packages...)

[Lms24]

I'm going to close this issue as the immediate work, including the docs update, was completed. We're tracking #12856 separately to further improve ESM support.