#101: Faster serverless APIs with Brian LeRoux
01:00:19 Share

在本期节目中，我采访了 Brian LeRoux，他是 begin.com 的联合创始人，也是 Architect 框架的创建者。Brian 还是 AWS Serverless Hero，目前正在开发 enhance.dev，这是一个 HTML 优先的全栈 Web 框架。在这次广泛的谈话中，我们讨论了：Architect 框架；Lambda 函数与单一用途函数；构建更快的 AWS SDK (aws-lite)；Web 组件；无函数；WASM；基于代码的框架（如 Ampt）；本期节目的链接：AWS Lite SDK；Architect 框架；Begin；Enhance 框架；LocalStack 集；LLRT 集；Jeremy Daly 的 Ampt；我的无服务器测试课程；主题曲：Kevin MacLeod 的 Cheery Monday；链接：https://incompetech.filmmusic.io/song/3495-cheery-monday；许可证：http://creativecommons.org/licenses/by/4.0</context> <raw_text>0 嗨，欢迎回到另一期《真实世界的无服务器》节目。今天，我和 Brian LaRue 进行了交谈，他是最早采用无服务器技术的开发者之一。嘿，Brian，欢迎来到节目。嘿，很高兴来到这里。你可能是最早采用无服务器技术的开发者之一。我晚了一点。是的，我记得你最近在阿姆斯特丹的时候，我们一起喝咖啡，你当时说，大约九年前，你与

是最近离开 Lambda 团队的 AJ 聊天，他们告诉你，你领先其他人十年，你说，这件事不会花那么长时间。九年后，我们在这里。是的，是的。我记得在 2019 年，我在 Serverless Conf 上，Simon Wardley 说，是的，这项技术成为主流还需要数年时间。我说，哦，我希望不是这样。但在那时，我们已经过去好几年了。

我在 2015 年旧金山峰会上 API Gateway 发布时开始对无服务器技术感兴趣。我看到他们演示了一个 HTTP 调用，返回一个 Lambda 负载，就像一个灯泡亮了。我想，哦，我再也不需要使用 Beanstalk 了。我想，

对我来说这是一个启示性的时刻。我认为每个人都一样，我只是假设，你知道，人们会想要编写代码并外包，呃，扩展。我在这方面大错特错了。他们显然想要编写，处理所有基础设施问题。尽管我认为现在情况正在发生变化，因为世界变得越来越以前端为中心，而且，呃，

运行工作负载的教条正在消失，除非你是 DHH。

是的，我们稍后再谈谈 DHH。但我认为你刚才说的，好吧，2019 年，Simon Waterley 说我们还需要数年时间。不幸的是，他并没有错。但 Simon Waterley 也可能是第一个真正开始做无服务器技术的人，因为他的公司，我认为是 2014 年，他们……

他们不应该成为一个完整的无服务器计算业务，但他们有一个顿悟的时刻，“哦，是的，一定有人想使用它，因为我们将处理所有基础设施，你只需编写你自己的代码。”

但它并没有流行起来。没有人想要它。我认为那是 2014 年还是更早？我记得他当时在谈论它。他的东西比那更早。有一种说法很有趣，我们没有这样做，因为我们认为这很难。我们这样做是因为我们认为这很容易。我认为基础设施就是这样，你知道，这能有多难？而且

事实证明这真的很困难，但很容易低估。所以我认为其中有一点。还有，这不像移动设备出现时那样，我们有很多

你知道，理由来采用这种新的，这种新的形式因素和这种新的计算方式。我认为对于 Lambda 来说，这在许多方面都是一个渐进式的升级。部署服务器存在很大的惯性。而且还有很多关于部署服务器的先例。所以，嗯，

让这些庞然大物，这些大型公司翩翩起舞需要一段时间，他们仍在适应它。但我仍然坚信，将来，大多数工作负载将由基础设施提供商管理，这将是一个异常情况，或者可能是极端规模下的成本问题。如果你像谷歌或 Facebook 那样规模庞大，那么也许重新安装服务器是有意义的，但是

对于绝大多数企业来说，这真的没有任何意义。是的，绝对的。我认为，就像你说的那样，过去几年的动力主要来自前端。我认为这可能是由 Vercel 推动，以及其定位和目标，非常具体地针对前端开发人员，他们

没有那种先例，但更重要的是，与管理机器没有那种先前的身份认同，与 DevOps 的关联，甚至可能是你的职位名称与你管理机器有关。如果你的业务不再管理机器，那么你的工作就可能面临风险。

所以我认为将目标市场定位在那里是一个非常聪明的举动。但说到针对前端开发人员，你的公司也在进入这个特定的领域。告诉我们一些关于这方面的信息，因为我认为很多人实际上并没有使用过它。

是的。所以，我的公司名为 begin.com。我们是一个基于名为 Architect 的开源框架的无服务器部署平台，它生成基于 SAM 的 CloudFormation。是的，这是一个非常容易上手的方法。你不需要信用卡。大约五分钟就能建立你的第一个工作负载，而且

之后部署只需几秒钟。我们最初认为，就像我说的那样，大多数后端开发人员会想要这种即时部署和 CloudFormation 类型部署的确定性。但我们发现，Vercel 绝对做到了这一点，前端开发人员市场正在增长，并且是新的云采用者的最大群体。他们不关心服务器。他们关心的是完成工作。所以……

我们不认为未来属于 React。我们认为它在 12 年前可能真的很好，但如今它有点过时了，它正试图通过反向数学方法来实现更现代的性能技术，并且它正在失败。它很慢，说出来也没关系。你可以自己运行开发工具并检查任何主要网站，你会发现它的性能非常差。主要原因是 React 做了很多浏览器已经做的事情。

因此，你加载了大量不需要加载的代码。所以在后端，我们称之为“无差异的繁重工作”。这是一个很好的说法，指的是你不需要做的工作。

