#104: Baseline, is this new serverless development framework better than Amplify?
57:49 Share

感谢 Hookdeck 赞助本期节目。如果您想提升您的事件驱动架构，请查看他们在 hookdeck.com/theburningmonk 上的无服务器事件网关，并帮助支持此播客。Baseline 的 CTO Thomas Nixon 分享了关于采用无服务器技术挑战的经验故事。他为我们演示了 Baseline.js，这是一个新的无服务器开发框架，它总结了他团队在过去六年中积累的许多宝贵的经验教训。可以把它想象成 Amplify，但是您可以拥有源代码，并且可以轻松地自定义以满足您的需求。我建议您在 YouTube 上观看此视频，以便您可以看到完整的演示：https://www.youtube.com/watch?v=a6r8M8E_5n4本期节目链接：Baseline.js 入门Baseline 的 Github 仓库Thomas 的领英个人资料开场主题曲：Kevin MacLeod 的 Cheery Monday链接：https://incompetech.filmmusic.io/song/3495-cheery-monday许可证：http://creativecommons.org/licenses/by/4.0</context> <raw_text>0 本期节目的支持来自 HookDeck。使用这个完全无服务器的事件网关来提升您的事件驱动架构。要了解更多信息，请访问 hookdeck.com/theburningmonk。大家好，欢迎回到另一期《真实世界的无服务器》节目。今天，我邀请到了 Thomas Nixon，他是来自澳大利亚 Baseline 的技术联合创始人。嘿，伙计，很高兴见到你。你好，Jan。感谢你邀请我。

我之前和你的联合创始人 Ken 聊过你们在无服务器方面的一些工作。我从之前与其他人交谈中了解到，澳大利亚拥有这个无服务器为中心的初创企业中心，那里有很多活动正在进行。我认为一些最早的无服务器日会议，对不起，无服务器大会也在那里举行。

Ken 提到，在你们开始整个 Baseline 项目之前，你们一起在 Devica 工作，并且你们为各种客户做了很多工作，帮助他们在澳大利亚构建无服务器解决方案。你们遇到了许多有趣的挑战。所以我想在我们开始之前，你想快速介绍一下自己并谈谈你所做的工作吗？

是的，当然。谢谢。我是 Thomas，Baseline 的技术联合创始人。我的背景是软件开发。我做过各种各样的工作，从承包、产品工作到咨询。我什么都见过。我见过成功的项目，失败的项目，运行时间过长的项目，

我做过初级开发人员，高级开发人员，项目负责人，并且在所有这些领域都有丰富的经验。Baseline 就像所有这些经验以及我们用 Baseline 看到和开发的东西的总结。所以 Baseline 是一个最近开源的框架，我们希望帮助并添加到无服务器社区中，并真正推动我们用无服务器可以做什么。

是的，我想谈谈你刚才提到的那些事情，你是否已经确定了一些成功公司的常见模式以及在采用无服务器方面不成功或失败的公司的一些常见模式或共同特征？

是的。即使对我们来说，Sovalus 的采用本身就是一个完整的旅程。就我个人而言，在我与 Ken 合作之前，我来自一家公司，那里有很多旧的架构，使用

容器或虚拟机以及非常大规模的部署，这些部署很难使用。然后在一家代理机构工作并构建许多无服务器优先的应用程序，在思考方式上有很多挑战和变化。我喜欢这样想，有很多恐惧或……

未知因素，你会有很多情感上的差异来处理无服务器，因为你突然从了解你周围的所有环境，能够调整它、改变它、拉动不同的杠杆，到这个无服务器的世界，你不太知道如何让它运行得更快或扩展更多，甚至不知道不同的东西是如何连接的，所以采用的大部分内容是

我该如何让它工作？听起来很简单，但是一个 hello world 应用程序不足以让你说，嘿，我现在可以把它推送到生产环境中了。中间还有很多东西，比如连接到数据库，确保它可以扩展，环境变量，在本地运行它，所有这些东西。我们发现……

设置这些东西真的很棘手，我们发现很多项目经常有不同的结构、不同的工具、不同版本的工具，这使得可靠地推出东西变得非常困难，如果你不能可靠地推出东西，你就不能信任你的管道，你就不能信任应用程序，你不想凌晨 3 点醒来处理中断或任何类似的事情，所以我们真的想依赖无服务器，但是

我们发现仅仅使用无服务器不足以获得无服务器的好处，我们在过程中犯了很多错误，也学到了很多东西，仅仅使用那些听起来像是正确的东西并不总是能带来你正在做正确的事情的结果，我们在身份验证、数据库扩展方面遇到了一些问题，

打包 Lambda，你会发现 30 兆字节的限制或 50 兆字节的限制（现在是多少），你达到了这个限制，这可不是什么好时候，甚至只是开发人员如何在本地运行他们的代码，你是在本地云中运行它吗？所有这些问题不断出现，如果你没有经验，这些问题很难回答，而且

环境变化得非常快。因此，跟上使用哪些工具，无论是 CDK、SAM 还是无服务器框架，都可能非常具有挑战性。因此，我们真的想创建一个项目的基线，这就是 Baseline 出现的原因。我们希望所有东西都连接起来，开箱即用，并包含我们在过去六年构建 Baseline 中发现的所有经验教训。

