#106: Rust with Lambda, easy-mode Rust & future of Middy | ft. Luciano Mammino
45:51 Share

本期节目由 HookDeck 赞助播出。HookDeck 是一个完全无服务器的事件网关，可提升您的事件驱动架构。要了解更多信息，请访问 hookdeck.com/theburningmonk。大家好，欢迎回到 Real World Serverless 节目的结尾。今天，我和 Luciano 聊聊，我已经认识他很多年了。我相信你们许多在无服务器领域的人可能过去甚至使用过 Luciano 的项目。所以，嘿，欢迎来到节目。

谢谢，Ian。很高兴来到这里。这是我最喜欢的关于 AWS 和无服务器的播客之一。所以能来到这里真的荣幸之至。

谢谢，谢谢。我不得不说，我真的很喜欢你和 4Theorem 的伙计们一起做的那些小视频，8 位精灵，简短精悍的视频。我喜欢那些非常具体的主题。如果其他人想查看，我也会在描述中添加链接。你们一直非常活跃，视频发布也很规律。是的，我想我们现在大约有 120 集了。

我们已经每周做一次很长时间了。现在我们最近改为每两周一次，因为持续下去太费力了。但是，我们仍然尽量保持规律。

我还看到你在社交媒体上发布了很多关于 Rust 的内容。我想你已经全心全意投入到 Rust 了。我想也许我们可以，你还在写一本已经写了一段时间的书。所以我们稍后再谈谈这个。但我认为大多数人可能通过你与 MIDI 的工作认识你。是的。

你想花几分钟时间谈谈你的背景，你是如何进入无服务器领域的，以及 MIDI 是从哪里来的吗？是的，当然。我的背景主要是全栈 Web 开发。我想我现在已经有 15 年甚至更长时间的从业经验了。大部分时间都在使用各种技术构建网站和 Web 应用程序，从

我不知道，.NET、PHP、Java、JavaScript。我想我已经见识过相当多的不同技术了。是的，JavaScript 可能仍然是我最喜欢的，也是我尝试最多、可能也是我最熟练的一种。

如果我们要具体谈谈 Mead，Mead 的故事可能始于 2016 年。Mead 文档上实际上有一个链接，显示了一点时间线。所以如果你想的话，我们以后可以在节目说明中添加链接。是的，在 2016 年，我在这家创业公司工作。它是爱尔兰一家主要电力供应商的分支机构。

他们试图为大型电力消费者建立一个有效的电力交易平台。其想法是，作为一个大型消费者，你可能必须预先购买能源，但也会有一些时刻你的能源比你需要的多，你可以转售。所以试图为电力消耗创建一个非常动态的市场。

这是一个非常令人兴奋的项目，主要是因为我们有几个非常好的经理，他们给了技术团队很大的自由。当然，当你这样做时，发生的事情是团队可能会开始变得有点疯狂，有点偏离常规路径，我会这么说。所以那是 Lambda 刚刚发布一年的时间。它仍然是一种相对较新且令人兴奋的技术。所以当然，作为一个拥有很多自由的团队，我们想，好吧，我们要用 Lambda 来构建一切。

我们甚至不了解 Lambda，但这就是做出的决定。

所以这是你当团队有很多自由时可能会做的那种疯狂的事情。我认为回想起来，这实际上是一个非常好的选择。我不知道如果当时我是经理，我是否会选择那样做，但作为一个团队成员，这是一个很好的选择。我学到了很多关于 AWS、无服务器和 Lambda 的知识。而且，由于它是一项新技术，你并没有真正得到很多指导，所以有很多人在谈论它并提供教程和示例。

我们通过构建东西、犯错误、意识到错误、然后重新构建来学习。那很有趣。但我认为这也让我真正理解了 Lambda 的工作原理。最终，我们想出了一个主意，为了使我们的代码更易于管理，我们需要以更好的方式对其进行抽象。

我们想出了这种中间件引擎类型的解决方案，它最初都是内部的。所以实际上，我们想要做的是复制类似 Express 的东西，你为特定的处理程序编写自己的业务逻辑，但是你可能有一些问题，比如，我不知道，验证、身份验证、序列化、反序列化，它们是必须执行的重复代码。

几乎到处都是复制粘贴。所以在类似 Express 的东西中，你会做什么，你会有一个中间件，你可以用一些配置附加它，基本上尝试从你的特定端点的核心业务逻辑中移除所有这些业务逻辑。所以基本上我们想重新创建类似的东西。当时，我认为已经有一些解决方案试图包装