浏览器内置了模块和组件系统。因此，我们最近一直在开发一个名为 Enhance 的项目。你可以在 enhance.dev 上看到它。它是一个以前端为中心的方法，使用 Web 组件作为主要基元来进行无服务器开发。这是一种有趣的工作方式。我认为未来可能会

更多基于标准的代码和 Web 组件，而不是用专有方言编写代码并转换成 JavaScript，然后执行该 JavaScript 来获取 HTML，你可以直接编写 HTML，它运行得非常好。是的，这就是我们的方法。Enhance 是基于我们的开源工作 Architect 构建的，Architect 是我们的 CloudFormation 生成工具。

我之前看过 Architect，它非常有趣。它比该领域的其他一些框架更具有主见。我想你已经有了所有这些用于连接 DynamoDB 表的快捷方式等等。如果你只想构建一些东西，并且你正在做的事情与框架的观点一致，

与 Serverless Framework 和 SAM 相比，你可以更快地完成工作，

甚至像 Sam Williams（他之前来过这个播客）一样，他今天刚刚发布了一篇文章，讲述了他如何从 Serverless 迁移到 CDK，他尝试移植的第一个项目，在 Serverless Framework 中大约有 10 行代码，在 CDK 中变成了大约 200 行代码，因为它只是更多，你知道，它不太具有主见，所以有很多

你必须自己编写的东西。即使你创建了可重用的构造，第一次你仍然必须自己这样做。你必须做出很多决定，而 10 行 Serverless Framework 代码实际上在 Architect 中可能只有 3 行，因为如果你正在做的事情非常符合，好吧，这就是我们开箱即用的东西，你可以非常快速地配置的东西。我认为这是……是的，继续说。

哦，我要说的是，是的，这很有趣，因为我永远不会做出那种武断的主张。我认为如果我们要列出这些观点，我们可能会发现它们只是我们都同意的事情。例如，我们的一个观点是，你应该有很多小型函数，因为它们冷启动速度更快，它们将具有更好的单一职责，它们更容易维护和重构以及随着时间的推移进行替换，更容易锁定到最小权限等等。

所以它是有主见的，但它们是很好的实践。它们主要源自亚马逊的良好架构框架。Architect 的另一个角度以及它与众不同的地方在于，它非常适合我正在构建的 Web 应用程序。这有点像，

如果你正在构建日志处理数据管道之类的东西，那么 Architect 比它更好的工具。但如果你正在构建一个与 DynamoDB 通信的网站，Architect 将使它变得非常非常快速和容易。这就是我们的，

我们的主要用例以及我们最关心的方面。Architect 的技巧很有趣。它非常快，而且非常小。我们实现这一点的方法是只选择我们使用的服务。我认为总共我们使用了 12 或 14 项服务，数量不多。它们都是无服务器服务。它们都有慷慨的免费套餐。而且

因为我们进行了子集选择，所以我们能够使其变得非常快速、紧凑和轻量级。多年来，我们能够在本地模拟所有内容，因此它可以在本地运行。这有时是有争议的，所以如果你不喜欢本地开发，不用担心，你不必使用它。如果你想要它，它就在那里。如果你想要它，它非常好。这是一种更快的工作方式，你的迭代速度会更快。

但我们完全建议部署到暂存堆栈和生产堆栈。如果你想在那里进行测试，你可以这样做。但总的来说，它最终是一个转换器。如果你访问 arc.code/playground，你会看到这两个窗格。左侧窗格是 Architect 语法。右侧窗格是生成的 CloudFormation。Architect 的代码通常比生成的 CloudFormation 少 80 倍。

然后是生成的 CloudFormation。你也可以随时深入研究 CloudFormation。所以就像 CDK 或其他任何东西一样，你可以以任何你想要的方式修改生成的 CloudFormation。因此，亚马逊可以使用 CloudFormation 做的任何事情，你都可以使用 Architect 来做。但是对于围绕构建 Web 应用程序的大多数用例来说，你永远都不需要看到任何 CloudFormation，而且你可能也不想看到。它确实变得非常冗长。

是的，特别是对于 API Gateway 之类的东西，你必须配置的不同层级的东西。是的，但其中蕴含着巨大的力量。因此，我们不想将其完全隐藏在一个黑盒中。如果你确实需要深入研究，而且你可能在更复杂的应用程序中会这样做，你将需要访问这些东西。但是的，这很有趣，因为我认为 Sam……

在某种程度上，Serverless Framework 都希望成为你可以手动编写的抽象，但我认为这是不可能的。我认为没有一个活着的人能够通过只手动编写 CloudFormation 来端到端地构建应用程序。我认为你必须整天复制粘贴、测试和投掷飞镖。而使用 Architect，你绝对可以在几秒钟内编写一个 arc 文件并生成 CloudFormation，它将格式良好并可以快速部署。

我认为 Ben Cahill 非常喜欢直接使用 CloudFormation。我从未参与过他参与的项目。所以我不知道他的 CloudFormation 模板有多大。但 Ben 是一位非常聪明的人。所以也许他能够让它工作。是的。我的意思是，我相信亚马逊正在为此开发工具。我的意思是，这就是 CDK 的吸引力，你可以获得，你知道，自动完成，你可以获得，

你知道，所有命令式语言的功能，都在你的指尖。所以它更容易推理，而 CloudFormation 可能非常不宽容。它非常结构化。它非常声明式，而且非常冗长，因为你可以做很多事情。所以这只是针对同一件事的不同方法。CDK 为你提供了命令式语言的所有功能，但也提供了所有陷阱。我可能会看到太多陷阱，以至于我无法真正喜欢 CDK。是的。

它也不适合我。是的，我不。所以对我来说，就我个人而言，这就像有很多通往山顶的路。所以当人们观看这个节目时，我希望你们明白，没有错误的方法。就像，你知道，为云构建。这将很有趣。对我来说，基础设施即代码的全部目的是拥有确定性的可重复部署。我想确保我今天构建的东西与三天后使用不同的计算机，甚至不同的团队构建的东西相同。所以我们通过签入带有我们代码的工件来实现这一点。它非常类似于一个打包的 JSON 文件，我们有版本号，并且我们知道该代码的该版本将与这段代码一起工作。所以……