并将它们融入到我们可以在每个项目中重复使用的产品中。因此，我们犯了一些错误，例如使用 Secret Manager 比 SSM 的价格更贵。

诸如此类的事情，就像嘿，我们每月在一些我们甚至不使用的密钥上花费 70 美元，或者只是如何以良好的结构部署代码，所以这里有很多技术障碍，一旦你把所有东西都组合在一起，它工作起来非常棒，我们取得了巨大的成功，但是在这个无服务器的采用过程中有很多障碍，因为它是一个如此广泛的生态系统，我认为目前没有人

对任何事情都有完整的答案。没有适用于所有事物的方案。你有很多不同的解决方案，但是你必须弄清楚它们是如何结合在一起的。反复试验是开发中最耗时、最耗时的部分。我们用很多不同的东西做了这个。所以进入无服务器，

开始忘记维护服务器或数据库是否与使用 Dynamo 和 Lambda 的计算一起扩展，甚至在那时进行 SQL 注入，这都非常棒。它变得……

开发东西变得非常容易，但是你必须处理新的问题。处理这些新问题，它们并不总是以有意义的方式解决，或者你使用了错误的工具来完成错误的工作。所以我们在这个过程中学到了很多东西，我认为在过去的六年里，情况也变得越来越好了。整个无服务器生态系统已经向前发展了很多，工具也变得好多了。

但是它仍然存在很多关于如何开始、如何大规模地做到这一点以及如何可靠地做到这一点并信任我可以构建的内容的核心问题。是的，正如你提到的那样，Lambda 对其工件的上载限制，取决于你的操作方式，如果你调用 API，它是 50 兆字节。如果你上传 S3 文件，它是 250 兆字节。如果你使用容器镜像，它是 10 千兆字节。Lambda 本身多年来已经获得了越来越多的

配置设置，你可以用来解决特定问题的东西。但是同样，有时它们并没有被宣传为这样。例如，Lambda 层，特别是对于 Lambda，AWS 中的一些宣传团队经常会促使你使用 Lambda 层来共享用于共享公共内容的包。

在项目之间、函数之间共享代码，而不是使用像 NPM 这样的包管理器。我发现 Lambda 层通常是人们四处传递的那些“脚枪”之一。他们被告知要使用它，然后他们意识到，哦，它实际上对于共享代码来说真的很糟糕。

是的，所以完全可以理解，特别是当，就像我说的那样，无服务器是一个如此庞大的生态系统。它不仅仅是关于 Lambda。还有所有这些你经常一起使用的服务。你必须学习每个服务是如何单独工作的，以及它们如何与 Lambda 交互，这取决于

你从事件源映射、并发控制、错误处理行为中获得的行为。所以有很多东西需要学习。但是我的意思是，我认为一旦你学习了它们，它可以真正地、真正地提高生产力，并且可以非常快速地完成事情。但是达到你精通并比以往任何时候都更频繁地做出正确选择的程度并非易事。这是我长期以来一直在关注的事情，是为了解决这个问题，但更多的是从教育的角度来看，你知道，我有研讨会，我有课程，我教人们如何做所有这些事情。我在社交媒体上也很活跃，但是对于刚开始并试图弄清楚所有这些事情的人来说，这并不容易。所以我非常喜欢你们正在做的事情，以及其他一些事情。

我想，类似的尝试只是以更用户友好的方式打包东西，这样它就可以做出明智的选择。例如 Jeremy Daly 使用 AMPT 所做的事情，以及我看到的 Wing Lang，提供更高的词汇量，以便人们可以开箱即用地获得这些最佳实践，而不是每次想要做某事时都必须学习和实现它们。

所以我想在这种情况下，关于一些，你是否看到过，我想回到我之前的问题，你是否看到过任何帮助你成功采用无服务器的常见模式？- 当然，我喜欢你关于我们试图让入门更容易的观点。开发人员是非常聪明的人。他们可以解决问题，他们可以很快地弄清楚事情。

我发现当他们说你必须参加为期六个月的 AWS 课程时，你学到的东西不如你拥有可以戳和探测的东西那样快。如果你有一个如何做某事的例子，你可以很快地学习，然后你可以开始根据你的需要修改它。因此，它消除了所有这些默认值和类似的东西。但是我们也需要优秀的内容。

所以是的，我们看到的常见模式是将 Lambda 和 DynamoDB 结合使用。这对我们来说非常成功。此外，我们尝试了 GraphQL。我们真的尝试了 GraphQL。这是一项很棒的技术，尤其是在用于正确的事情时。我们最终放弃了它。

我们发现 JSON API 效率更高。我们的重点是初创企业，快速启动并开始快速开发功能，而不是说大型企业系统或将一堆 API 粘合在一起。所以我们采用了 JSON API 的模式，但是我们以一种让你感觉像是在使用单体架构的方式构建它。

因为我们真的想利用现有的招聘市场。因此，任何了解 Express 或 React 或甚至无服务器 AWS 内容的人，我们都希望他们能够利用这些知识，并能够成功地使用 Baseline，而无需学习全新的东西。

所以如果你使用它，它感觉非常像是在使用 Express 服务器。我们已经处理了抽象。我们使添加它变得非常简单。你只是在构建路由并连接到已经存在的东西。真正的魔力发生在你打包它的时候。所以我们根据实体将其拆分为不同的 Lambda。所以我们发现这是一种非常有效的模式，因为你