express 本身用于 Lambda，所以基本上模拟传入的事件，将其转换为 HTTP 请求，然后获取事件响应，对不起，获取 express 响应，将其转换为事件响应，并执行所有这些神奇的操作。

但我们觉得这个解决方案对于我们想要做的事情来说有点太重了。而且，我们还有一些事件不是 HTTP 的情况，所以在没有 HTTP 事件和响应的情况下使用 Express 这种方法并没有多大意义。所以这可能是我们构建自己的中间件框架的原因。

我们使用它大约一年时间。我认为我们对此非常满意。它对我们来说运行得相当好。但一年后，不幸的是，公司的情况并不像预期的那样好。他们没有获得更多资金，所以公司倒闭了。我认为在这一点上，团队只剩下一个选择。就像，好吧，我们看到我们构建的东西有很多价值。这个中间件引擎可能是我们现在可以与业内其他人分享的最酷的事情之一。值得庆幸的是，我们得到了许可

将其从该组织中移除，使其开源。这就是 MIDI 的诞生之处。这就是我们当时选择的名称，以开源项目的形式继续这个项目。

是的，我认为现在很多人都在使用 media，甚至 Lambda Power Tools 也围绕它的一些中间件进行了标准化。对于 Python 版本，他们有自己的中间件工厂之类的东西，但这更多的是针对 Python 的。

而且我认为我还看到其他一些类似的尝试，为其他语言运行时引入了这种中间件引擎，它可以处理许多常见的跨领域问题。我认为有时我也看到人们走得太远了。我还看到

一些开发人员发现中间件是一件事，突然间所有东西都被塞进中间件里。所以不是有一个带有某些业务逻辑的处理程序，然后围绕一些中间件来处理一些跨领域的问题，就像你说的那样，比如，包装，嗯，

包装一些错误到 400、500 响应之类的东西。相反，你突然发现自定义业务逻辑被包装到中间件中。不是共享库、共享模块，它们都变成了中间件和组合器，这样你就看不到处理程序中的任何东西。只是一堆中间件。很难理解。

所以我看到人们走得太远了。是的，但是，是的，MIDI 已经是一个非常成功的项目了，是的，我很高兴你们取得了如此大的成就。我想 Will 在过去几年里一直在主要推动 MIDI 的发展。是这样吗？是的。所以实际上回到故事中，接下来发生的事情非常有趣，因为

我认为我可能是最初那组人中最兴奋的一个关于 MIDI 的。所以那时来自那家公司的其他人转向了不同类型的活动。我可能是最努力推动 MIDI 开源的人。所以在这一点上，我以某种方式成为了维护者，非正式的，我不知道正式的，但我做的大部分工作。而且

与此同时，我在一家不做太多无服务器甚至不做太多 Node.js 的公司工作。所以有很多 Python。我们在 AWS 中做的事情更多的是在弹性搜索领域，并使所有这些都具有可扩展性。所以我很难跟上 MIDI 和无服务器的创新，同时将我大部分时间都花在其他主题上。我想我坚持了两年左右。然后我觉得我

我有点筋疲力尽了，有很多问题我没有时间回答，我感到有点内疚。我认为这是开源维护者中常见的事情，你创造了一些东西，你认为它有价值，人们喜欢它并开始使用它，然后你跟不上，你为此感到负责。所以我记得我在 repo 上写了一个非常诚实的 issue，说：

看，我认为我不是继续做这件事的最佳人选。我觉得我筋疲力尽了。我没有做我认为维护者应该为这个项目做的事情。所以还有其他人想接手吗？那一刻，Will，当时是主要贡献者之一，站出来说，好吧，我可能有更多时间投入到这个项目中。我很乐意这样做。我认为从那时起，他一直在做着令人惊叹的工作。我认为这让我……

所有接下来的发展阶段。我认为我只拥有启动它的特权，但 Will 才是真正将它变成我们今天都使用和喜爱的工具的人。所以我要借此机会感谢 Will 做了所有这些。

是的，整个开源模式有点破损。它运作的唯一方法一直是当你的开源项目由一个捐助者、一家大型科技公司支持时，他们出于营销或其他需求这样做。否则，人们在全职工作之余还要做这件事。使用这些开源项目的人也相当

有时也很挑剔和大声。因此，平衡你的职业生活、个人生活和所有这些其他要求你更改的开源人员的要求绝对不容易。所以我完全理解为什么你需要一些帮助，需要远离它。

那么在这种情况下，你是否仍然参与项目的规划，MIDI 的下一步是什么？我知道现在是 5 版。我仍然停留在 4 版，因为 5 版的 ESM 唯一要求仍然是我的障碍，我认为对很多人来说也是如此。从你的角度来看，MIDI 的未来是什么？