想象一下，如果在 Node.js 中，他们决定拥有 package.js 文件，并且它是用于依赖项解析的命令式代码。它永远不会工作。它会崩溃。package.json 工作的全部原因是因为它是声明式的，而且非常明确。如果你让任何人编写任何内容，那么它将在规模上崩溃。它不会是确定性的。它将是

你知道，很难知道它是否会在一天到下一天工作。所以对我来说，命令式代码，即使它生成 CloudFormation，特别是如果它是转换的命令式代码，那就像不会那么稳定或确定性。这有点违背了基础设施即代码作为可靠和可重复的全部目的。所以……

它不适合我。我完全承认这是一种很好的入门方法，并且可以快速前进。一些公司正在寻找方法让它为他们工作。这很好。我不是说他们错了，或者他们做错了什么，但我认为声明式代码和命令式代码之间的权衡非常非常糟糕。

你之前还提到了单一用途函数与 LambdaLifts 之间的权衡。我不久前与 Hito 进行了交谈。他显然在无服务器的整个架构框架中发挥了很大的作用。他实际上告诉我，他已经改变了立场。他现在更倾向于 LambdaLift。

我也看到很多人现在也在推广 LambdaLift。尽管我仍然站在单一用途函数一边，但我认为我们过去提出的许多论点，例如在安全性方面更好的粒度，如果都是内部流程，我认为很多人可能正确地说，它不像外部阶段的安全性那么重要，例如你的 Cognito 和你的 API 端点。

因此，即使你在应用特权方面有点宽松，所以你有一个 LambdaLift，每个端点都有更多权限，但你的函数本身仍然遵循这个特权，这可能没问题。我的意思是，除非你在所有权限上都使用通配符。

我认为有些人还指出，许多 API 可能有五个端点，但它们具有相同的依赖项。因此，就实际的成本时间而言，你和我可能都见过例子。我见过一个客户的例子，他们有一个 API，一个 React 服务渲染端点，然后是一堆 REST 端点，你的 REST 端点非常慢，仅仅是因为你必须加载 React

同样。对于这个例子来说，是的，单一用途函数不会有同样的性能问题。但与此同时，许多 API 确实只是与 DynamoDB 通信。因此，同一个 API 中的所有 Lambda 函数都具有相同的依赖项。所以无论是 LambdaLift——我认为这是关键。如果它们共享很多代码，也许它们可以……另一件事是，我们发现过去几年中，事情变得……

非常快。例如，我们现在有主动初始化，我们有更快的运行时。亚马逊做了很多工作来使 AWS Lambda 变得更快。所以在 2015 年，如果你的函数大于 5 MB，它的冷启动时间将超过亚秒级。这非常糟糕。如今，AJ 正在测量大约 50 MB 的内容。

所以，我的意思是，你可以在那里获得很多应用程序，但是你知道，例如，我不会将我的 React 应用程序放在我的 SQS 队列处理程序中。这根本没有意义，因为代码在那里没有共享，但是我的所有 get 处理程序都使用我的 React 代码。所以是的，这是有意义的。它们可能应该以某种形式捆绑在一起。所以，我认为这是，我绝对正在放松它。例如，我们现在正在使用更胖的函数。嗯，

是的，当然。是的，我也是。我也在放松我对这方面的立场。但我仍然认为，我们传统上一直在考虑的论点可能并没有，好吧，至少现在不太相关了。但我认为从操作方面来看，我仍然发现单一用途函数会给你一种更容易的方式来在出现问题时得到通知。

因为你每个函数都有一个警报，而不是一个警报。然后是调试。然后通过找出哪个代码路径有问题来进行调试。是一切吗？是一条特定的路径吗？所以拥有这个……重构是另一个。没错，重构。还有优化你的 CPU 使用率。我不久前正在帮助一个客户优化他们的函数，但很快意识到，好吧，

“等等，我们不能这样做，因为这是一个 LambdaLift，我们有四个不同的端点，性能配置文件略有不同。我们不能只是尝试优化并为所有端点找到合适的内存设置。”所以有一些事情，从操作方面来看，拥有多个函数实际上使警报、监控以及检查日志和找出问题变得容易得多。

但是我们认为很重要的事情现在在性能和安全性方面可能不那么重要了。是的，我认为这是非常正确的。这就是云的奇妙之处。我的意思是，它一直在变得更好。随着时间的推移，我们获得了这些免费升级。所以你必须不断地衡量和挑战你的假设，我认为。而且这不是……

我认为一些软件社区真的非常关注他们的身份认同等等。拥有观点并改变它是可以的。事实上，这可能意味着智力的标志。如果你能够根据更多信息来改变你的观点，这是一件好事。所以就像，是的，我认为有很多情况下，一个更胖的函数现在是可以的。我不，我不会，

就我个人而言，我不认为从那里开始是一个好主意。我认为你应该尝试构建离散的、独立的、单一职责的筒仓，然后从那里向后工作。但是是的，共享代码可能对我来说是一个很大的问题。如果所有内容都共享同一个库，那么可能这只是一个函数，它有不同的事件源。所以这是一个很好的查看方法。

是的，但我认为使用一些现有 Web 框架的单个 LambdaLifts 使测试变得容易得多。至少更容易将现有的测试方法应用于无服务器。我认为这是很多人在第一次接触无服务器时都会遇到的问题。

当他们第一次接触无服务器时，只是如何测试我的函数？是的。测试云。我认为这就是你谈论本地测试和本地模拟的地方。同样，这并不是关于本地模拟或本地测试本身，因为我喜欢它。我想要那个快速的反馈循环。我遇到的问题是，工具不可用。LocalStack 可能是那里的主要参与者。而且很长时间以来。LocalStack 非常好。是的。