冷启动次数更少，代码更本地化，包大小更小，并且保持更小。然后任何具有依赖项的东西，例如与例如 Zero 或 Stripe 的集成，都只保留在它们依赖的那些端点中。所以我们在后端使用了组合架构。

我们发现这对于快速构建事物非常有用。如果你需要添加特定的端点，开发人员可以快速添加它们并保持简单。我们已经包装了身份验证之类的东西，所以它已经开箱即用。因此 Cognito 已设置好。你在请求有效负载中拥有当前用户。你可以轻松地引用它。你可以使用中间件检查他们是否是管理员。我们也使添加这些东西变得非常容易。所以……

这对我们来说是一个很好的模式。我们在每个项目中都这样做，然后使用 CloudFront 和 S3 用于静态站点、SPA、React 非常有效。但是获取该配置需要很长时间。我不知道这是否是其他人也遇到过的问题，但是我们花了数年时间才将 CloudFormation 的设置正确。这需要

要做到具有成本效益、可扩展性、缓存，然后与 React 和 S3 设置配合得很好，这非常困难。我注意到有很多相互冲突的方法可以做这种事情。所以使用它对我们来说非常棒。你每月可以有 100,000 次访问，它每月只需花费 58 美分，因为 Route 53 的默认成本。

所以我们发现它非常有效。然后我们切换不同的技术来尝试它们并查看哪些技术有效。所以最初我们开始使用 Yarn 进行包管理。在 Yarn 2 和 3 稍微改变方向后，我们将其完全简化为 NPM。现在我们已经转向 PNPM，它非常有效，并且加快了

速度非常快，以及使用 ESBuild。ESBuild 使热重载更快，构建代码、发布它以及运行它都非常有效。由于我们使用的是无服务器框架和无服务器离线插件，因此在本地运行它是一个救命稻草。

我们发现以整个应用程序的意义在本地运行事物相当困难。我知道你可以单独调用事物，但是大多数时候你想要测试整个应用程序，而且你并不总是想将其部署到云环境中，特别是如果你项目负责人并且正在进行代码审查，你正在不同 PR 之间切换，这些 PR 具有不同的基础设施，将其推送到你自己的个人环境中。

AWS 帐户在这个级别上确实不起作用，因为可能会有太多更改需要更新该基础设施。因此，在本地运行，非常快速的反馈循环，能够快速更改它并拥有与云相当一致的环境，这对我们来说是一个改变游戏规则的东西。

最初我们没有那么多，我们单独调用事物，很多时候你会看到一些东西，如果你只是在完整的应用程序中运行它，你本可以更早地发现这些东西。因此，让它开箱即用并为此创建一个结构对我们来说非常重要。

好的。所以我想在这种情况下，你有一些，因为仅仅通过收听很难想象。所以你有一些例子可以用 Baseline 展示吗？也许是包装，也许是引导一个新项目并向其中添加一些新的端点？是的，当然。让我们做一个现场演示，看看效果如何。

对于在 Spotify 或其他播客平台上收听的各位，请查看下面说明中的链接，以获取完整的 YouTube 视频，以便您可以看到演示，与音频相比，视频会更容易一些。好的。

好的，所以我们最近在开源时重新构建了 Baseline，以使其入门非常容易。所以我们希望它感觉像 create React app，除了不仅仅是前端，我们希望它是整个应用程序。所以我们只需要运行这个命令就可以开始了，我们称之为 demo，这基本上会为你提供最新版本的 Baseline。

使用 Baseline，我们为你提供所有代码。所以没有任何隐藏的东西。没有黑盒子。所有内容都部署到您自己的 AWS 帐户中。因此，您可以充分利用您的 AWS 帐户并完全控制更改任何内容。所以虽然我们对设置方式有自己的看法，但您仍然可以继续更改任何部分。所以我们现在可以打开 VS Code。这是我们的……

新的 Baseline。在我们获得 Baseline 后，我们有一些事情要做。我们将打开自述文件并跳到设置部分。所以我们已经完成了一些步骤。所以使用 PNPM，我们只需安装包，之后，只需进行设置。

所以这个设置基本上允许你添加应用程序名称并为其指定一个区域。所以我们将使用 AP Southeast。由于我们是……

我们经常开发许多应用程序。我们永远不想使用 AWS 默认配置文件。所以 Baseline 内置了配置文件。所以我们在任何地方都添加了抽象。所以它总是使用应用程序名称作为配置文件。所以你可以非常轻松地在项目之间切换。由于无服务器框架不支持 SSO，

我们做了一个小命令来让我们输入并抽象它。你仍然可以使用 configure 将配置文件添加到 AWS 命令中，但是我们发现这更容易。

既然我们已经设置好了……对不起，这意味着你必须先设置配置文件吗？或者这个步骤会为你创建一个配置文件，你可以用它来使用 AWS CLI 和其他所有东西吗？这是一个好问题。所以我们假设我们已经设置好了。不幸的是，设置 IAM 内容仍然不像我希望的那样无缝。它……

你仍然可以使用 IAM 角色并使用你的管理员凭据以及类似的东西。我们在内部使用 SSO。所以因为它有第三个密钥，会话令牌，我们基本上将其粘贴进去。对。它不像我希望的那样好，但是我希望随着时间的推移，我们会得到一些关于如何做得更好的建议，因为我们希望看到它更强大，并支持更无缝的入门过程。