绝对的。现在可能是澄清我目前参与情况的好时机。我仍然参与其中。我仍然是正式的维护者之一。但公平地说，我的参与相当有限。我更多的是……

我不知道我想称自己为顾问，但这可能更接近我所做的工作。我一直在做一些关于 TypeScript 的事情，但这主要是因为这可能是目前存在的一个问题，我们稍后可以在这次聊天中讨论。但是，是的，我可能是做这件事的最佳人选，即使我不认为自己是该项目真正做好 TypeScript 工作所需的 TypeScript 专家。

但当时我是做这件事的最佳人选，所以我做了关于 TypeScript 的大部分工作，并在 TypeScript 再次出现在对话或问题中时尝试提供一些帮助。所以，参与非常有限。可能每隔几个月几个小时，只是和 Will 聊聊，看看我如何提供帮助。但是的，他仍然在做大部分的重担，我会这么说。

是的，关于当前状态和下一步是什么，我的观点，我也会尝试报告 Will 的观点，因为我在准备这次采访时问了一些问题，那就是现在 MIDI 处于相当不错的状态。在提高性能、提高稳定性方面已经付出了很多努力。所以我想尤其……

从 3 版到 4 版，在这个领域付出了很多努力。所以即使你使用的是 4 版，我认为你仍然可以获得大部分这些东西。然后从 4 版到 5 版，重点更多地放在进行破坏性更改并从双模式转向仅 ESM。这有点痛苦。我认为我们仍然很高兴我们做出了这个决定，因为我们认为未来将更多地是 ESM，并且最终……

CommonJS 即将消失。这样做只是简化了 MIDI 的维护。在某种程度上，我们看到的错误更少了，因为我们过去有很多错误报告仅仅是因为双模式以及正确配置所有这些双模式。所以之前想使用 ESM 的人并没有真正度过一段美好的时光。现在想要使用 ESM 的人应该相对简单直接。

AWS 还有一篇由 Dan Fox（无服务器首席专家解决方案架构师）发表在 Compute 博客上的文章。其中有一些基准测试表明，如果你使用 ESM，你会获得更好的性能，尤其是在冷启动方面。所以这是我们试图更多地推广

ESM 方法的另一个动机。当然，我们理解并非每个人都准备好进行切换，但希望如果你正在构建一个新项目，你可以直接使用 ESM。一些仍然存在的问题，不幸的是，当你将 ESM 与 TypeScript 结合使用时。

而且我不认为这是任何人的错，我会这么说。这并不是 MIDI 的错，也不是 TypeScript 的错。我认为只是 TypeScript 有如此广泛的配置。尤其是在选择输入模块系统、输出模块系统以及要定位的 ECMAScript 版本时，存在如此多的可变性。这就像一个巨大的矩阵

你可以拥有的可能性。我认为有很多配置与 MIDI 在 ESM 中的配置方式不兼容。所以我们只是因为人们带着各种 TS 配置而来，MIDI 无法立即工作，所以我接下来该怎么办？

我不知道是否真的存在一个可以在所有用例中都能工作的通用解决方案。我们已经确定了一个与 MIDI 的当前 ESM 版本兼容的 TS 配置。这就是我们在文档中建议的。如果您有任何问题，请尝试查看是否可以在您的 TS 配置中调整这些参数，看看它们是否应该消失。

所以希望这能为大多数人解决问题，但这仍然是一段旅程，看到人们进来并说，嘿，看，这不起作用。我正在使用 TypeScript。他们甚至没有告诉你他们有什么样的配置，因为很多人没有意识到 TypeScript 并不是一种语言，而更像是一种

一个语言的宇宙，它真的取决于你的多元宇宙。你在那个多元宇宙中选择的宇宙取决于你拥有的 TypeScript 配置。所以是的，一旦你开始谈论这个，并且你将他们引导到文档中的正确方向，我认为大多数人都能够解决他们的问题。我们仍然有一些关于

类型的问题，因为正确地键入中间件实际上非常困难。当我开始编写所有 TypeScript 时，我没有意识到这一点，因为中间件本质上是如此动态，它可以改变所有传入和传出的类型。所以你必须嵌入所有这些逻辑以及你如何链接不同的中间件。类型系统应该跟踪所有链，并确保它在正确的位置提供正确的类型。