是的，是的，是的，是的，但四年前、五年前，这仍然非常……这很难，而且我们做了相当多的模拟，我们的测试将在本地内存中运行，这可以理解地让人们感到紧张，他们，你知道，人们会说，哦，我不知道，这并不是在测试真实的东西，亚马逊的

如果他们有什么名声的话，那就是稳定性的名声，也许是过分稳定。他们几乎从不更改他们的 API。他们只是不断添加更多 API。而且，嗯，

你知道，所以你可以相当安全地模拟它们并摆脱困境。但是，你知道，偶尔你确实会被烧伤。这是一件需要注意的事情。我认为对我来说，教训是使用本地测试来获得快速的反馈循环，但不要将其用作不进行暂存或生产测试的借口。就像你必须两者都做。

你可以通过在本地针对模拟或模拟器（如 Architect Sandbox）进行工作来快速上手。但在某个时候，你将需要针对真实环境验证该工作负载。你可能也希望在工作负载进入生产环境时验证它。因为没有办法知道，直到你到达那里，才知道真正的限制是什么，以及围绕这些限制的真正挑战是什么。

是的，我要说几年前当我尝试使用 LocalStack 时，它非常粗糙。它是在 1.0 之前或 1.0 之后。所以有很多稳定性问题。与真实环境有很多不同的行为。它的失败方式略有不同。你会得到误报。所以它只是……

向其他人推荐这样做真的很难。因此，我构建了整个实践，使用我称之为远程代码测试的方法。所以我在本地运行我的代码，与已部署的资源进行通信，并且我使用临时或短暂的环境，以便创建新环境既快速又容易，并且拆除环境也同样快速，以弥补

像稳定的或良好的本地模拟。但我认为我上周邀请了 Baltimore Hummer，他是 LocalStack 的 CTO。是的，就像，你知道，LocalStack 2.0 非常非常令人印象深刻。他们在 3.0 版本上也做了一些非常好的事情。这是一个非常雄心勃勃的项目。亚马逊应该构建这个。

它是由奥地利的几个人完成的，这令人难以置信。但它确实很好。他们依赖于我们正在使用的相同原则，即亚马逊将保持稳定。但他们正在做所有事情。而我们模拟 API Gateway、Lambda、Dynamo、S3，

仅此而已。对我们来说，这是一个非常轻量级的表面区域，但对于他们正在做的事情来说，这令人难以置信。我的意思是，我不知道现在有多少服务，但有数百个。是的。

他们拥有大部分服务。你专注于构建 Web API。他们更广泛地关注，所以是无服务器工作负载。是的。所以任务略有不同。他们现在实际上正在向其他提供商扩展。所以他们现在也为 Snowflake 提供本地模拟。

他们在 3.0 版本中开始进行一些故障注入，因此你可以模拟 DynamoDB 节流，这是我在 Vox 中经常使用的东西，因为它很难模拟真实情况。所以他们实际上正在扩展并涵盖越来越多的用例，而不仅仅是越来越多的服务。但是是的，我对他们正在做的事情印象非常深刻。

他们也做了一些非常有趣的事情。在使用之前，我认为他们使用的是 DynamoDB local 进行模拟。但是 DynamoDB local，我认为该库的大小达到了大约 140 MB 或类似的荒谬大小。很大。是的，有点太大了。所以他们基本上重写了整个东西，这将其缩小到，我认为，几，也许是几千字节或类似的东西。

当他告诉我这件事时，它实际上让我想起了你使用 AWS Lite 做的事情。你告诉我，是什么，内部 AWS v4 签名模块或类似的东西，它有数万行代码。然后你重写了它，它只有，我不知道，几百行代码或类似的东西。

是的，我们有一些这样的例子。最大的差异，所以对每个人来说，我们参与了 Architect 项目，我们正在开发一个 AWS SDK 替换项目。

现在所有听众都认为我疯了，而且可能是对的。那么，我们为什么要这样做呢？好吧，AWS SDK v2 速度不是很快，它主要用于 Node.js，但它实际上可以为所有内容构建。你可以在 Dino 中使用它，你可以在浏览器中使用它，你可以在 CommonJS 中使用它，你可以在 ES 模块中使用它。所以它涵盖了很多空间。

在过去几年中，我认为是在 2021 年，亚马逊宣布了 v3，这是一个用 TypeScript 重写的版本。他们开始鼓励人们迁移。去年，他们基本上表示他们将弃用 v2，并将强制升级到 v3。

不幸的是，V3 的性能倒退相当严重。我们发现它比我们的客户端 AWS Lite 慢五倍以上。顺便说一句，这些数字并非我编造的。如果您访问 awslight.org，可以在主页上看到我们的性能基准测试代码。我们正在与亚马逊合作处理这些问题，以确保我们自己诚实。我认为数据每三天发布一次。

基于最新的 SDK 与我们的东西。而且，嗯，这主要由我的联合创始人 Ryan Block 编写，甚至不只是主要，我认为大约 99.99% 是由 Ryan 编写的，我们其他人一直在测试和做插件。而且，嗯，

是的，我们采取了不同的方法。亚马逊正在使用一种名为 Smithy 的技术来生成他们的 SDK。他们不仅是机器生成的，而且是为许多不同的目标机器生成的，他们还机器生成大量的测试代码和大量的文档代码和类型。

所有这些都被发送到 NPM。因此，当您运行 NPM install 时，您的磁盘上会获得相当大量的代码，这些代码必须初始化才能进行 API 调用。我们承担不起超过一秒的冷启动时间。许多 V3 的东西都会强制执行此操作，尤其是在您使用 DynamoDB 的情况下。对我们来说，面向用户的 Lambda 函数应该在亚秒级内完成。

理想情况下，它应该在 200 毫秒或更短的时间内完成。这就是我们使用 AWS Lite 实现的目标。我们获得了更好的性能。那么我们是如何做到这一点的呢？我们手工编写了这些插件。我认为最引人注目的是 CloudFront。在底层，CloudFront 实际上是一个 XML API。关于亚马逊的有趣之处在于每个团队