好的，在这种情况下，你说你总是默认为应用程序名称。这意味着当我使用单点登录在我的 AWS CLI 中设置它时，我需要确保我使用的配置文件名称与我将在 Baseline 中使用的应用程序名称相同。是的，是的。在 Baseline 中，你在其中执行的所有操作都已支持该配置文件标志。好的，明白了。

然后，既然我们已经……我已经完成了这个，所以它已经在后台隐藏了，所以我无需向任何人展示我的密钥。我们现在可以进行部署了。所以这会启动 API、管理员门户和网站的部署。所以……

所以这表示部署到 staging。这意味着它正在部署到名为 staging 的无服务器阶段吗？是的。所以堆栈以 staging 为前缀。开箱即用，我们有本地环境作为阶段，然后作为环境，然后 staging 作为环境，以及 production 作为环境。因为在应用程序开发过程的后期重新访问它会变得有点棘手，因为

弄清楚稍后在哪里放置名称可能会很棘手。所以开箱即用地拥有它使事情变得非常容易，因为你自动开始考虑它是哪个阶段。

好的。我想也许还值得向任何没有看到过这一点的人提及，那就是这一切都围绕无服务器框架进行包装。所以最终你拥有底层的无服务器框架，但是你在它之上创建了另一层，以便它创建几乎类似于无服务器框架模板的基本引导。但是我想不仅仅是这些，你还在这之上添加了其他东西，例如支持单点登录等等。

是的。所以一种说法是，我们专注于优雅而不是抽象，并将我们能找到的最佳技术粘合在一起，以解决目前的问题，然后使更改任何部分都变得非常容易。Baseline

我们为你提供所有代码，它只有不到 6000 行代码，我认为所以能够将任何部分适应你已经熟悉的东西，或者如果你只是想开始更改东西，这将变得非常容易，因为它非常底层，并且接近你正在使用的技术，而不是拥有

例如 Baseline 抽象层，它实际上只是代码……在那里，所以它非常像一个模板，但是我们添加了很多东西，让你可以做比模板多一点的事情……所以这是部署的……我有点作弊，因为我已经部署了 CloudFront 内容，所以它不会花费 8 分钟，是的，8 分钟来完成……

这个设置过程的一部分是，我们希望尽可能让用户远离 AWS 控制台。所以我们试图使入门变得非常简单。在这样做时，如果你第一次设置应用程序，通常需要一个用户。所以我们使开发人员能够开箱即用地轻松添加用户。所以我们将把我添加到其中。这会将我添加到 Cognito 和 DynamoDB 中。

我明白了。我想默认情况下，你使用 Cognito，你使用 API Gateway，你使用 DynamoDB 表。我想，你使用的是……

使用 Lambda 函数的确认触发器来将用户也保存到 Dynamo 中吗？这是一个非常好的问题。实际上，我们花了很长时间来苦思冥想的事情。我们最初有触发器，我们非常努力地尝试让它工作。我们经常发现我们使用以前设置的方式时存在时间问题。所以我们实际上改用

完全不同的方法，我们使用 user sub 并将其存储在管理员处。但是对于用户，我们只使用 user sub 并根据它进行存储。这是两件不同的事情。我想 user sub 只是你用于用户 ID 的东西。

但是我想听起来你既在 Cognito 中拥有用户，也在 DynamoDB 中拥有用户。你首先说的是不使用触发器。所以在用户注册过程中，如果你不使用触发器，用户何时会被添加到 DynamoDB 中？好吧，我们使用 ID 作为本质上，你可以认为它是独立的，它自己的对象。所以我们使用 user sub 在其他任何地方引用它。

我们之前创建过触发器，如果应用程序特别需要它开箱即用地将内容附加到该用户，或者如果我们想跟踪该用户的特定信息。但是，让事情有效地工作一直是一个问题，因为……

显然，user sub 特定于 Cognito，所以并非总是依赖它很理想。然后存储重复信息会使其不同步。我们一直试图保持同步，但是我们在使用触发器的部署中遇到了问题，触发器有时会与

Cognito 分离，你实际上必须进入 UI 并更改它。我不确定你是否遇到过这种情况，但是它出现了。那个特定问题

对不起？我从循环引用的角度遇到了触发器的问题，所以如果我真的需要从触发器引用 Cognito 用户池，那么我就会有循环引用。但是我没有看到它们突然从 Cognito 中消失。我没有见过那个。是的，这是一个非常奇怪的问题，触发器看起来好像已连接到 UI 中，但它就是不会运行 Lambda。

所以我们实际上一直这样做，最近这样做非常成功。它简单得多，但并非对每个应用程序都理想。有些应用程序你希望存储直接用户，使其保持同步等等，并使用触发器，你只需开始创建对象，其中你使用 user sub 来引用要获取的对象或该关系。

这非常有效，因为它可能只是针对 user sub 存储权限，然后你可以获取关联的权限或任务等等。它非常有效，并且比例如拥有重复的用户对象简单得多，但它非常有效。如果你愿意，我可以深入探讨一下。