正确地做到这一点非常困难，我认为我们的类型声明中仍然有一些错误。有时我们会收到错误报告，说，嘿，我正在执行这个特定的事件链，并且我得到一个类型跳过错误。然后我们必须深入研究并弄清楚也许我们需要稍微调整类型系统，对不起，类型声明以支持该特定用例。从维护的角度来看，这有点痛苦，因为

我们的核心团队中并没有很多 TypeScript 专家。现在，我们有一位贡献者 Naur Pellet 正在最大限度地帮助我们解决这些问题。他似乎是最有经验的人。所以绝对要感谢他。但是是的，如果任何对 TypeScript 有经验的人有兴趣帮助 media，我认为在接下来的版本中，我们可能会有一个做得更好的领域。所以向任何想要贡献的人发出公开邀请。

好的，听起来不错。有趣。是的，我遇到过一些其他人，其中一个客户特别构建了自己的 TypeScript 中间件。他们决定这样做的原因是，当时 MIDI 在 TypeScript 中的故事并不那么好。当你编写新的中间件时，没有类型信息。所以他们写了自己的东西。我想他们的实现更

约束，所以他们可能没有遇到你在类型方面遇到的相同问题，从一个中间件到另一个中间件的更高层次的流程。但我想谈谈类型，Rust。你是如何开始使用 Rust 的，以及你目前对 Rust 的感觉如何，与使用 Rust 进行 Lambda 函数相比，比如 JavaScript？

是的，我认为总的来说，澄清我首先对 Rust 感兴趣的原因可能值得一提。正如我在开头所说，我在使用不同的编程语言方面有相当多样的背景。但是几年前，大约三到四年前，当 Go 和 Rust 出现热潮时，

我意识到我大部分职业生涯中所了解和使用过的所有语言，它们都是高级解释型语言。其中一些可能编译到虚拟机，但我对低级语言并没有太多经验。所以这就是我对 Rust 感兴趣的原因，因为我觉得

我不一定需要成为专家。我只是想学习一点，看看我 15 年来一直在使用的语言和一种稍微低级的语言之间的区别，以及这会带来哪些机会。

而且我实际上非常惊讶。实际上，最初有点棘手。最初，这段旅程并不像我预期的那样顺利，因为有很多东西需要学习。即使只是内存管理，我在大学里也学习过，但实际上并没有使用过。所以我可能在理论上了解一些事情，但是然后尝试将这些事情付诸实践，你需要学习的东西还有很多。所以最初有点坎坷，但后来我爱上了 Rust 和整个生态系统，因为……

这是一种语言，他们花费大量时间来确保开发人员体验良好。甚至编译器也会给你惊人的错误，这些错误会教你接下来该做什么来修复你的问题，这是我希望其他语言中也存在的东西。

我还意识到，作为一种语言，它有非常广泛的用例，比如你可以从在 Raspberry Pico 中构建你自己的固件开始，到构建 Web 应用程序，甚至 Web 应用程序的前端，如果你想的话，一个全栈 Web 开发框架。所以正因为如此，我认为这是一种潜力巨大的语言，并且社区似乎非常喜欢它。所以使用了几年之后，我开始意识到，好吧，如果你想在 Lambda 中使用它会发生什么？

然后我意识到这可能是该语言在云计算中的最佳用例之一，因为 Lambda 的定价模型非常适合 Rust 的特性。与其他语言相比，你可以获得最佳的冷启动、最佳的内存利用率和通常令人惊叹的性能。所以你基本上减少了定价的两个维度，即内存分配和执行时间。

此外，你还可以获得非常非常高效的冷启动。我看到平均值大约为 10 到 20 毫秒。所以你几乎可以说那时你没有冷启动。如果你正在构建一个 API，你绝对可以忽略大多数用例的冷启动。所以我想，这是考虑将 Rust 用于 Lambda 的一个很好的建议。我不知道你是否想更多地谈论这个，但这就是我目前的自白。

是的，我想反过来，你必须学习一门全新的语言。如果这就是在 Lambda 上构建高效 API 所需的，那么也许 Lambda 本身就是问题所在。这就是为什么我更……

在使 Lambda 更易于访问更多用例方面，我们需要满足客户的需求。这就是为什么我对我们的 RT 更兴奋的原因，它当然是用 Rust 编写的，并且在 Rust 中实现所有 JavaScript API，而不是 JavaScript 本身。这就是他们能够，你知道，

他们能够获得如此良好性能的原因之一，至少目前是这样。但我们不知道一旦他们实现其他所有内容，所有缺失的 API 和 v1 版本，它是否仍然能够保持当前的冷启动水平，这与你提到的非常相似，个位数，对不起，

