如果您去年一直在使用 Javascript 和 AWS SDK,您可能在浏览他们的文档时注意到了这条消息:

[](https://res.cloudinary.com/practicaldev/image/fetch/s--YNyIYKA9--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to- uploads.s3.amazonaws.com/uploads/articles/fl2gsxdog9uxbq0f68n5.png)

好吧,实际上 AWS SDK 版本 3 已经公开提供了一年,现在,所以我利用一个全新的闪亮项目的机会开始使用它。

这是个好主意吗?

我还不能告诉你,我们仍在编写前几行代码,但采用它会带来一些麻烦。

有什么区别?

除其他外,主要有趣的变化和功能是

• 模块化架构:每个服务都有一个单独的包。无需拉入整个 sdk 即可使用 s3!

• 一流的 Typescript 支持。

• 中间件:不再将侦听器附加到请求以操纵它并控制调用的生命周期,现在可以使用中间件堆栈,其中_堆栈中的每个中间件在对请求对象进行任何更改后调用下一个中间件_,改进可读性和调试经验。

• 个人配置:不再有由 SDK 管理的全局配置。必须将配置传递给实例化的每个服务客户端。

我真的建议查看repo尤其是升级部分以了解更多详细信息。

这里只是几个简单的例子

使用版本 2,您将导入内容并进行这样的调用 - 假设您远离回调并且使用 async await:

const AWS = require("aws-sdk");
const s3Client = new AWS.S3({});

// yes you can also do. 
// const S3 = require('aws-sdk/clients/s3');
// const s3Client = new S3({})

await s3Client.createBucket(params).promise();

进入全屏模式 退出全屏模式

使用版本 3,您只需 npm install 并需要单独的服务/包

const { S3 } = require("@aws-sdk/client-s3");
const s3Client = new S3({});
await s3Client.createBucket(params);

进入全屏模式 退出全屏模式

如您所见,差别不大,但要好得多。

另一方面,尽管我仍然觉得它更好、更易读和可重用,但 Command 方法需要对代码进行相当多的更改,并且需要时间来适应它。

import { S3Client, GetObjectCommand } from "@aws-sdk/client-s3"; 
const client = new S3Client(config);
const input = {
    Bucket: 'abc', // your bucket name,
    Key: 'abc.txt' // path to the object you're looking for
}
const command = new GetObjectCommand(input);
const response = await client.send(command);

进入全屏模式 退出全屏模式

在版本 2 中

const aws = require('aws-sdk');
const s3 = new aws.S3(); 

var getParams = {
    Bucket: 'abc', // your bucket name,
    Key: 'abc.txt' // path to the object you're looking for
}

const response = await s3.getObject(getParams).promise()

进入全屏模式 退出全屏模式

不管怎样,我们就这样开始了我们的项目,每一件小事都花更长的时间,只是为了适应新的文档,它也有完全不同的格式,但我们很高兴,直到我们意识到一些Middy 中间件仍然依赖于旧版本的 SDK,我们开始怀疑这是否可行。

经过一番搜索,我们惊讶地发现 Lambda 运行时没有预装 aws-sdk v3,而是 v2。

怎么样?为什么?!那是问题吗?

是的,根据这些 lambda 示例:

适用于 JavaScript v2 而非 v3 的 AWS 开发工具包安装在默认 Lambda Node.js 环境中。此处链接的示例演示了如何将所需的适用于 JavaScript v3 的 AWS 开发工具包模块与示例代码捆绑在一起。

这是否意味着我们需要捆绑两个版本的服务呢?

并非如此,因为您始终可以从捆绑包中排除 aws-sdk,因为它已经在 Lambda 运行时中可用:

例如,在 CDK 中,您可以从捆绑中跳过 aws-sdk,如下所示:

    bundling: {
                minify: true,
                externalModules: [
                    'aws-sdk', // Use the 'aws-sdk' available in the Lambda runtime
                ],
            },

进入全屏模式 退出全屏模式

所以,

• 当您使用 v2 时,您不必将 lambda 与它捆绑,因为它已经在运行时中,您可以捆绑您的代码并拥有更小的包。

• 如果您使用 v3,则您具有模块化架构,因此您不会引入整个 aws,而只是引入您需要的代码,因此捆绑更小。这里是您可以阅读 AWS 团队的一篇有趣的文章,描述他们如何将模块化 SDK 的发布大小减半。

当然,我们只能捆绑我们使用和从版本 3 导入的小包,如果我们的中间件使用来自 v2 的东西,它们将从运行时获取它。

但是,这一切有意义吗?

那么你应该使用v3还是不使用?

嗯......这取决于。首先,如果您正在编写与 AWS 交互的代码,这些代码将在您的机器或 docker 上而不是 lambda 上运行,那么使用 v3 绝对是有意义的。

但即使在 lambda... 显然来自 2 个版本的代码可以共存(尽管对于开发人员来说很难看和令人困惑)所以这不是问题,根据一些](https://theburningmonk.com/2019/09/should-you-pack-the-aws-sdk-in-your-deployment-artefact/)的[,你应该总是捆绑 aws-sdk 因为轻微您认为您正在使用的差异(最新稳定版本和安装在Lambda 运行时上的版本。(例如,在编写此 v2 的最新版本时为 2.1045.0 而安装的版本在运行时是 2.1001.0 - 这是 44 个具有改进和错误修复的小版本!!)

此外,其他中间件和包将很快升级,因此这个问题将变得不那么常见,同时您仍然可以利用 typescript、模块化架构并放弃那个该死的 .promise() 东西。

所以,老实说,我不会迁移一个正在运行的项目,但如果你是从头开始一个新项目,我认为开始使用 v3 是有意义的——这不是 beta 版或尖端的——如果你去 github 或官方文档随处可见,建议使用V3,因为它已经公开可用一年了。

如果您想了解更多关于 v3 的优缺点并阅读其他意见我真的建议这篇文章

希望能帮助到你