- 好的。也许是因为，好吧，我想我仍然不明白的是，如果你，所以你是说你在 DynamoDB 中没有用户的重复记录吗？- 对于，是的，我们为管理员用户有。- 好的，但是对于在 Web 应用程序本身注册的用户则没有。- 是的，你不能添加它，因为我们希望 Baseline 足够灵活，可以开发成任何类型的应用程序。我们不想规定所有内容。

所以这是其中一部分，我们不知道你将要构建什么。它可能是一个 CMS，可能是一个市场或一个 SaaS。这就是用户内容开始变得有趣的地方。事件驱动架构是构建大型系统的强大范例，但它们也因其在生产环境中难以测试、观察和监控而臭名昭著。

有如此多的独立事件发布者和订阅者，围绕错误处理、警报和恢复以及确保你对事件的整个生命周期具有完全可见性，以便能够解决你遇到的任何问题，都存在许多额外的复杂性。

我在 AWS 上构建了许多事件驱动架构，这些只是我面临的一些反复出现的挑战。这就是 HookDeck 的用武之地。它是一个完全无服务器的事件网关。你无需管理任何基础设施。你可以使用他们的命令行界面在几分钟内开始使用。

与 Amazon EventBridge 相比，它执行 EventBridge 执行的所有操作。它可以从多个来源摄取事件，过滤它们，将它们路由到不同的目标，并沿途转换事件，但它还提供更好的开发人员体验，包括本地开发体验，以及更详细的指标和日志，以帮助你调试事件传递问题，以及能够轻松查询你拥有的事件，这使得测试变得简单得多。

你今天可以开始 HookDeck 的免费试用，并同时支持此播客，方法是访问 hookdeck.com/theburningmonk。好的，好的，对。我还想问另一个问题，为什么使用 sub 作为用户 ID，而不是单独使用用户 ID？因为当你有……

我想是单点登录和社交登录之类的东西时，sub 的效果不太好，因为你使用的每个平台都会有不同的 Cognito 用户，它们会有不同的 sub，但是如果它们都引用同一个用户，你可能想要拥有你自己的用户 ID。所以我想问题是，为什么使用 Cognito sub 作为用户 ID，而不是拥有单独的用户 ID？是的。

这就是它开始变得有趣的地方，因为当您有多个登录时，这时您真的想开始整合这类事情。开箱即用，我们希望使其足够简单，以便不会为此类事情添加大量的抽象，因为我们不想添加基本上不会使用的代码。所以……

并非每个应用程序都会使用单点登录。我们希望有一个非常自然的 Cognito 实现。Baseline 的好处是，我们以后可以添加一个基础块或一个基础堆栈，在其中添加此功能。因此，仅仅因为它不在您获得 Baseline 的核心内容中，并不意味着我们不能将其添加到我们的生态系统中，供人们开始使用这样的东西。因此，如果这成为一种非常流行的做法，我们可以稍后注入该代码。

好的，好的，听起来不错。好的，请继续。是的，在我们设置好所有这些之后，我们希望有一种方法可以获取项目的 URL，而无需在控制台中深入研究 CloudFormation 堆栈。因此，我们使查找它们变得非常容易。我们使用开箱即用获得的默认 CloudFront URL，这样我们就不必专门……

开箱即用地进行域名配置，因为它会妨碍您，因为并非每个人都为他们的应用程序准备好了域名，这就是 Web 门户，然后我们可以直接跳转到管理员门户，因为我们已经创建了该用户并且已经登录，所以我们可以直接登录

因此我们可以看到我有一个管理员，我们可以邀请更多用户、删除、更改电子邮件，所有这些东西。因此，我们基本上已经获得了一个在您的帐户中开箱即用的完全可运行的无服务器优先应用程序。

所以这一切都很好。因此，开箱即用，我看到有一个基线核心架构。我们可以看一下，以便了解到目前为止创建了什么？您提到有 Cognito 用户池、API。此外，还有一个 Web 应用程序 S3 和应用程序中的 S3。好的。是的。好的。

所以这是一个相当标准的实现，这里没有什么特别的，实际上只有一个 Lambda，两个 CloudFront 分发，您只是在使用 API Gateway Dynamo DB，我们也希望保持它的简单性，因为我们真的希望您能够成长为任何东西……

当您拥有 CMS 之类的东西时，它会变得更有趣。您可以从这样的图表中看到事物如何更多地交互。但是，是的，这是开箱即用的非常基本的设置。好的，明白了。所以现在我们已经设置好了，我们实际上也可以开始在本地运行项目了。因此，我们还设法将环境变量管理放入 Baseline 中。因此，我们实际上可以首先在本地生成所有项目

环境变量，这只是为项目设置了一些 .env 之类的东西，然后我们可以启动 API，现在 API 将完成什么，.env 文件的内容来自哪里……它是堆栈输出的组合……

以及为该项目专门配置的任何内容。因此，您可以修改和添加到生成脚本的方法。好的。这使得管理前端和后端环境变量以及随着时间的推移扩展它们变得非常容易。我们发现，像前端如何知道后端 API 的 URL 这样应该很简单的事情，如果没有将一些东西粘合在一起，就很难回答。我知道最近出现了一些功能可以使这更容易，但是让它在本地工作或在构建过程中部署，您必须将所有内容打包在一起，我们真的想要这样做