对于 JavaScript 函数来说，只有低两位数毫秒的冷启动，并且内存占用非常小。是的，Go 和 Rust 绝对更适合系统编程，在这种编程中，你更关注效率

并且你希望用户进程的占用空间尽可能小，以便你的系统进程应该占用非常小的空间，以便你为用户留下尽可能多的资源来做他们自己的事情，非常优雅。但是是的，我以前玩过 Rust。

早在 1.0 之前，因为我经历了这样一段旅程，几年来我每年都在学习一门新语言，而 Ross 有一个关于资源所有权系统的新想法，这样你就不会有日志和所有这些昂贵的运行时概念，

所以我对它的工作原理非常感兴趣，并花了不少时间玩弄 Rust，部分是为了了解该机制的工作原理。它非常巧妙，但我认为对于许多来自 JavaScript 的人来说，理解这种类型的语言，拥有强大的类型系统是一个障碍。我确实担心，如果我们正在推广，你想使用 Lambda，你应该使用 Rust。这对于人们来说可能很难接受

就大规模采用而言。但我完全明白。Rust 是一种非常适合性能和效率的语言。那么，对于来自 JavaScript 并想学习 Rust 的人，你有什么建议吗？我知道你有一本书。它是否针对该人群？

我认为是的。所以这本书叫做《用 Rust 编写 Lambda 函数》，网站是 lambda-rust.com。

我认为我们会有的。对不起，是 rust-lambda.com。希望我们会在节目说明中添加它。但是是的，我的想法是，至少我的观点是，如果你还不了解 Rust，这有点像投资。我认为 Rust 总体上越来越普遍了。就像我看到越来越多的公司以某种方式采用它。所以我认为那里也存在一个时间因素。我认为如果我们五年后再次进行这次谈话，

可能人们通常来说会不太担心学习 Rust，因为它在业界不同层面的出现会越来越普遍。但现在你是对的，那里确实存在一点障碍，如果你真的想利用我们在 Lambda 上下文中描述的所有好处，但你不了解 Rust，你首先需要学习一点 Rust。现在，我要稍微反驳一下，你需要学习的 Rust 量用于 Lambda

可能比你只是说，我想学习 Rust 来做所有事情或做系统编程要少得多，这是一种更深层次的事情，你需要更清楚地了解如何使用内存。你不能走捷径。但在 Lambda 的上下文中，有一个……实际上有一个不错的演讲，我可能以后会分享链接给你。如果你想的话，你可以把它添加到节目说明中，它叫做《简单模式 Rust》。

这表明如果你愿意的话，Rust 有两个级别。你可以稍微作弊的一个，但它更容易使用。比如，你可以在此处进行一些内存复制，以简化你的生活。诸如此类的事情，基本上你并不一定使用你所提取的最高效的解决方案，但与此同时，它使你更容易使用 Rust。而且

你可以有意识地这样做，然后意识到，好吧，以后，我可以学习如何使用引用，使这段代码的性能更好一些。这就是整个想法。所以我认为在无服务器的背景下，即使只使用 Easy Mode Rust，你仍然可以获得惊人的好处。

然后，如果你真的想投资，再说一次，这仍然只是你需要有意识地做的投资。但如果你想投入更多，你可以说，好吧，现在我想成为一个更熟练的 Rust 程序员，学习更高级的模式。然后下次我用 Rust 编写代码时，如果需要，我知道我可以编写更高效的 Rust 代码。

所以我认为就是这样。这在今天仍然是一项投资。你需要看到那里的长期目标。你需要乐于学习新事物，当然，这并不总是适合所有人，这取决于你的限制。但是如果你做了所有这些，将来会有好处。所以我基本上会告诉人们，自己做评估，自己推理，看看是否值得你的时间，是否值得学习和投资这项技术，而不是也许

使用给你带来不同权衡的其他工具。我也非常期待 LL 或 T。我认为它会……如果它继续下去，如果它设法弥合 Node.js 标准库及其支持内容之间的差距，如果它们真的非常接近于基本上可以获取 Node.js 的任何代码并在 Lambda 中运行它，我认为它将成为 Lambda 的一个惊人的运行时。所以我非常期待看看那里会发生什么。但是现在……

这有点像碰运气，因为如果你从头开始编写新的 Lambda，也许你可以避免使用某些不受支持的东西。但是如果你试图将现有的东西移植到 LL 或 T，我看到大多数情况下它无法开箱即用。你需要弄清楚需要调整什么，删除一些依赖项，重写一些代码。所以现在总是一些投资。

