共计 4251 个字符，预计需要花费 11 分钟才能阅读完成。
申明：
本文转自 DEV Community 网站，文章翻译由开发者社区提供；
点击下方链接，查看英文原文：
- https://dev.to/aws-builders/f…
2022 年 1 月 5 日，AWS 高级解决方案架构师 Sara Gerion 发表，Lambda Powertools TypeScript 曾经进入公开测试阶段。Lambda Powertools 是一个由 AWS 资助的开源我的项目，旨在应用 AWS Lambda 时优化开发人员的体验并采纳最佳实际。Lambda Powertools TypeScript 退出了 Java 和 Python Lambda Powertools 库。
目录
- Node.js Tooling for Lambda
- Decorators
- No Decorators
- 性能
- Tracer
- Logger
- Metrics
- Package Size
- 总结
Node.js Tooling for Lambda
我是 TypeScript 的忠诚粉丝，实际上我还与别人合著了一本对于 TypeScript 的书。我不罕用 Java 或 Python，所以，尽管我对 Lambda Powertools 很感兴趣，但直到现在我才开始尝试应用。Lambda Powertools TypeScript、middy 和 DAZN Lambda Powertools 都是运行 Node.js 的 Lambda 工具。Lambda Powertools TypeScript 与同类库的两点区别在于，前者是由 AWS 资助的，并且反对 decorator。
Lambda Powertools TypeScript 同时反对 JavaScript AWS SDK v2 和 v3 版本，两个版本的例子都会给出。
Decorators
大家对 decorator 的认识不一，但我认为它们是有用的形象，并且在面向对象的 TypeScript 中大量应用。然而，在 TypeScript 中有一个相当大的制约因素，那就是 decorator 能够放在类办法上，但不能放在函数上。这意味着，像这样的代码目前还无奈实现。
这一点很遗憾，因为它能提供很好的开发者体验。为了将 doSomethingGreat decorator 增加到咱们的处理程序上，咱们须要写一些像上面的代码。
这是额定的五行代码，或者不是什么大问题。不管怎样，Powertools 团队能做的不多，因为在函数反对 decorator 之前可能还要等上几年。请记住，如果咱们抉择在 Lambda 中应用 decorator 和类，咱们须要审慎参考这个文件。
（如果不应用 deno）Lambda 中不反对 decorator 和 TypeScript，所以如果要运行 decorator 和 TypeScript，咱们还须要一个转译步骤。侥幸的是，对于 AWS CDK、AWS SAM 和无服务器框架的用户来说，这个问题曾经根本解决。如果你打算或须要推出本人的 decorator 和 TypeScript，esbuild 是一个很好的开始，仿佛是首选的 bundler。
不应用 Decorators
咱们无妨抉择不应用类或转码器。Lambda Powertools TypeScript 能够不应用 decorator，事实上也不须要 TypeScript。咱们能够通过 vanilla Node.js 应用该库。
Lambda Powertools TypeScript 文档十分好，外面提供了几个例子，GitHub 上还有更多例子。
性能
三个版本的 Lambda Powertools 都将 Metrics、Logger 和 Tracer 作为外围工具。Lambda Powertools Python 蕴含一个 Event Handler 和其余一些有用的工具，反对批量解决、有效性、验证等。
Lambda Powertools 的每个版本都是独立开发的，其性能是依据不同运行工夫的不同需要而定制的。区别在于，AWS CDK 应用 jsii 向多个运行工夫公布雷同的构造。尽管期待某些性能可能会令人丧气，但这就是正确的做法，因为如果将通用代码编译成能够装璜多个运行工夫的自定义代码，只会减少复杂性。
为了进行测试，我在一个样本我的项目中施行了 Lambda Powertools TypeScript 的所有三个实用程序。我抉择了 CDK Async Testing 我的项目，因为它蕴含若干个 Lambda 函数，以及通过 EventBridge 和 Step Functions 的异步工作流。
能够点击此处查看我的 instrument 代码。
Tracer
为了通过 Tracer 来 instrument 我的函数，我须要将它们重写为类。我抉择了应用 decorator，因为我还没有决定是否要全副应用类，所以我须要摸索一下。我从 collect.ts 开始，以下是该函数初始的 11 行代码。
下是为了包含 Tracer 而进行的重构。
该函数当初有 25 行代码，这并不可怕。退出 Metrics 和 Logger 工具后，最终变为 33 行。当然，我的函数会更大，因为它领有更多的性能。咱们应该把这种减少看作是加法，而不是乘法。我的 11 行代码函数变成了 25 行。如果它最后有 111 行，它就会减少到 125 行，而不是翻倍。
那么，后果如何呢？Tracer 模块封装了 AWS X-Ray SDK（作为横向的依赖关系）。它并没有减少任何新的性能，而是使 SDK 更易使用。依据我的教训，这个 SDK 的应用有些麻烦，所以这么做是十分值得的。咱们能够装璜类办法，在一行代码中引入新的跟踪段。咱们还能够应用命令的模式在咱们认为适合的中央增加新的跟踪。咱们能够捕捉 AWS 客户端，但这会裸露 X-Ray SDK。
还有一点没有解决，那就是应用 X-Ray SDK 和 DynamoDB DocumentClient 时比拟怪异。在应用 DocumentClient 和 X-Ray 时，咱们须要稍作变通，因为 SDK 须要拜访 DocumentClient 服务属性，但这并没有在类型上反映进去。以下是我解决这个问题的办法。
更新! 这个问题在 0.5.0 版本中曾经解决了! 下面的代码当初能够这样写：
非常感谢这个迅速的改良! 当初我的 DX 变得更好了，以下是我的利用。
原始文本
我不仅取得了十分棒的服务图，还有具体的跟踪。
Tracer 模块正在增加这些截图上的 ##index.handler 局部。我想减少更多的跟踪来更好地利用这个工具。总的来说，通过所有性能和服务取得应用程序的这些具体的跟踪是相当令人印象粗浅的，也是十分有用的。大部分工作由 X-Ray 实现，但更好的开发者体验意味着咱们要 instrument 更多的应用程序，这当然是一件坏事。
在这里我想说的是，跟踪也包含日志，instrument 程序段的日志位于 CloudWatch 中的跟踪。
这一点也很棒。我可能以分布式的形式、应用繁多用处的函数编写利用程序代码，但可能在执行程序时掌控全局。
只有咱们在高吞吐量的利用上设置一个取样率，X-Ray 服务的价格就会很低。定价仿佛是基于跟踪，所以在跟踪中减少额定的代码段并不会减少老本。
Logger
Logger 工具能够间接代替任何记录器，包含控制台。Logger 的附加价值在于可能将 Lambda 上下文注入到所以日志信息中。当咱们用 @logger.injectLambdaContext() 给 handler method 加正文，而后应用 logger.info，咱们会看到如下的日志音讯：
如果咱们打算将日志提取至搜寻索引，或者如果只是想应用 CloudWatch Logs Insights，这真的很不便，因为该构造有助于咱们搜寻和过滤日志信息。另一方面，如果咱们只是查阅大量日志信息，则可能会有点繁冗。咱们应该记住，任何日志服务（包含 CloudWatch）都要按量计费，极其简短的日志老本会很昂扬。
思考到这一点，Logger 工具有很多不错的性能，咱们能够得心应手地构建日志。此外，Logger 还包含一个取样率性能，用于升高费用。
默认状况下，记录器办法须要一个或多个参数。第一个参数是一个字符串或带有音讯键的对象。我发现，如果我将一个字符串作为后续参数，那么这个字符串就会被转换成一个字符数组并被打印进去，所以这一点须要留神。
Metrics
Metrics 工具的用处是公布自定义 CloudWatch 指标。只管 Lambda 会主动公布一些有用的指标，比方提早、并发执行、节流等，但自定义指标能够在指标中增加相干的业务事件，实现可察看性。
追踪可靠性十分重要，但它并不代表全副！自定义指标应该是最重要的指标。这周有多少客户进行注册？其中有多少人可能实现有价值的工作流？这些问题的答案就在代码中，如果咱们收回自定义指标，它们也会呈现在咱们的仪表盘中。
自定义指标的定价构造可能十分低廉。嵌入式指标格局有助于治理老本，并且是由 Lambda Powertools TypeScript 反对。此文档也很明确，不须要我过多论述。让咱们来看看理论体验。我给 collectionSuccess 函数增加了一个 “collectionSuccess “ 的自定义指标。在我假如的应用程序中，会催收局部付款，在这里我标记出催收是否实现领取。
增加 @metrics.logMetrics 会使咱们收回的任何指标都被记录到 CloudWatch。（思考到老本）咱们可能心愿，也可能不心愿这样。要增加一个自定义指标，咱们只需应用 metrics.addMetric。
我对我的利用进行了 instrument，以发射冷启动指标，以及其余形容利用中重要事件的自定义指标，例如胜利 / 失败的领取 / 催收。因为我的利用的重点是展现集成测试，所以我还设置了自定义指标，以显示测试的运行工夫。
这些指标能够在 CloudWatch Metrics 中找到，位于仪表盘或通过 API 导出到第三方工具。
Package Size
在我的项目中增加的所有工具减少的容量，未压缩是 600kb，压缩后是 200kb。思考到其价值以及将局部依赖性链接到 AWS SDK 或 X-Ray SDK 中的须要，这仿佛很正当，而且该团队在贯彻其精益主旨方面做得很好。
总结
Lambda Powertools 将重点放在了开发者真正须要的工具方面，可能优化利用并遵循最佳实际。其中的外围模块都专一于可察看性，这一点是必须的，也是值得赞叹的。该团队开发出的 API，无论是对于应用 decorator 的开发者，还是不应用 decorator 的开发者都具备吸引力。
我心愿这个库可能尽快遍及，我会关注路线图，跟进后续停顿，并参加进来。
文章作者：Matt Morgan
Matt Morgan for AWS Community Builders