那里的东西，以及为所有参与项目的开发人员提供一致的环境。因此，如果您加入项目，您不希望从其他人那里复制 .env 文件，或者试图弄清楚谁拥有最新的文件或缺少哪些环境变量或哪些应该是真正的秘密。我们希望它包含在项目和您的 AWS 帐户中。这就是我们倾向于这种环境变量管理的原因。

好的，很好。您提到您可以引入 ExpressJS 或其他任何东西，然后您可以将它们剪切成，我想，以实体为中心的函数，这些函数服务于特定于特定实体的一组端点。那么，我们可以看看您开箱即用的一些 Lambda 函数吗？

是的，当然。我将启动并运行它，我们将创建一个全新的实体，我们可以看到所有生成的代码及其所在的位置。好的。是的。这也有很多类似的东西，我已经看到 Amplify 团队试图通过 Amplify Studio 来做到这一点，即为您开箱即用地构建管理控制台，让您轻松做到这一点等等。

但是，当然，Amplify 的一个问题是它有点像黑匣子，很难摆脱。因此，您可以访问所有代码并能够修改它，这就是我想要的 Amplify 的好东西之一。但我还没有看到它，但我一直被告知 Amplify Gen 2 将使它变得更好得多。

是的。是的。我们尝试过几次放大，希望它能成为 Baseline。我们只是，它永远不够，或者它生成的代码永远不是您想要的代码。对。我们发现它很难使用。否则，我们可能会使用它，并且 Baseline 实际上根本不存在。所以是的，

但是现在在本地运行它，我们可以登录。我们在 API 中模拟了一个用户。我们有种子数据。因此，当您在本地运行它时，您可以为参与项目的开发人员提供存储在存储库本身中的一致数据集。每次您重新启动 API 时，它都会被填充。因此，如果我们只是删除记录，如果您再次启动 API，该记录将再次出现。

并且您可以从本质上复制部署体验的样子……因此，如果我们想快速发布更改……我们将只说更改它更新为 demo app……我们可以看到 React 热重载正在运行，我们实际上可以简单地运行 pnpm run deploy

现在，显然您通常会为此类事情使用 CICD，但您也可以从本地执行此操作。使用此命令，我们将把所有内容组合在一起

并尝试部署任何已更改的内容。它还包括失效，因此您不必担心进入控制台并进行失效。它只是使这个过程变得非常简单，如果您添加了新的代码或新的基础设施，它都会通过这个统一的部署命令发布，这非常有用。所以现在已经部署了。所以如果我们回到这里，回到这里。

我们将刷新一下，我们可以看到更改立即发布了，因此它确实提高了迭代速度，现在我们使它更有趣，我们可以创建一个全新的实体，我们现在就这样做，让我们回到这里，这是通过如果我们运行 pnpm add object

所以我们有这些叫做 Baseline 命令的东西，你可以扩展它。add object 命令基本上是一个代码模板，您可以生成它并将代码注入 Baseline。所以我们让它为此处创建一个全新的实体。所以我们做一个任务，我们将给它一个名为 title 的新字段。什么是任务？就像 Jira 任务一样，或者像项目的实际对象一样。

对于项目。或者它可以是任何东西，例如书籍对象或用户类型对象。

所以我们将使用……-哦，那只是一个名称，而不是类型。对不起，我以为这是一个特定类型。-没关系。我们将使其不是必需的，我们还将添加描述字段。我们将添加它。因此，这将生成此代码。所以我们现在有了类型、服务代码、CDATA、任务函数。因此，无服务器的 YAML 定义，以及 DynamoDB 和 API 代码。

然后我们有了共享类型，这样我们就可以在前端和后端之间共享它，那么服务和 API 之间的区别是什么？服务和 API？服务正在实现我们的服务对象……这使我们可以对该服务对象执行常见操作或业务逻辑，然后 API 是实际的接口

能够使用并对该对象执行操作。这就是您在执行操作之前检查用户是否有效或请求是否正常的地方。所以非常像 Express。非常熟悉。我们已经内置了中间件，用于检查用户是否在 DynamoDB 中并与用户子项对齐的管理员之类的事情。

然后是一个响应映射器，并且在那里使用服务来创建任务。所以代码非常简单直接。所以你说它看起来非常像 Express。它实际上是在使用 Express API 还是……好的。所以我们使用了……

我们有一个包装器，用于使用 Cognito 和特定的设置创建应用程序，以确保它针对在 Lambda 中运行进行了优化。它非常有效且快速。冷启动令人惊叹，响应时间非常令人印象深刻，即使是 DynamoDB 命中和对 API 的身份验证也是如此。

我们希望简化设置这些东西的整个过程。这就是 create app 存在的原因。好的。因此，一旦创建并部署了函数，它实际上是否像使用 LambdaLiv 一样运行 Express？

是的，所以 Express 将运行。它主要用于路由和能够以熟悉的方式利用中间件、请求和响应对象，这对于大多数以前使用过 Express 的人来说都非常容易访问。好的。当你说代码启动时，这太棒了。您的函数的代码启动会得到什么样的数字？所以我们最近刚刚升级到 Node 20 和……

AWS SDK 3，我认为它们下降到 400 毫秒并完成。是的。往返时间约为 700 毫秒。因此，任何持续时间的约 400 毫秒，然后端到端为 700 毫秒。好的。这有点快。我，我，