是的，目前它们还没有准备好投入生产使用。它不适用于……我认为对流 API 或许多其他事物的支持并不完整。所以，也许它不起作用。Lambda Power Tool 不起作用。他们正在优先支持 AWS SDK 中的所有内容。而且我认为你是对的。大多数 Lambda 函数只是调用一些 API，调用 AWS 服务。

没有大量的复杂业务逻辑。我想如果你有的话，那么你总是可以在每个函数的基础上切换到更熟悉的函数。但是对于那些对延迟敏感的简单事情，也许可以使用 Rust 的简单模式

只需知道如何安装 AWS SDK，如何调用这些不同的服务，以及它的语法是什么。但是对于 Lambda 的 Rust 支持生态系统在部署方面、打包方面有多好呢？你用什么？你使用服务器框架、CDK 还是其他什么？

是的，这实际上是一个非常好的问题，也是让我感到惊讶的地方，因为它仍然是一个相对较新的东西，而且我认为目前利用这个生态系统的用户并不多。所以我对 AWS 主要在一些贡献者的帮助下所做的工作印象深刻。所以有一些非常重要的部分需要提及。首先，它仍然是一个自定义运行时。所以它不像你获得一个托管的运行时。所以你仍然需要

以某种方式自己提供运行时。但这并不意味着你必须从头开始编写运行时。AWS 提供并维护了一个运行时，你只需将其作为库安装到你的项目中。

当然，启动一个项目并弄清楚如何安装这个特定的运行时，以及想出一个 Lambda 的骨架或样板可能本身就很难。就像如果你从未做过 Rust，那可能会让你立刻放弃。所以他们还创建了一个名为 Cargo Lambda 的工具，它是 Cargo（包管理器，你与 Rust 一起使用的默认包管理器）的扩展。所以当你安装 Rust 时，Cargo 就相当于 Node.js 的 NPM。

当你有了 cargo Lambda，你可以说 cargo Lambda init，它会给你一个指导性的体验，它会告诉你一些事情，例如，你想做一个 HTTP Lambda 吗？如果你这样做，你想支持什么样的事件？

如果它不是 HTTP Lambda，你还想支持哪些其他事件？是 SQS 吗？我不知道，SNS，无论是什么，你都可以从下拉列表中选择，它会创建所有你需要的代码，并提供示例供你从那里开始。它还会自动安装你需要的全部依赖项，包括运行时。我认为这是一个惊人的体验，因为你实际上不需要了解任何关于 Rust 和 Lambda 的知识。你只需要安装这个工具，运行一个命令，

然后你就可以直接部署一些东西了。当然，你可能想更改一些代码并进行调整以使其执行你想要执行的操作，但你不是从零开始，我想这对于大多数人来说将是一个更大的障碍。这个工具实际上做得更多。它不仅仅是做脚手架。它也做

本地测试，所以它运行一个本地环境，自动监视你的代码。所以如果你做了更改，它会重新编译你的代码，并具有这种模拟模式，你可以调用

它还可以为不同的目标构建。因此，无论你的操作系统和 CPU 架构如何，你都可以针对例如 Linux ARM，这对于 Lambda 通常是最便宜的。根据用例的不同，它甚至可能性能更好一些。这是另一个优势，因为你不需要担心如何正确编译它。只需运行构建，它就会为你完成魔法。

最后，另一件事是它与 SAM 集成得非常好。我认为对于 CDK 也有一个构造。对于 Terraform 也是如此，我认为 Anton Bank 的项目 Serverless TF 在这方面有一些东西可以使其易于与我们一起使用。我还没有尝试过，但这就是我听到的。

所以基本上，当涉及到发布时，你可以运行 cargo lambda，我认为它被称为 deploy，cargo lambda deploy，它会为你构建和部署。但是该部署没有适当的基础设施即代码设置。所以通常你不想使用它，但你想使用与 SAM 或 CDK 的集成。在幕后，它将使用 cargo lambda 来进行构建，但是其余基础设施的发布和部署，将所有内容连接在一起，你

按正确的顺序，尊重所有依赖项是通过基础设施即代码完成的。我认为当你将使用 Cargo Lambda 与 SAM 或 CDK 结合使用时，你就会获得惊人的体验。就像你只需要知道一点 Rust easy mode，然后你就会获得很多好处。也许我夸大了，但这就是我现在看到的。

好的，明白了。所以使用 SAM 将你的函数与其他所有内容连接起来，因为函数只是你整体架构的一部分。然后使用 Cargo Lambda 来构建和初始化依赖项以及生成代码示例等。好的。实际上，为了完成该语句，SAM 与 Cargo Lambda 直接集成，所以你不需要单独执行它