人们可能知道这一点，但就像你听说过两个比萨团队一样，这实际上是真的。他们真的只是小型团队，这些团队之间不会互相交流。他们会做出自己的技术决策。因此，有些 API 是 JSON，有些是 XML，有些甚至两者都是，令人难以置信。因此，CloudFront，你可以对这些 API 进行碳定年，你几乎可以分辨出他们在底层使用了什么，但 CloudFront 很多是 XML，很多是嵌套的 XML。

我相信 Ryan 为我们在 AWS Lite 中的处理编写了一个递归 XML 解析器。大约有 150 行代码。而 AWS SDK 使用的 Smithy 生成的版本有 20,000 行代码。所以，不管你使用了多少捆绑技巧，这都没关系，

它只会更慢，因为它需要解析和评估更多的代码，并且需要占用磁盘空间。因此，AWS Lite 通过非常谨慎地处理来避免很多这种情况。与 Architect 类似，它之所以如此快速，是因为我们可以选择。我们不支持所有亚马逊服务。我们只支持专门用于无服务器的子集。我们不支持所有可能的……我们认为你不应该从浏览器中进行 AWS API 调用。

我们认为最好在后端完成。您可能不想将您的服务令牌共享给客户端。因此，我们不是为浏览器构建的，而是为 Node.js 构建的。因此，我们节省了大量空间，因为我们不需要担心在浏览器中填充 Node.js 的东西。因此，它是磁盘上的千字节与兆字节，加载速度快得多。

但这并不意味着它完美无缺。它有权衡取舍。如果您想使用它与 EC2 通信，则必须进行原始 API 调用，因为我们尚未为 EC2 构建任何插件，而且我们可能也不会构建。是的。

是的，我想对于像 AWS 这样规模的公司来说，他们没有为每个 SDK 和语言配备专门的团队，这有点令人惊讶。当数万名开发人员都在使用它们，而且每个人都在为这种性能损失买单时，他们竟然使用像 Smithy 这样的工具来自动生成 SDK 客户端，这太疯狂了。

是的，我，我感觉，好吧，我认为现在我们已经有一些基准测试，每个人都可以看到并从中学习，他们有一些非常明确的目标，希望，你知道，用泥灰填补漏洞，击败我们，向我们展示如何做到这一点。这，这，

现实情况是，他们的任务比我们多得多。他们担心各种运行时。他们担心各种我们根本不在乎的服务。所以从他们的角度来看，这是一个更棘手的问题。我同意。他们应该为每个 SDK 配备专门的人员。我的意思是，看起来他们很快甚至可能会有自己的 JavaScript 运行时，即 LLRT。所以……

也许这是故事的一部分。我不知道。嗯，作为一名 JavaScript 开发人员，我很兴奋，因为这些对我来说只是玩具而已。所以，我，

对不止一件事情存在感到非常满意。现在，好吧，现在我的可怜的联合创始人 Ryan 已经经历了创建许多 AWS Lite 的东西的痛苦，嗯，它很稳定，很好。我们在内部和 architect 中使用它，它实际上加快了 architect 的速度。嗯，我们很高兴，我们不会破坏它，而且它永远不会变慢。所以，你知道，

在未来很长一段时间内它都会很好。是的，如果出现更好的东西，我们不会对这些东西过于珍视。我们一定会使用它。

是的，几周前我邀请了 David Richardson 来这里，他是 LRT 的创建者。是的，他谈到了你谈论的很多事情，好吧，你知道，有了 Lambda，我们有了这个非常特殊的、非常受限的执行环境，人们正在做某些事情。所以让我们不要构建一个能够执行所有其他事情的通用 JavaScript 运行时。让我们只构建一个，

非常适合这个受限环境的东西，在这个环境中，人们通常执行 I/O 密集型工作负载，调用 API，他们不会执行超级密集型工作。因此，与其使用 JIT，他们根本没有使用 JIT。

因此，这使他们能够更快地协同启动，使他们能够一次性交付，并且更轻量级。所以这正是你所说的，好吧，让我们不要为所有人构建。然后没有人会满意。让我们为一小部分与我们的用例更相关的用户构建，他们将

获得使用 Elipas Lite 的更好体验。希望 Elipas 将开始从中学到一些经验，并做一些类似于他们现在使用 LRT 所做的事情，以获得更侧重于语言的视角，也许，你知道，他们一直在谈论以客户为中心。这是他们应该为客户痴迷的事情，对吧？是的。

这很有趣，因为我认为我们也看到了，所以，我敢打赌，99% 的 architect 应用程序都在调用 DynamoDB 并返回一些 HTML。我敢打赌，99% 的应用程序都在这样做。而且越来越感觉，也许在中间运行任何东西实际上都不是一个很好的时间利用方式。当我查看直接无函数集成时，例如我们在 step functions 中看到的东西，例如，

有一个，有一个这样的世界，我们有逻辑列表。例如，我调用 Dynamo，也许我有一些助手可以将其转换为 HTML，但这只是一小段代码，它获取一些状态并对其进行转换。然后它直接传递回去。所以感觉我们几乎快到了，但是现在的编程技术水平仍然非常……我正在编写，我正在编写 JavaScript，我将去与数据库对话，然后我将

遍历行，然后以某种方式将其转换为 HTML。然后我将返回它，也许我还将返回一个缓存头。我觉得那里有很多重复的工作，这些工作可能会完全消失。但这对人们来说可能需要一段时间。如果人们认为无服务器很疯狂，他们会认为无函数更疯狂。所以，是的。

是的，我的意思是，我喜欢使用直接集成。当我编写 AppSync API 时，我确实使用 Lambda 函数。大多数情况下，它是 AppSync 直接连接到 DynamoDB。它更快，更便宜。是的。