我认为可以接受的个人障碍是最多一秒钟。低于一秒钟的任何内容，您都可以轻松处理。我认为，对于典型的用户应用程序来说，任何更长的时间都开始进入危险区域。是的，我认为一秒钟，对于人们设置 SLA 和类似的事情来说相当普遍。然后在那之后，我认为请求，在您完成冷启动后大约

50 毫秒往返时间。在这种情况下，您是否，因为您也有管理仪表板。因此，这只是从架构图中 S3 托管的单页应用程序。好的，开箱即用没有服务器端渲染。

是的。因此，它非常专注于构建应用程序，而不是替代 Next.js 之类的东西。对。明白了。您仍然可以在您的 Baseline 项目中放入 Next.js。好的。

我们经常引入 React Native，以便在管理门户和客户端门户旁边拥有移动组件。我们发现扩展 Baseline 非常有效。我们从未希望它仅仅是这样。它只是一个管理门户，仅此而已。它永远不会成为任何其他东西。现在您可以将其完全发展成应用程序所需的任何东西。添加更多包等等。

所以现在我们已经添加了这个代码，我们可以添加一些种子数据来开始。看看 Copilot 是否启动。还没有。任务 ID，我们将保持简单。标题、描述、项目符号。好的，我们现在有一些对象了。我们实际上可以再次启动 API，并且我们将拥有 API 中的新实体，它只会显示出来。

我们可以看到它正在运行，我们可以看到数据正在传输。那么我们现在如何部署它呢？好吧，方法还是一样的。我们实际上可以运行该部署暂存，这将发布所有新的后端代码，这使得开始使用变得非常容易。

然后您可以扩展任何此代码，因为由于我们注入了代码，您仍然可以修改任何代码。它不仅仅是一个抽象，就像我们添加一个新任务并赋予它所有逻辑一样。我们生成代码，您可以修改它。您甚至可以更改模板本身，因为它在 Baseline 中。因此，如果您有特殊需求，您可以开始将其修改为自己的项目。

在每个 API 端点中，您可以添加它，并且您可以利用这些模板或为应用程序的不同部分创建新模板，在这些部分中，您必须不断生成新代码。好的。并且您有一些，我想，接下来可能是查看 Baseline 块的工作方式，以便您可以引入一些额外的，我想，附加组件。听起来像是您可以添加到现有项目中的东西。

是的，我今天没有演示。但这是我们经常做的事情。我们有基础块和基础堆栈的概念。因此，基础堆栈可能类似于 React Native 基础堆栈，您可以将其放入，然后它会自动连接到 API，与 Cognito 一起工作，拥有所有构建管道并连接到此处存在的各种脚本。

然后基础块基本上位于其之上。因此，您可能有一个用于 API 的基础块，例如，您添加一个任务，它也可以注入该代码。

因此，我们希望使社区能够构建 Baseline 的扩展，并使其能够修改该扩展，而不是专注于将事物打包到可能无法维护的库中。因为维护您不知道人们将如何使用的东西可能会很棘手，这就是我们制作 Baseline 的原因之一……

从本质上讲，精简了，所以我们为您提供了一个非常好的盒子。我们不在乎你在盒子里做什么。你可以弄乱它，也可以让它变得非常漂亮，非常结构化。但我们想给你一个不错的盒子来开始，我们不知道你会改变它什么。因此，一旦您拥有了代码，您就可以随心所欲地做任何事情。好的，明白了。

所有这些都基于 Express，我想。那么，有人说，运行正确的测试有多容易？因为您展示了如何在本地进行探索，如何在本地运行模拟，但是关于，您是否有关于如何为此编写测试的一些示例？非常好的问题。我们故意忽略了测试。我非常清楚这是一个有意见的地方。

我对您现在为业务逻辑编写测试而不是 100% 覆盖率的实用观点，因为如今工具中有很多东西都被捕获了，例如 lint、美化、构建。甚至您的 IDE 都有所有工具可以自动为您提供不工作的部分的红色波浪线。单元测试并不能让您免受一些无论如何都会出现的问题，

无论如何，单元测试对于业务逻辑或必须以这种方式 100% 工作的事情非常重要……所以我们把它留空了，我们将来会提供指南或潜在的基础块，只需插入测试即可，但我们没有将其作为其中的一部分，仅仅是因为我们知道您可以用它做很多事情，并且

我真的很不喜欢所有创建的东西。TypeScript 中的测试已经取得了长足的进步，但您仍然必须做一些非常奇怪的事情，这使得将其添加到项目中可能很困难，尤其是在使用基础设施即代码时。我们还没有找到正确的粘合剂来使其成为一种非常棒的体验。

好的，所以您谈到的是您希望测试业务用例，而不是单个代码块。您可以使用单元测试来测试您在那里拥有的那些单独的服务或 API 模块。但是通常情况下，您知道，您的业务用例不仅仅是 CRUD。您将调用一些不同的东西，从不同的地方提取数据。然后这就是您实际服务用户请求函数的方式。

所以我想在这种情况下，您仍然会，作为您的建议的一部分，您会说这更像是您想要在端到端测试级别上做的事情，您将其称为前端客户端的 API，然后您确保整个 API，包括 Lambda 函数和其他所有内容都正常工作？是的，基本上，是的。使用此设置进行端到端测试非常强大，因为由于所有内容都