两个步骤。你只需要告诉 SAM，这个 Lambda 是一个 Rust Lambda，所以用 Cargo Lambda 编译它。因此，你需要向你的函数定义添加一些元数据。然后你只需执行你使用 SAM 通常执行的操作。你甚至可以执行本地 HTTP 网关

它将构建并运行你的 Lambda，并允许你使用在本地工作的 HTTP 端点对其进行测试。因此，你获得了两全其美的好处，而无需过多担心幕后是如何进行构建的。

好的，明白了，明白了。好的，这听起来比我想象的要好得多。那么横切关注点呢？管道中会有用于 Rust 的 MIDI 吗？是的，这实际上是一个非常好的问题。这是我思考过一段时间的事情。为了澄清这一点，我认为 MIDI 实际上是两件事结合在一起。所以中间件引擎就是我们所说的核心，实际上包被称为核心。

这是一个组件。这是启用生态系统所需的主要内容。但是，也存在一个官方中间件生态系统，这些中间件解决了我们所看到的或多或少是人们最常见的关注点。所以在 Rust 中，存在这个概念……

他们称之为服务特性，它来自 Tokyo 生态系统。Tokyo 是 Rust 中存在的异步等待运行时。无需过多详细介绍，基本上他们所做的是定义一个接口，它基本上代表了最抽象意义上的请求响应模式。有了这个，如果你实现了它，你就会自动拥有一个由库内置的中间件引擎。

所以当他们构建 Lambda 运行时时，他们会利用所有这些生态系统。所以你的处理程序函数已经利用了这个接口。所以有一个你可以使用的自动中间件引擎。你实际上可以使用甚至在 Lambda 之外存在的中间件。所以如果你有一个问题，比如，

我不知道，以某种方式处理某些输入。而这个关注点在容器化应用程序（如常规 Web 服务器）中也可能相同。你可以在 Lambda 和该特定应用程序中使用相同的中间件，因为它属于生态系统的一部分，而不是 Lambda 特定的东西。

现在，当然，对于 Lambda，你可能有不同类型的事件。它可能并不总是有效。使用你在其他地方拥有的所有中间件可能并不总是合乎逻辑。但一般来说，它实际上是同一个库。因此，你甚至可以在不同的上下文中重用大量代码。我认为缺少的是我们在 MIDI 中拥有的这个丰富的生态系统在 Rust 中还不存在。所以也许在那里，有空间围绕它构建一个项目。

这不是我现在正在积极从事的事情，但我认为如果越来越多的人使用 Rust 构建 Lambda，它可能会变得越来越需要，仅仅是因为这些关注点将变得如此普遍，以至于最终有人会为此构建 Middlewell 特定的用例。好的，是的，因为我想象这对 Easy Mode Rust Lambda 用户来说将是一个非常有用的难题。

是的，是的，当然。好的，这说得通。我想我最后还想问你的是，好吧，你显然是 80% 英雄计划的一部分，但你也是 80% Microsoft MVP 计划的一部分。而且我认为你已经做了很多年了，因为你参与了 .NET 社区，有时你还会继续参与 TypeScript 等等。所以任何……

我的意思是，对于那些人来说，我想我们大多数人都参与其中一个或另一个计划，很少有人同时参与这两个计划。你有什么可以告诉我们这两个计划在某种程度上如何比较，或者也许是额外津贴，或者也许是你从一个或另一个计划中喜欢的东西吗？是的，这是一个非常好的问题。我不知道是否容易比较两者，因为它们非常不同。

仅仅是因为我认为 AWS 中的英雄计划有点神秘。你如何成为英雄？真的有一个正式的流程。当然，当宣布新的英雄时，每个人都同意这些人应该成为英雄。所以，

有一些标准是由你对社区的贡献、知识共享、项目等等决定的。每个英雄，你绝对可以认出他们的一些东西。我并不是说这不公平。这绝对是公平的。只是它并不总是很清楚。如果你想成为英雄，我需要做什么才能成为英雄？我认为对此没有简单的答案。

而在 Microsoft MVP 计划中，他们有一个更有条理的系统，你基本上需要由某人提名，但你基本上可以访问一个表单系统，你必须在其中解释你在特定领域所做的所有活动。然后 Microsoft 将根据这些内容对你进行评估。所以这个过程更直接一些。这也许是我在这两个计划之间看到的区别之一。

另一件事是 Microsoft 的一个，当然有不同的领域，大多数领域都专门针对 Microsoft 产品。我所参与的一个更通用的领域，它认可对科技界做出贡献的人。所以他们更受认可，例如开源活动、公开演讲、文章、知识共享等等。