但我不喜欢“无函数”这个术语，因为我觉得它把重点放在了错误的事情上。它关注的是删除 lambda 函数，而不是，如果你需要的话，就有一个函数。它更多的是关于什么最适合你的用例，而不是试图使其更具意识形态。所以我不是这个术语的忠实粉丝，但这种方法绝对是正确的。我认为这种方法绝对是正确的做法。

但是如果无服务器仍然很新，那么这将是遥不可及的。就像我们现在已经走得很远了，但确实感觉未来某个时候会发生一些事情。是的。

所以，就像你说的，你大多数客户都在做同样的事情，迭代他们从 DynamoDB 获取的一些数据，那么在 Begin 之上构建某种框架怎么样，基本上就是这样做？你提供一个小的转换函数来转换 DynamoDB 中的单个行，而这是你唯一需要交付的东西？

是的，也许吧。最近，我们一直在探索 Web Components 空间，我们团队中的一位开发人员 Ryan Bethel 做了一个实验，他将我们的 Web Components 渲染器放入了 Wasm 中。他正在使用 QuickJS，与 LLT 相同。

它有效。他已经成功地将其移植到每个后端运行时。所以我们在 Ruby、WordPress 和 Python 中运行它。因此，您可以编写一个 Web Components，例如 my element extends HTML element，

你可以在 WordPress 中运行它，它将返回它的 HTML，服务器端渲染。如果你想，那么你可以在客户端运行 custom element define 并进行水化，并拥有你的客户端 JavaScript。所以它就像同构的，但与后端无关。

我不知道这意味着什么。这是我第一次看到它。这甚至不是 React 可以做到的事情。就像你，你知道，你通常会在将你的 React 代码放在某个地方与 Ruby 或 Python 交谈之前执行构建步骤。但是现在我们有了 Wasm 直接执行 JavaScript 的能力。这就像，这是新的、未经探索的和有趣的。我们首先做的是手工编写 JavaScript 来生成 HTML。

但很快我们就意识到，哦，我们不能只将 JavaScript 和渲染 HTML 交给它。我们必须将 JavaScript 和状态交给它来渲染 HTML，例如我们需要循环遍历的 Dynamo 行或其他任何东西。所以有一些东西是这样的，就像将某种渲染器和一些状态交给 Wasm 运行时，然后返回一个 HTML 字符串。

我对这个很兴奋。这意味着你可以拥有一个适用于你的 WordPress 博客的设计系统，但你也可以在运行 Java 或 .NET 或其他任何东西的产品中使用它。所以 JavaScript 真的开始在任何地方运行并成为粘合层。也许这就是直接集成。我不知道。我不知道。我查看 EventBridge 和 AppSync，

以及 step functions 中发生的事情。那里有很多用例可以直接进行。没有涉及 JavaScript。我们实际上只是编写推理代码来创建 Glue。所以是的，这是一个令人兴奋的时代。为了退一步，Web Components，很多听众可能不是前端开发人员。什么是 Web Components，它与单页应用程序有何不同？

是的，当然。Web Components 是一种创建自定义元素的方法。因此，与其使用 form HTML 元素，您可以使用 my form，并且您可以使用您想要的任何 HTML 事件对其进行扩展。因此，Web Components 只是一种扩展内置浏览器元素的方法。

这令人兴奋，因为过去这通常是使用框架代码完成的，例如 React、Angular、Vue 或 Svelte。但是 React、Angular、Vue 或 Svelte 的问题在于，你正在为它们的抽象编写代码，然后你将其转换为 JavaScript。然后你执行该 JavaScript 来获取 HTML。而对于 Web Components，你扩展 HTML 元素。

然后它在浏览器中运行，你有一个新元素。就是这样。没有中间步骤。没有转换。没有运行。它只是内置的。所以它是一种平台原生方式来扩展 HTML。那么在这种情况下，你如何告诉浏览器如何处理我的元素呢？

是的，你可以进行一个名为注册表的调用，它被称为 custom element.define。你将一个类和你想运行的元素的名称传递给它。现在，有趣的是，这是一个渐进式增强步骤。它是可选的，如果你没有监听任何东西，你不需要运行它。一个很好的例子是，我的网站上可能有一个标题，它有很多链接。

该标题可能不需要客户端 JavaScript。因此，就像你可以将其转换为自定义元素，你可以拥有，你知道，my header，my header 可以有很多锚标签。嗯，它不需要客户端 JavaScript，所以你不需要运行任何其他东西。只需将其放入即可。它可以正常工作。而且，呃，你想要它的原因是它更具语义化。更容易限定你的样式。你可以选择 shadow DOM，如果你想的话，可以完全封装它，或者不封装。而且，嗯，

是的，它是浏览器的原生功能。在某种程度上，它听起来有点像 CloudFormation 提供商。是的，我可以看到一个分形世界，所有这些都是非常相似的东西。我们最近想到的一个更奇怪的想法是，如果我们有一些没有 UI 的自定义元素会怎么样？例如，如果你有一个名为 WebSocket 的自定义元素会怎么样？

其中一个属性是端点。因此，它处理了所有 WebSocket 的事情，但作为用户，你只需要知道编写 WebSocket 标签即可。也许我在这里过时了，但是 Flash、Flex 过去有很多这种组件，你可以在一种名为 MXML 的语言中编写数据组件。这实际上是一个非常相似的概念。

是的，真可惜。时间是一个扁平的圆圈。我们只是不断地回到同样的想法。是的，真可惜。Flash 实际上是一项相当不错的技术。它有一些问题，但是你可以用 Flash 做的事情比突然不能做的事情多得多，因为 Apple 扼杀了它。是的，那是一个戏剧性的时刻。这可能是迄今为止最大的行业地毯式轰炸，它毁掉了很多人职业生涯，

但这确实让很多顾问赚了很多钱，因为每个人都必须将他们的 Flash 应用程序重写为 iOS 和 Android 应用程序。这成了一件大事。这是一个关于 Web 的警示故事。你必须注意专有抽象。我有时认为 React 将会以艰难的方式吸取这个教训。

