Maintenance: Renaming of Lambda Powertools

[sthulb]

With your help, the Lambda Powertools project has grown since June 2020, starting with the Python version and then adding Java (Aug 2020), TypeScript (July 2022), and DotNet (Feb 2023) languages. As of today, we outgrew the AWS Labs GitHub organization and we plan to move to our new home soon - more on this later 🎉

Meanwhile, we are renaming the project to Powertools for AWS Lambda (TypeScript) to accommodate our growth beyond Lambda (foreseeable future) 🚀 The rename will happen in the next two weeks.

We’ll share more about the new home as soon as we can.

Please ask any questions you have!

[mikecsmith]

Really pleased to see that there's the intention to grow Powertools beyond Lambda.

I'm working with StepFunctions, Lambda's and ECS + Fargate in a TypeScript monorepo project at the moment with a custom logging implementation which uses continuation local storage to avoid injecting parameters but I'd love to migrate fully over to Powertools Logging for everything.

From my reading of the docs I think this should just work but I'm not sure if there are any downsides to using Powertools for Lambda in a Node project that's not running on Lambda - i.e. a container in ECS + Fargate?

[dreamorosi]

Hi @mikecsmith thank you for the message, we are also excited about the news!

To answer your question, generally speaking we don't guarantee that all the features will work outside of Lambda at this stage.

There are some features like the class decorators and Middy middleware that are inherent to Lambda as they assume the presence of a function with a specific signature - these features won't be available unless you architect your code in functions and call it with custom code.

Aside from that most of the features for some of the utilities should work:

• Logger - the utility relies on the presence of a context object to add contextual info to your log entries. You could however supply your own context by calling logger.addContext(context); and passing your own object. All the other features will work normally as long as your code can emit to stdout & stderr.
• Metrics - the utility should work as long as your code can emit to stdout and you have a collector that parses it (or the CloudWatch logs) and is able to interpret EMF metrics and forward them to CloudWatch (this is done automatically in Lambda).
• Tracer - this is the one that might behave less well as the underlying X-Ray sdk works differently on different platforms. You most probably won't be able to use any of the automated tracing, however if you run your own X-Ray daemon (or have one running along your compute platform), and instrument the context in which the code is running with a Trace header, you might be able to create segments, annotate them, put metadata, and eventually send it to X-Ray.
• Parameters - this one should work the same regardless of the platform

[dreamorosi]

With the migration to the new GitHub Organization, repository, and documentation we can consider the migration completed.

[github-actions]

⚠️ COMMENT VISIBILITY WARNING ⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.