有趣的是，每年他们都必须更新这个头衔，他们会再次问你，你能否填写这个表格，你必须在其中提到你认为你今年的主要贡献是什么？

大多数时候我都在那里放与 AWS 相关的东西，他们仍然接受。所以我不知道这将来是否会改变，但我认为我的大部分重点仍然是 AWS 而不是与 Microsoft 相关的东西。这似乎对这个我参与的特定类型的 MVP 计划来说是可以的。所以是的，

我不知道，也许这可以让你了解这两个计划是如何相互比较的，但是是的，它们在许多方面往往有所不同。

好的。我想 EDBS 也有社区建设者计划。我想在流程方面，这在自我报告方面更接近于此。但我认为他们也为英雄计划引入了这种续约流程的一些元素。每两年，他们都会问你是否还想参与。

好的，但是认可方面呢？你是否认为 Microsoft MVP 计划，他们做得那么多，我想英雄计划的一件好事是他们会让你与团队互动，他们会让你访问不同类型的服务预览，他们会鼓励英雄们对团队正在开发的新功能提供反馈。你在 MVP 计划中获得类似的东西吗？

是的，实际上经常会发生类似的事情。你几乎每周都会被邀请参加整个 Microsoft 组织内部不同团队的不同会议，他们认为你可能会感兴趣。你可能会收到邀请。公平地说，他们很少适用于我，因为他们往往与 Azure 团队有关。

我很少使用或根本不使用的服务。所以我认为我个人在 AWS 中发现的价值更多，因为我做的 AWS 比 Azure 多得多，而 Azure 我只是偶尔使用。所以也许它并不完全适用于我，但我认为如果有人更专注于 Azure，那么拥有这种体验将非常有价值，你可以在其中看到新功能的预览，与团队交谈，

与你在 AWS 计划中成为英雄而获得的非常相似。好的，明白了。好的，这说得通。是的，所以我认为这就是我所拥有的一切。Luciano，在我们离开之前，你还想分享其他什么吗？

让我看看。我有一些笔记。我认为我们涵盖了我想要分享的大部分内容。所以非常感谢你给我这个机会。我只想提一下，对我来说，我们有两个赞助，一个是来自我工作的公司 Fortirium，另一个来自 AWS 本身，顺便说一句，收到 AWS 对开源项目的赞助真是太棒了。这并不常见。所以我对此感到惊讶。

但是现在赞助基本上直接给了 Will，他无论如何都在做 99% 的工作。所以这是公平的。我会做的是，如果你不介意的话，建议想要支持或公司想要支持该项目的人考虑向 Will 捐款，支持他作为开源贡献者，因为基本上他 99% 的开源时间都花在了 MIDI 上。所以你实际上是在支持 MIDI。

好的，明白了。那么在这种情况下，人们如何赞助呢？他们只是去……是你在 GitHub 上赞助的东西还是你需要访问的不同链接？是的，我们在文档中有一个链接，但公平地说，根据金额的不同，去 GitHub 赞助是否有意义。我认为超过一定金额，如果你想进行一次性大额付款而不是每月定期付款，GitHub 赞助不会使其过于容易。

所以我们过去有过不同的经验，但如果你只是访问该链接并与 Will 互动，我相信你可以弄清楚什么是最佳解决方案。现在，如果你只想每月捐赠少量金额，GitHub 赞助可能是最简单的。你只需点击几下即可轻松完成。好的。我认为我找到了 GitHub 赞助的链接。它是 repo 的一部分，并且……

是的，好的。如果你想进行一次赞助付款，我会在下面的节目说明中添加该链接，以便你可以查看。当然，还会有指向 MIDI 项目本身的链接，以及 Luciano 的书籍和 Alibis Bytes 的链接。好的，我认为这就是我所拥有的一切。Luciano，再次感谢你抽出时间与我们交谈。是的，我希望很快见到你，我想。

是的，同样。非常感谢你邀请我。这太棒了。是的，你以后必须把支票寄给我，用于所有这些链接。不用担心。放松一下，伙计们。下次见。好的，再见。感谢 HookDeck 对本集的支持。你可以了解有关 HookDeck 如何改善构建事件驱动架构的开发人员体验的更多信息。访问 hookdeck.com/theburningmonk。

这就是另一集 Real World Serverless 的全部内容。要访问节目说明，请访问 realworldserverless.com。如果你想学习如何构建可投入生产的无服务器应用程序，请查看我在 productionreadyserverless.com 上即将推出的课程。下次见。