我还有一个问题，我想，是关于提供某种高级抽象。你之前谈到过，你可以为很多 Web Components 的工作做到这一点。但我们之前谈到过，我们如何才能将类似的东西引入 Begin。你有没有看过 Jeremy Daly 使用 AMPT 做的事情？

因为它感觉他们正在做的事情是试图提供更高级别的抽象，就……你知道，我看到了一些编写 AI 聊天机器人的例子，它提供了一些非常好的抽象，这样你就可以非常快速地完成你的工作，连接一些东西，只需说出你想要的东西。它会在后台创建所有资源。

是的，我认为这，如果我们要在一个圆圈中描绘无服务器人员共享的苦恼，那就是我们都生活在未来。Jeremy Daly 甚至可能在这个圆圈之外。他生活在遥远的未来。所以他和 Emrah 正在研究 Amped，其理念是代码即基础设施。至少我认为他们还在这么说。我不知道他们是否还在这么说，但其理念是，好吧，我们有代码即基础设施。这很好。它非常明确。你知道，如果我写，

你知道，我的 API 网关内容到 CloudFormation 中，我将获得一个 API 网关。他们的断言是我的代码已经包含了这些信息。所以如果我的代码中有一个 API，请帮我找出它并创建 API 网关。他们已经把这个做得相当远了。我认为他们正在探索的想法非常出色。你

你只需编写代码，然后将代码给他们，他们就会弄清楚它应该在 Lambda 中运行还是在 Fargate 中运行，它应该是一个 API 网关还是一个队列。他们会在入口处为你设置一个 DynamoDB 表。你只需要编写从表中读取和写入数据的代码即可。这真的很聪明。我认为从 0 到 60，这将可能是你进入云端的最快途径。在哪里……

而且我确信他们并不完全确定。例如，当你开始超出他们的抽象的界限时，你将需要直接使用 CloudFormation 或自己弄清楚，这将是一次相当冷酷的体验。所以我还不知道你如何推断一些更明确的事情。例如，如果我需要多个数据库表，我有一个名为 users 的表，然后我有一个名为，我不知道，

用户的地址，但我打错了字，我不小心写成了 users address。会发生什么？我会得到两个表吗？你会删除一个表吗？它会失败并警告我吗？这些都是非常重要的问题。另一个问题是，它如何知道要使用多少内存、磁盘和 CPU 以及所有这些？我们可以设置非常智能的默认值，但是随着应用程序的扩展，

它们几乎总是会超出其限制。因此，你几乎总是需要提出支持请求，例如，“我需要更多”，我需要更多 DNS 记录。所以，它如何处理弹性和理解明确的配额和限制是另一个挑战，但我认为这些挑战并非不可能克服。我真的很钦佩他们从无服务器框架中发展出这一点，他们正在尝试回答这些问题。我的意思是，这是最前沿的东西。是的，

这确实是 CloudFormation 方法的彻底反驳，CloudFormation 方法非常明确。

如果你有任何基础设施问题，CloudFormation，你将在该文档中获得这些信息。但是，该文档将会变得很大。它不会是一个人类可读的工件。理解和维护该工件将是一项多人工作。它是你的代码库的一部分。他们正在做的事情实际上是让所有这些都消失。你只需要专注于你的代码，我很喜欢这一点。我觉得这非常符合无服务器的精神。

是的，但我不知道，感觉这可能与人们习惯的东西差异太大。它可能很难销售，尤其是在你所说的那样，在某些情况下会发生很多不确定性。如果我打错了字，决定，你知道，不小心删除一行代码，这会删除我的数据库，而且，嗯，

诸如此类的事情，我认为这将很难说服至少是企业级的重要参与者尝试

而且，我想我对真正以用例为中心的方法略微怀疑，因为就像我说的那样，我的意思是，现在每个人都在构建聊天机器人。明天，没有人会构建聊天机器人。因此，所有这些使构建一件事情变得非常容易的抽象，它很快就变得，我想，无关紧要了。它几乎感觉太季节性了，太时尚了。是的。

所以这是过去的事情的挑战。我的意思是，多年来我们一直在 Begin 中为此而苦苦挣扎，有时我们想，哦，我们需要更注重前端。其他时候我们想，也许这并不重要。像我们或者哪个前端？当我第一次开始 Begin 时，有人明确告诉我 Gatsby 是一件重要的事情。人们现在可能不记得 Gatsby 了，因为它已经消失了数年。所以，我不知道，像真正抽象的地方在哪里。当，当橡胶碰到路面，你构建，你知道，你的应用程序，如果你的公司足够幸运能够成功，无论如何它都可能是一团糟。你将是某种无服务器，某种不是无服务器，你将在这里和那里的云中拥有一个服务，它将用胶带和愿望粘合在一起，而且，呃，

是的，但这也很有趣。我很钦佩他们对这种理念进行了真正的尝试，因为我认为他们在这种方式上非常独特。几乎所有其他人要么假装 AI 可以生成代码，要么非常明确。而我们的方法是明确但简洁的。所以也许我们是 Python 的……

在代码短语中，我们就像，你知道，尽可能多样化，尽可能少地编写，但要明确和声明式。而 CDK 的事情发生了，结果证明它非常冗长且脆弱。所以这是介于两者之间的东西。它不冗长，但很难知道它是否会在任何方向上扩展。但我敢打赌他们对此有很好的答案。我知道他不会删除我的数据库表。

但它会做什么？它会失败吗？就像，你知道，给我一个有意义的错误？就像，“嘿，我认为你的意思是 user addresses。所以我做了。”有无数种方法可以解决这个问题，还有无数种方法可能会出错。所以看看这一切将如何发展将会很有趣。

是的，还有 Wing Lang。是的。好吧，有 Dark Lang，有 Wing Lang。我认为 Dark Lang 刚刚转向了。我最近看到了这个公告。我现在忘记它说了什么，但我认为他们确实转向了。是的，就是这样。甚至都不知道，我猜。我的意思是，当然他们做了。可能。是的。