从您身边抽象出来。如果没有构建大量新的测试抽象，就很难以有意义的方式对其进行测试，这可能会引入新的奇怪问题。因此，我认为当您部署到 AWS 帐户时，端到端测试对此类事情非常棒。因此，即使您只是在测试帐户、测试暂存环境上运行它们，这也是一种相当不错的方法。

但是，您知道，合适的工具用于合适的工作，这就是我提出的现实情况。

而且，我想这是重点。我认为您之前提到过，你们偏离了 GraphQL，这完全专注于 REST。您可以在本地运行的一些本地模拟是否存在一些限制？我想，这是使用无服务器 API 本地、API 网关本地来模拟本地 API 调用吗？好的。是的，是的。所以我们发现这是最……

可靠的方式。我们知道它不是完美的逐一体验，但我们尝试过引入不同的工具，例如 SAM 或任何使用 Docker 的工具，并且我们遇到了一些延迟。我们仍在测试那里不同的工具。如果某些东西变得更流行或更有用，我们愿意更改它，在运行整个应用程序的体验中。我们只是发现

一旦您引入 Docker，hello world 的响应时间对我们来说大约在 1 到 3 秒之间，如果您在应用程序中有 100 个端点并且像普通应用程序一样加载它，那可能是一场真正的斗争。因此，模拟它是我们迄今为止发现的最佳体验，并且支持服务框架，为基础设施提供多个文件，这非常有意义。

好的，我想你们正在为 Baseline 计划什么未来？您是否主要考虑只是继续添加基础块，以便您可以向项目添加自定义？我想，这背后的商业模式是什么？是的，我们有一个路线图。

由于我们是开源的，我们正在寻找外部反馈，并查看人们如何使用 Baseline，这将是关于此事的真正有趣之处。我们将开发它。我们仍在研究 AWS 或

或合作伙伴围绕不同工具推出的技术。我们知道 Solace Framework V4 即将推出，并且我们正在更改其周围的许可。所以我们看看情况如何发展，无论我们是否继续使用 Solace Framework 或切换到 SAM（如果它开始支持足够多的东西）。我们……

我非常有兴趣构建基础块生态系统和基础堆栈生态系统，因为如果社区可以扩展 Baseline，它将使人们免于例如分叉 Baseline，然后修改它，最终我们得到的是整个 Baseline 生态系统。如果我们可以使其成为一个

一个真正强大的地方，人们可以在其中添加代码和功能，并且我们可以成为将整个应用程序整合在一起的粘合剂。那将是太棒了。我认为，例如，现在进入无服务器领域的一个难题是如何在我的应用程序中使其工作？如何在不弄清楚粘合剂如何组合的情况下，今天开始在我的应用程序中使用它？

我们将自己构建一些模板，我们可能会将其作为加速使用 Baseline 的方法来出售，例如您可以开始使用的成熟市场或成熟的移动应用程序等等，我们还将进行咨询和服务围绕 Baseline，并且

正在考虑为基础块构建该市场。因此，实际上，我们正在测试以与开发人员建立产品市场契合度，我们正在努力降低初创公司构建应用程序的进入门槛。但我们也在关注

云现代化，也许某个组织以前没有使用过 Baseline，他们想迈出进入云的第一步，我们希望 Baseline 可以成为一种非常低风险的方法，因此能够从 Baseline 项目开始，然后开始构建并取得进展并看到结果，这正是我们目前的目标，然后开源任何非常有用的东西，所以我们已经

还创建了一个 DynamoDB 库，您可以将其放入其他项目中。我们构建它是因为我们需要从 DynamoDB 获得更多性能，并且我们有一种使用它的方法，我们确实在 Baseline 中使用了它，但我们希望人们能够获得更新，因此我们将其移到了它自己的存储库中。因此，任何其他有意义的事情

拆分出来，我们也可能会这样做。然后从长远来看，我们很想支持其他云，但这我想还需要一段时间。我们真的只想让开始使用无服务器的体验变得非常好，并消除那些障碍，可能使 IAM 东西更容易上手等等。

好的。好的。听起来雄心勃勃。我想祝你好运。是的，Thomas，非常感谢您今天抽出时间与我们交谈，并向我们展示 Baseline 的演示。看起来非常有趣。我想如果人们想开始，他们去哪里？他们可以在哪里阅读有关 Baseline 的信息以及一些入门指南等等？是的。

是的。所以 baselinejs.com 将带您进入一个好地方。您还可以在 GitHub 上找到我们，baselinejs，我们将在那里提供有关如何开始的说明。所以是的，我们期待社区及其对我们正在做的事情的回应。是的。或者在 LinkedIn 上找到我并向我提问。

好的，当然。我会将这些链接放在下面的描述中，以便人们，因为您提到你们将围绕此进行一些咨询工作。因此，如果有人想开始使用 Baseline 并遇到麻烦，他们也可以从下面的描述中找到您的信息。太棒了。再次感谢您今天抽出时间与我们交谈。是的，祝 Baseline 未来一切顺利。谢谢，Jan。我很感激。保重，各位。下次见。好的。再见。

感谢 HookDeck 对本集的支持。您可以了解有关 HookDeck 如何改善构建事件驱动架构的开发人员体验的更多信息。访问 hookdeck.com/theburningmonk。

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