所以说到 Begin 和你，接下来是什么？因为我认为我们之前说过，你对 AWS Lite 非常满意。你不会做太多改变。那么你接下来会专注于 enhance 或 dev 吗？是的，我们真的……好吧，AWS Lite 仍在不断更新。

我们不久前重新设计了重试逻辑，并添加了新的抖动，我认为是，这很无聊，但这是你需要的。然后我觉得有一些，哦，更多凭证提供程序即将到来。所以我们没有做，我不记得 EC2 的名字了。我们真的只关心 Lambda。所以我们发布的是针对它的，但我们正在向 AWS Lite 添加更多凭证提供程序。

我觉得还有其他更新，但我记不起来了。Enhance 绝对是我们更大的重点。我们知道云中所有增长都将来自前端 Web 开发人员将其工作负载转移到亚马逊等地方。我们认为 Web Components 是他们应该着陆的正确位置。而且

是的，我们对这个 Wasm 东西很感兴趣。我们只是在过去几周才开始研究它。而且我有点，我觉得前端有点领先于自身，变得非常以 Node 为中心。与此同时，仍然有数百万开发人员使用 Python、PHP 和 Ruby，他们有点被抛在了后面。或者更糟糕的是，你有一个

预渲染或预构建你的应用程序，然后使用 API 与你的 Ruby 或其他任何东西进行通信，这是一种委婉的说法，你的 UI 上到处都是骨架屏幕和旋转器，这是一种糟糕的用户体验。因此，能够在这些环境中服务器端渲染 JavaScript Web Components 是一项非常引人注目的进步。所以我们将要，我们刚刚让我们的 WordPress 东西工作了

顺便说一句，这太疯狂了。这是一个全新的世界。我不知道 WordPress 的增长速度如此之快。但它有一个名为 Block Editor 的东西，以及它自己将组件组合到页面中的方式。所以我们现在完全支持 Enhance。我认为 Rails 是我们的下一个——Rails 或 Django。我们开始研究 Spring Framework，我不敢相信它仍然存在。

这让我有点过时了，但 Spring 有一个，它被称为 Thymeleaf，是它们的模板解决方案。所以我们正在考虑将 Enhance 插件到其中。因此，你原则上可以编写一个使用 Web Components 的设计系统，然后在所有这些不同的后端运行时中重用它。这非常引人注目。我认为 99% 的 AWS Lambda 用户都在运行 Node 或 Python。

我认为我所看到的几乎所有调查结果都非常非常偏向于 Python 和 JavaScript。是的。是的。所以我们肯定已经控制了 JavaScript。我们对此很满意。这很好，而且效果很好。所以 Python 也许也会排在前面。尽管我们正在研究这些其他服务器环境来运行 enhance，因为仍然有很多工作负载不是无服务器的。

实际上，随着 Lambda 的改进，我相信我们最终能够在 Lambda 函数中运行 WordPress。所以我不认为这是一个好主意，但是，为什么不呢？

是的，我的博客实际上运行在 WordPress 上，但它使用的是名为 Shifter 的东西。所以当你在编写时，他们会给你一个 WordPress 实例，就像一个 Docker 实例。当你完成后，你基本上会有一个像部署步骤这样的东西，它会将你的 WordPress 网站编译成静态。静态网站？是的。这很酷。

因此，您将获得WordPress附带的所有写作工具，但您却获得了静态网站的性能。所以是的，我们为您提供了一些最好的两全其美的方法，减去一些依赖于运行时API核心之类的插件。

是的，web组件中有一个名为Shadow DOM的原语，它听起来比实际情况酷得多。Shadow DOM的理念是它为您提供了一个文档中的文档，并且它是完全隔离的。因此，样式不会泄漏，代码也不会泄漏。当我构建应用程序时，我个人并没有很多这样的用例。

但是，当我看到所有这些运行着所有插件的WordPress安装时，我想，哦，这就是Shadow DOM的用途。因为它是狂野西部。您可以安装任何东西，它可以做任何事情。而且似乎人们确实是这样做的。是的，坏主意。无论如何，Shadow DOM将是一个很好的解决方案，因为您可以隔离这些部分。

好的，我想我已经说完了。非常感谢Brian抽出时间与我们交谈。在我们离开之前，您还有什么想告诉我们的吗？是的，请访问awslight.org，如果您发现任何错误，请加入我们的Discord并告诉我，或者在Twitter或Mastodon上联系我。我最近更多地使用Mastodon，我会分享链接。它是IndieWebSocial上的Brian LaRue。

有趣。Mastodon，我上次尝试时，工作室感觉非常安静。那里似乎没有多少活动。你感觉如何？你必须关注很多人。我喜欢它。我的意思是，没有广告，所以它是不一样的。你只看到你关注的内容，但你可以关注标签。而且实际上有一个不错的AWS社区正在那里发展壮大。好的。

他们刚刚达到1500万用户，与Twitter或LinkedIn相比，它仍然非常小，奇怪的是，它现在非常流行。但是是的，它很酷。我喜欢它。它噪音较小，但我认为这是吸引力的一部分。你只看到你想看到的东西。没有算法提要或任何东西，所以你必须关注很多标签才能真正……

让它运转起来。但是一旦你开始运行，它就相当可爱了，因为它很少有市场性。它更像是人们分享一些巧妙的想法，实际上让我想起了早期的Twitter。对。是的，我想他们那里疯狂的人也少了，没有无服务器。

是的，没有很多这样的情况。实际上，确实会发生。是的，肯定还有一些仇恨者。到处都是。是的。好的。是的，再次感谢Brian。我想我很快就会在Mastodon上看到你。是的，酷。谢谢，John。保重，各位。好的，再见。

这就是另一集《真实世界无服务器》的全部内容。要访问节目笔记，请访问realworldserverless.com。如果您想学习如何构建可用于生产的无服务器应用程序，请查看我在productionreadyserverless.com上即将推出的课程。我们下次再见。