Chris Coyier 的 Smashing Podcast 第 22 集：什么是无服务器？

今天，我们谈论的是无服务器架构。 这意味着什么，它与我们目前构建网站的方式有何不同？ 我与 Chris Coyier 进行了交谈以了解情况。

显示注释

• Chris 的微型网站 前端开发人员的无服务器的力量
• 克里斯在推特上
• ShopTalk Show 播客

每周更新

• “设置 Redux 以在实际应用程序中使用”，
  通过杰里纳维
• “你能为五种感官设计一个网站吗？”
  苏珊娜·斯卡卡
• “使用 Sapper 和 Strapi 创建静态博客，”
  作者 Daniel Madalitso Phiri
• “React 应用中的产品导览实用指南”，
  by Blessing Krofegha
• “如何使用草图创建保时捷 911，”
  尼古拉·拉扎雷维奇

成绩单

Drew McLellan：他是一名网页设计师和开发人员，您可能从 CSS-Tricks 认识他，这是一个他在 10 多年前创建的网站，对于那些构建网站的人来说，这仍然是一个极好的学习资源。 他是 CodePen 的联合创始人，这是一个基于浏览器的编码游乐场和社区，被世界各地的前端人员用来分享他们所做的事情并从他们关注的人那里寻找灵感。 与 Dave Rupert 一起是 ShopTalk Show 的共同主持人，这是一个关于制作网站的播客。 所以我们知道他对 Web 开发了解很多，但你知道他曾经仅靠他的魅力赢得了吃热狗比赛吗？ 我的好朋友，请欢迎 Chris Coyier。 你好克里斯，你好吗？

Chris Coyier：嘿，我太棒了。

Drew：我今天想和你讨论的不是 CodePen，我也不一定想和你讨论 CSS-Tricks，这是我相信每个人都知道出现在 Google 顶部的令人惊叹的资源之一查找有关任何 Web 开发问题的答案时的搜索结果。 弹出你的脸，你或你的一位来宾贡献者写了一篇有用的博客文章。

克里斯：哦，我曾经真的这样做过。 有一个……我不知道，可能是在谷歌拥有那个奇怪的社交网络的时候。 那是什么？ 谷歌加？

德鲁：哦，另外，是的。

克里斯：是的，他们会将网站与 Plus 帐户相关联，所以我的 Plus 帐户有一个头像，头像就是我，所以它会出现在搜索结果中。 我想那些日子已经一去不复返了。 我想如果你…

德鲁：我想是的，是的——

克里斯：是的。

Drew：但我有点想和你谈谈一些你的兴趣爱好，那就是无服务器架构的概念。

克里斯：嗯（肯定的）。

德鲁：这是你一段时间以来一直在学习的东西。 那正确吗？

克里斯：是的，是的。 我只是一个粉丝。 这似乎很适合前端开发的发展，我觉得我至少在这方面拥有一些专业知识。 我认为自己在前端比后端更有用得多，而不是我……我这些天都在做。 我已经有足够长的时间了，所以我不害怕看一点 Ruby 代码，这是肯定的。 但我更喜欢前端。 我研究了更多。 我在那个级别上参与的项目更多，然后出现了一种新的范式，它说“你可以在服务器上使用你的 JavaScript 技能”，这很有趣。 你懂的？ 我就是这么想的。 它的意义远不止于此，但这就是我关心的原因，因为我觉得前端开发人员已经对 JavaScript 进行了如此深入的研究。 现在我们可以在其他地方使用同样的技能。 嗯，很酷。

Drew：似乎一个全新的世界已经打开，而如果你只是一个前端编码员......我说，只是一个前端编码员，我不应该。 如果您是前端编码员，并且您习惯于与同事或朋友一起帮助您进行后端实现，那么突然之间就开放了。 而且您可以自己管理更多的整个堆栈。

克里斯：是的，是的。 而已。

德鲁：对着房间里的大象讲话，就在顶部。 我们正在谈论无服务器，显然，命名事物是困难的。 我们都知道。 无服务器架构并不意味着没有服务器，不是吗？

克里斯：我认为这是强制性的，例如，如果这是您第一次听到它的播客，或者在第一次……您只是在前十几次听到“无服务器”这个词时才听到它，那么您必须有一种本能的反应并有这种“哦，但仍然有服务器”。 没关系。 如果您现在正在发生这种情况，请知道，这是其中的必要步骤。 就像生活中的其他任何事情一样。 理解是有阶段的。 第一次听到，你需要稍微拒绝一下，然后十几次，或者证明对你有点价值，你才能进入更深的阶段这里的理解。 但是这个词已经赢了，所以如果你还在反对“无服务器”这个词，我不想告诉你，火车已经离开了那里的车站。 这个词已经成功了。 你不会赢得这个。 非常抱歉。

Chris：但我确实认为有趣的是……它开始变得像，也许有时实际上不涉及服务器。 我认为将无服务器作为一个概念锁定的事情之一是 AWS Lambda。 他们是现场的第一批人。 lambda 就像你给 AWS 的一个函数，它把它放在神奇的天空中，然后……它有一个 URL，你可以点击它，它会运行那个函数并返回一些你想要的东西。 你懂的？ 那只是HTTP或其他。 这就是它的工作原理，……当你第一次听到这个的时候，你会想，“为什么？ 我不在乎。” 但是，有一些显而易见的事情。 它可以知道其他人无法访问的我的 API 密钥。 这就是你开始运行后端的原因，因为它知道不必在客户端的 JavaScript 中存在的秘密内容。 因此，如果它需要与数据库通信，它就可以做到。 它可以安全地做到这一点，而无需在其他地方公开 API 密钥。 甚至这些数据在哪里或如何获取它，它是……

克里斯：所以这很酷。 我可以编写一个与数据库对话的函数，获取一些数据，然后返回。 凉爽的。 所以，Lambda 就是这样，但 AWS 可以工作。 你必须选择一个地区。 你就像，“我不知道。 它应该在哪里，弗吉尼亚？ 俄勒冈？ 我应该选择澳大利亚的吗？ 我不知道。” 他们有 20、30 个。我什至不知道他们现在有多少，但即使是 lambdas 也有区域。 我认为，他们现在有 Lambda@Edge，这意味着它是所有地区，这很酷。 但他们是第一个，现在每个人都有像 Lambda 这样的东西。 所有的云服务。 他们想要在这个世界上获得某种服务。 其中之一是 CloudFlare。 CloudFlare 有工人。 他们拥有比 AWS 更多的位置，但他们执行它的时间也有所不同……就像 CloudFlare 工作人员的方式……它类似于 lambda，因为您可以运行 Node.js。 您可以运行 JavaScript。 你也可以运行许多其他语言，但是……我主要考虑这些东西，最有趣的语言是 JavaScript，只是因为它的流行。

克里斯：它只发生在 CDN 级别，我猜它是服务器，但我倾向于不将 CDN 视为服务器。 不像其他东西那么明显。 最近开始感觉更加无服务器。 CDN 是服务器吗？ 我的意思是，我猜它是某处的计算机，但感觉更像是更少的服务器。

Drew：感觉就像，是的，CDN 可能是服务器，但它是服务器的最简化版本。 如果您愿意，它就像一台瘦服务器。

克里斯：是的。 当然。

德鲁：好的。 我听说过……不幸的是，我不记得要归功于的来源，但我听说无服务器被描述为“就像使用像 Uber 或 Lyft 这样的拼车服务”或其他什么。 你可以无车而不拥有汽车，但这并不意味着你从不使用汽车。

克里斯：是的，这并不意味着汽车不存在。 嗯，不错。

德鲁：你只是在需要的时候召唤一辆，但同时，你不需要支付汽车的前期购买成本。 你不支付维修费或燃料费或-

克里斯：对，定价也很合理，对吧？ 那很好。 我认为这是一个很好的类比。 然后，因为它也在 CDN 级别，所以它只是拦截已经发生的 HTTP 请求，这意味着你不问它……你不向它发送请求，它会发回请求。 它只是在请求期间自然发生，这也使它感觉不那么服务器化。 我不知道，这很有趣。 这肯定很有趣。 不过，这很重要，因为您提出了定价问题。 你只需为你使用的东西付费。 这也很重要，因为……比方说，您是一名后端开发人员，他一生都习惯于运行服务器。 他们计算成本，“我需要这种具有这种内存、这种 CPU 和这种规格的服务器。 这就是它的成本。” 无服务器的出现并削减了该定价。

克里斯：所以，即使你是一个不太喜欢这个的后端开发人员，他们只是不喜欢它，就像你的技能是多年来的样子，你比较价格你会说，“什么？ 我可以支付我之前支付的 1% 的费用吗？” 你不能不在乎这个，对吧？ 如果你是这个后端开发人员，为他们的服务支付的费用是他们需要支付的费用的一百倍，那么你的工作就有点糟糕了。 不好意思说。 这种情况已经出现，并且在很多方面都破坏了定价。 你必须关心这一点。 其他人很酷……这并不是说您根本不必担心安全性，但这不是您的服务器。 您没有……您的 lambda 或云功能，或者您的工作人员，或其他任何东西，都没有位于您自己网络上一些真正敏感数据旁边的服务器上。 它不在您的数据库旁边。

克里斯：如果有人编写的代码以某种方式试图将自己从工人或 lambda 或其他任何东西中弹出，并试图以他们的方式访问其他事物，那么就没有什么可取的了。 所以安全性也很重要，所以再次强调，如果这是你作为服务器管理员的工作，那就是处理这件事的安全性。 运行它，在 Lambda 中运行某些东西，你会从中获得一些自然的安全性，这很棒。 所以，便宜多了。 这样更安全。 它鼓励这些小型模块化架构，这可能是一个好主意。 好主意的多米诺骨牌在这里似乎是多米诺骨牌。 这就是它引人注目的原因。 你懂的？

Drew：是的，我的意思是，传统上我们已经在网络上运行了几十年的基于服务器的架构，你有一个你自己运行的网络服务器。 它包含您的前端代码、后端代码、数据库和所有内容。 然后你需要维护它并让它运行并支付账单，即使它没有被使用，它也在那里计时。 用户会发出一个请求，它会从数据库中构建所有 HTML 查询内容，然后将其全部发送到浏览器。 这个过程有效。 这就是大量事物的构建方式。 这可能是构建 Web 的主要方式。 这就是 WordPress 之类的工作方式。 这真的是我们需要解决的问题吗？ 我的意思是，我们已经谈到了一些成本。 还有什么其他问题，我们……我们需要解决，无服务器可能会帮助我们？

克里斯：是的，老派方法的问题。 是的，我不知道，也许没有。 我的意思是，我并不是说整个网络需要在一夜之间改变他们的整体……整个事情。 我不知道。 也许它不是真的，但我认为它打开了大门。 看起来，当好的想法像这样出现时，它们只是慢慢地改变了网络的运作方式。 所以，如果有一些 CMS 以某种方式构建，期望数据库在那里，这意味着未来的主机可能会开始以有趣的方式利用它。 也许你觉得它仍然只是一个传统的服务器，但是主机本身已经将它、它们的运行方式、到无服务器架构中。 所以你甚至不知道这种情况正在发生，但他们已经找到了一种方法来通过以无服务器方式托管你需要的东西来削减成本。 也许是的，作为开发人员甚至不需要关心，但在元层面上，这就是正在发生的事情。 可能是。 我不知道。

克里斯：这也不意味着……数据库仍然存在。 如果事实证明在架构上拥有一个关系数据库是存储该数据的正确方法，那就太好了。 我提到这一点是因为这个无服务器世界与 JAMstack 是同时成长起来的。 JAMstack 是这样一种架构，“你应该从静态主机上为你的网站提供服务，除了……之外什么都不运行。”它们就像小型 CDN。 他们就像，“我无能为力。 我不运行 PHP。 我不运行 Ruby。 我什么都不跑。 我在一个很小的 ​​Web 服务器上运行，该服务器仅设计用于提供静态文件。”

克里斯： “然后，如果你需要做的不止这些，如果你需要从关系数据库中提取数据，那么请在其他时间做，而不是在服务器时间。 你可以提前在构建过程中完成，然后将这些东西从数据库中提取出来，预先构建静态文件，我会为这些文件提供服务，或者在运行时完成。” 这意味着你得到了一个文档的外壳，然后它发出一个 JavaScript 请求来获取一些数据并预填充它。 因此，您可以提前或之后进行，但这并不意味着“不要使用关系数据库”。 它只是意味着，“不要让服务器在请求文档时生成它”，这是一个……我不知道，这有点范式转变。

克里斯：不仅仅是 JAMstack。 我们也生活在 JavaScript 框架时代。 我们生活在一个人们开始期待 JavaScript 应用程序启动方式的时代，即它安装一些组件，并且随着这些组件的安装，它会请求它需要的数据。 因此，对于像 React 网站这样的东西来说，它可能是一种很自然的选择，“好吧，我只需点击一个无服务器函数来获取它需要的数据。 它本质上是一些 JSON API。 我得到了我需要的 JSON 数据，并根据这些数据构建了自己，然后渲染到页面上。” 现在，无论这对网络是好是坏，就像，“我不知道。 太糟糕了。 船已经航行了。 这就是很多人建造网站的方式。” 这只是客户端渲染的东西。 因此，无服务器和现代 JavaScript 是齐头并进的。

德鲁：我想你不必批发……看一种或另一种建筑。 中间有一个区域，基础设施的一部分可能更传统，而部分可能是无服务器的，我猜？

克里斯：是的。 好吧，无论如何，他们都想告诉你。 任何想把他们建筑的任何部分卖给你的人都会说，“你现在不用买了。 就做一点点。” 因为当然，他们希望您将脚趾浸入他们出售的任何东西中，因为一旦您将脚趾浸入水中，您将自己溅入游泳池的机会就会高得多。 所以，我认为……这不是谎言，虽然，必然，虽然我发现运气不太好……我不希望我的筹码成为一切的一点点。 我认为那里有一些我并不总是想吞下的技术死亡。

德鲁：嗯（肯定）。

克里斯：但有可能做到。 我认为引用最多的一个是……假设我有一个包含电子商务元素的网站，这意味着……假设是大规模电子商务，所以有 10,000 种产品或其他东西，这个 JAMstack 架构还没有达到静态重建它总是特别有效。 所以，想法是，“那就不要”。 让那部分自然水合物......点击无服务器功能并获取它需要的数据，然后做所有这些。 但是网站的其余部分，不是……没有那么多页面，没有那么多数据，你可以预渲染或其他什么。 所以两者都有一点。

Drew：当然，很多人都在处理遗留系统……一些建于 2000 年代的旧数据库东西，他们可能能够在上面粘贴某种 JSON API 层……

克里斯：是的。

Drew： ……并构建更现代的东西，也许是无服务器的，然后仍然通过以一种奇怪的方式将它们完全粘合起来与这些遗留系统交互。

克里斯：是的。 不过我喜欢这样，不是吗？ 不是……大多数网站已经存在。 我们中有多少人是完全绿色的网站？ 我们大多数人都在处理一些已经存在但出于某种原因需要被拖到未来的垃圾，因为我不知道，开发人员想要更快地工作，或者你不能再雇用 COBOL 中的任何人，或者其他任何故事是。 你懂的？

Drew：从术语上讲，我们谈论的是 JAMstack，这是一种在浏览器中运行代码的方法，从 CDN 提供服务。 因此，服务器上没有任何动态。 然后当我们谈论无服务器时，我们谈论的是在其他地方的服务器上运行的那些小功能。 那正确吗？ 我们正在谈论这些云功能——

克里斯：是的，我的意思是，它们现在恰好是两种热门想法。 因此，谈论一个并谈论另一个很容易。 但他们不一定需要在一起。 您可以运行一个与无服务器无关的 JAMstack 站点。 您只是在这样做，您只需预先构建站点并运行它，您就可以使用无服务器而无需关心 JAMstack。 事实上，CodePen 根本不做 JAMstack。 并不是说我们一定要谈论 CodePen，但它是一个 Ruby on Rails 应用程序。 它在一大堆 AWS EC2 实例和各种其他架构上运行以实现它。 但是我们尽可能使用无服务器的东西，因为它便宜又安全，而且是一种很好的工作方式。 因此，根本没有使用 JAMstack，但到处都是无服务器的。

德鲁：这很有趣。 您在 CodePen 上放置了哪些无服务器任务？

克里斯：嗯，有很多东西。 其中之一是，我认为，希望相当明显的是，我需要...... CodePen 的重点是你在浏览器中编写每个 HTML、CSS 和 JavaScript，它会呈现在你面前，对吧？ 但是您也可以选择预处理器语言。 假设你喜欢 Sass。 您在 CSS 中打开 Sass，然后编写 Sass。 好吧，有些东西必须处理 Sass。 这些天来，Sass 是用 Dart 或其他东西编写的。

克里斯：理论上，你可以在客户端中做到这一点。 但是这些进行预处理的库非常大。 我不认为我想把整个 Sass 库发给你，只是为了运行那个东西。 我不想......它只是不是，这必然不是正确的架构。 也许它在路上，我的意思是，我们可以谈论离线废话，yada，yada，Web Workers。 我们可以做一百万种建筑方面的事情。 但这就是它现在的工作方式，是否有 lambda。 它处理 Sass。 它有一个微小的、微小的、微小的、微小的工作。

Chris：你把这个 Sass 的 blob 发给它，它把东西发回给你，这是经过处理的 CSS，可能是一个站点地图，等等。 它有一个很小的工作，我们可能会为那个 lambda 支付，比如 4 美分或其他东西。 因为 lambdas 非常便宜，你也可以锤击它。 您不必担心规模。 您只需随心所欲地打那个东西，您的账单就会便宜得惊人。 有些时候，无服务器开始越过过于昂贵的界限。 我不知道那是什么，我不是那种东西的大师。 但一般来说，我们所做的任何无服务器的东西，我们基本上……几乎都算免费的，因为它很便宜。 但是 Sass 有一个。 有一个少。 有一个给巴贝尔的。 TypeScript 有一个。 有一个用于……所有这些都是我们运行的单个 lambda。 这是一些代码，把它交给 lambda，它会回来，然后我们就可以用它做任何事情。 但我们使用它的用途远不止于此，即使是最近。

克里斯：这是一个例子。 CodePen 上的每一支 Pen 都有一个屏幕截图。 这有点酷，对吧？ 因此，人们制作了一个东西，然后我们需要一个 PNG 或 JPEG 或类似的东西，这样我们就可以……这样，当你发推文时，你会得到它的小预览。 如果你在 Slack 中分享它，你会得到它的小预览。 我们在网站本身上使用它来渲染……而不是 iframe，如果我们可以检测到 Pen 没有动画，因为 iframe 的图像要轻得多，那么为什么不使用图像呢？ 反正也不是动画。 只是这样的性能提升。 因此，显然，这些屏幕截图中的每一个都有一个 URL。 我们已经对其进行了架构，以便该 URL 实际上是一个无服务器功能。 是一名工人。 因此，如果该 URL 被点击，我们可以非常快速地检查我们是否已经截取了该屏幕截图。

Chris：这实际上是由 CloudFlare Workers 启用的，因为 CloudFlare Workers 不仅仅是一个无服务器功能，而且它们也有一个数据存储。 他们有一个叫做键值存储的东西，所以它的 ID，我们可以快速检查，它会是，“真假，你有没有？” 如果它得到它，它会为它服务。 它通过 CloudFlare 提供服务，一开始就超级快。 然后也给你所有这些能力。 因为它是一个图像 CDN，你可以说，“好吧，以最佳格式提供它。 把它当作这些维度来服务。” 我不必制作这些尺寸的图像。 您只需将尺寸放在 URL 中，它就会神奇地返回该尺寸。 所以这真的很好。 如果没有它，它会要求另一个无服务器功能使其变得非常快。 所以它会成功，然后把它放在某个桶里……因为你必须有图像的来源，对吗？ 您通常必须将其实际托管在某个地方。 因此，我们很快将其放入 S3 存储桶中，然后提供服务。

克里斯：所以没有排队服务器，什么都没有。 就像无服务器功能管理这些图像的创建、存储和服务一样。 大约有 5000 万或 8000 万个。 它很多，因此它可以很好地处理规模。 我们只是不碰它。 它只是发生。 这一切都发生得非常快。 超好。

Drew：我猜是这样……好吧，无服务器功能非常适合需要很少了解事物状态的任务。 我的意思是，您提到了 CloudFlare 存储键值对的能力，以查看您是否已经缓存了某些内容。

克里斯：是的。 不过，这就是他们试图解决的问题。 那些键值对是……我认为传统上是正确的。 他们就像，“避免事物中的状态”，因为你不能指望它。 CloudFlare Workers 就像，“是的，实际上，你可以在某种程度上处理状态。” 它不像……我不知道，它是键值，所以它是值中的键。 它不像一个嵌套的、关系性的花哨的东西。 所以可能有一些限制。 但这是婴儿的日子。 我认为这些东西会变得更强大，所以你确实有能力做一些类似状态的东西。

德鲁：有时限制，那种维持状态的有限能力，或者你没有......你根本不想维持任何状态的事实，有点推动你进入一个给你这种......好吧，当我们谈论“小块松散连接”的软件理念，不是吗？

克里斯：嗯（肯定的）。

德鲁：每个小组件都做一件事并且做得很好。 并且并不真正了解它周围的其他生态系统。 似乎这确实适用于无服务器功能的概念。 你同意吗？

克里斯：是的。 我认为无论这是否是一个好主意，您都可以进行哲学辩论。 你懂的？ 我认为有些人喜欢单体应用。 我认为有可能……有办法过度这样做，并制造太多难以完全测试的小部件。 很高兴有这样的测试，“哦，我想知道我的 Sass 函数是否正常工作。 好吧，让我们为它写一个小测试，并确保它是。” 但是让我们说，对用户来说重要的是其中的七个字符串。 你如何一起测试所有七个？ 我觉得这个故事有点复杂。 我不知道如何以超级智能的方式与所有这些东西交谈，但我知道这不一定是这样，如果你使用所有无服务器功能，那么它会自动成为比任何其他架构更好的架构。 我喜欢。 这对我来说很有道理，但我不知道这是所有架构的最终目的。 你懂的？

Drew：对我来说，它感觉非常像网络，因为……这正是 HTML 的工作原理，不是吗？ 您提供一些 HTML，然后浏览器将去获取您的图像并获取您的 JavaScript 并获取您的 CSS。 这似乎是它的扩展——

克里斯：很好。

德鲁： ……有点想法。 但是，我们对网络了解的一件事是，它被设计为具有弹性，因为网络很脆弱。

克里斯：嗯（肯定的）。

Drew：这种无服务器方法有多强大？ 如果有什么……如果其中一个小碎片消失了，会发生什么？

克里斯：那会很糟糕。 你懂的？ 这将是一场灾难。 我猜你的网站会像任何其他服务器一样宕机，如果它碰巧宕机了。

德鲁：有没有办法减轻这种情况，特别是——

克里斯：我不知道。

德鲁： ……适合这种方法，你遇到过吗？

克里斯：也许吧。 我的意思是，就像我说的，一个真正超级花哨的健壮的东西可能是……假设您访问 CodePen，假设有一个 Sass 的 JavaScript 实现，我们注意到您在一个相当快的网络上并且您处于空闲状态现在。 也许我们会去拿那个 JavaScript，然后把它扔给一个服务工作者。 然后，如果我们检测到 lambda 失败，或者其他什么，或者您已经安装了这个东西，那么我们将使用 service worker 而不是 lambda，并且 service worker 能够离线工作。 所以，这也不错。 那很有意思。 我的意思是，它们是同一种语言。 服务工作者是 JavaScript，很多云函数都是 JavaScript，所以有一些......我认为这是一种可能性，虽然......只是，这是一些严肃的技术......它只是让我害怕拥有你交付的这段 JavaScript对于成千上万的用户，您不一定知道他们拥有什么，以及他们拥有什么版本。 Eww，但这只是我自己的恐惧。 我敢肯定，有些人在这类事情上做得很好。

克里斯：我其实不知道。 也许你知道一些我不知道的关于无服务器弹性的策略。

Drew：我猜有一种失败模式，一种失败风格，这可能发生在无服务器函数中，你运行一个函数一次失败，然后你可以立即再次运行它，它会成功，因为它可能会命中完全不同的服务器。 或者无论问题是什么，当第二个请求可能不存在该运行时。 整个主机停机的问题是一回事，但也许有……你的机器有个别问题。 你有一个特定的服务器，它的内存已经坏了，它抛出了大量的错误，当你第一次点击它时，它就会失败。 第二次，这个问题可能已经根深蒂固。

克里斯：倾向于提供这种技术的公司，你必须信任他们，但他们也恰好是那种公司……这是他们的骄傲。 这就是人们使用它们的原因是因为它们是可靠的。 我敢肯定，人们可能会指出过去的一些 AWS 中断，但它们往往有点少见，而且不是很常见。 如果您是在托管自己的垃圾，我敢打赌，他们会让您从 SLA 百分比的水平上被击败。 你懂的？ 所以这并不是说“不要以一种有弹性的方式建设”，但通常提供这些东西的公司类型非常可靠。 你因为搞砸了那个功能而失败的机会比因为他们的架构失败而失败的机会要高得多。

Drew：我想，我的意思是，就像任何你使用 API 或可能失败的东西一样，只是确保你构建你的代码以应对这种失败模式，并知道接下来会发生什么，而不是仅仅抛出给用户一个错误，或者只是快死了，或者你有什么。 它意识到这一点并要求用户再试一次。 或者自己再试一次，或者别的什么。

克里斯：是的，我喜欢尝试不止一次的想法，而不仅仅是“哦，不。 失败。 中止。” “我不知道，你为什么不在那里再试一次，伙计？”

Drew：所以我的意思是，当涉及到无服务器功能的测试和开发时，比如云功能，可以在本地完成吗？ 必须在云端完成吗？ 有办法管理吗？

克里斯：我认为有一些方法。 不知道这个故事是不是很精彩。 它仍然是一个相对较新的概念，所以我认为它会变得越来越好。 但据我所知，一方面，您正在编写一个相当普通的 Node 函数。 假设您使用 JavaScript 来执行此操作，并且我知道特别是在 Lambda 上，它们支持各种东西。 您可以编写一个有趣的 PHP 云函数。 您可以编写一个 Ruby 云函数。 所以，我知道我是在专门谈论 JavaScript，因为我有一种感觉，这些东西大部分都是 JavaScript。 我的意思是，无论它是什么语言，您都可以在本地转到命令行并执行该操作。 其中一些测试是……您只需像测试任何其他代码一样测试它。 您只需在本地调用该函数并查看它是否有效。

Chris：当您谈论对它的 HTTP 请求时，情况就有些不同了，这就是您要测试的东西。 它是否正确响应请求？ 它是否正确返回了这些东西？ 我不知道。 网络可能会参与其中。 因此，您可能希望在该级别编写测试。 没关系。 我不知道。 那里的正常故事是什么？ 您启动某种本地服务器或为其提供服务的东西。 使用邮递员，我不知道。 但是有……框架也试图提供帮助。 我知道无服务器“.com”非常令人困惑，但实际上有一家名为 Serverless 的公司，他们为编写无服务器功能创建了一个框架来帮助您部署它们。

Chris：所以如果你喜欢 NPM install serverless，你会得到他们的框架。 它被广泛认为非常好，因为它非常有帮助，但他们没有自己的云或其他任何东西。 你编写这些，然后它可以帮助你把它们变成一个真正的 lambda。 或者它可能与多个云提供商一起使用。 这些天我什至不知道，但他们存在的目的是使部署故事更容易。 我不知道是什么…… AWS 并不以简单而闻名。 你懂的？ 有很多工具可以帮助您使用 AWS，它们就是其中之一。

克里斯：他们有某种付费产品。 我什至不知道它到底是什么。 我认为他们所做的其中一件事是……使用它们的目的是为了测试，是为了拥有一个用于测试无服务器功能的开发环境。

德鲁：是的，因为我猜这是工作流程中相当大的一部分，不是吗？ 如果您已经编写了 JavaScript 函数，并且已经在本地对其进行了测试，那么您就知道它会完成这项工作。 您如何实际选择它将进入哪个提供商以及如何将其用于该服务？ 现在，我的意思是，那是一个雷区，不是吗？

克里斯：是的。 我的意思是，如果你根本不想使用任何工具，我认为他们有一个非常……特别是像 AWS，有一个非常基本的 GUI。 You can paste the code in there and hit save and be like, “Okay, I guess it's live now.” That's not the best dev story, but I think you could do it that way. I know CloudFlare workers have this thing called Wrangler that you install locally. You spin it up and it spins up a fake browser on the top and then dev tools below. Then you can visit the URL and it somehow intercepts that and runs your local cloud function against it. Because one of the interesting things about workers is… you know how I described how it… you don't hit a URL and then it returns stuff. It just automatically runs when you… when it intercepts the URL, like CDN style.

Chris: So, one of the things it can do is manipulate the HTML on the way through. The worker, it has access to the complete HTML document. They have a jQuery-esque thing that's like, “Look for this selector. Get the content from it. Replace it with this content. And then continue the request.” So you can mess with code on the way through it. To test that locally, you're using their little Wrangler tool thing to do that. Also, I think the way we did it was… it's also a little dangerous. The second you put it live, it's affecting all your web traffic. 这是一件大事。 You don't want to screw up a worker. 你懂的？ You can spin up a dev worker that's at a fake subdomain, and because it's CloudFlare, you can… CloudFlare can just make a subdomain anyway. 我不知道。 It's just kind of a nice way to do a… as you're only affecting sub-domain traffic, not your main traffic yet. But the subdomain's just a mirror of a production anyway, so that's kind of a… that's a testing story there.

Chris: It brings up an interesting thing, though, to me. It's like… imagine you have two websites. One of them is… for us it's like a Ruby on Rails app. 任何。 It's a thing. But we don't have a CMS for that. That's just like… it's not a CMS, really. I think there's probably Ruby CMSs, but there's not any renowned ones. 你懂的？ It seems like all the good CMSs are PHP, for some reason. So, you want a quality CMS. Drew, you've lived in the CMS market for a long time -

Drew: Absolutely.

Chris: … so you know how this goes. Let's say you want to manage your sites in Perch or whatever, because it's a good CMS and that's the proper thing to use to build the kind of pages you want to build. But you don't want to run them on the same server. Unless you want to manage the pages on one site, but show them on another site. Well, I don't know, there's any number of ways to do that. But one JavaScript way could be, “Okay, load the page. There's an empty div there. Run some JavaScript. Ask the other site for the content of that page and then plunk it out on the new page.” That's fine, I guess, but now you're in a client side rendered page. It's going to be slow. It's going to have bad SEO, because… Google will see it eventually, but it takes 10 days or something. It's just a bad story for SEO. It's not very resilient, because who knows what's going to happen in the network. It's not the greatest way to do this kind of “content elsewhere, content on site B, show page of site A”, situation.

Chris: You could also do it on the server side, though. Let's say you had… Ruby is capable of granting a network request too, but that's even scarier because then if something fails on the network, the whole page could die or something. It's like a nervous thing. I don't love doing that either. But we did this just recently with a worker, in that we… because the worker's JavaScript, it can make a fetch request. So, it fetches site A, it finds this div on the page, and then it goes and asks site B for the content. Gets the content. Plugs it into that div, and serves the page before it gets anything. So it looks like a server rendered page, but it wasn't. It all happened at the… on the edge, at the worker level, at the serverless level.

Chris: So it's kind of cool. I think you can imagine a fetch request on the browser probably takes, I don't know, a second and a half or something. It probably takes a minute to do it. But because these are… site B is hosted on some nice hosting and Cloudflare has some… who knows what kind of super computers they use to do it. 他们是这样。 Those are just two servers talking to each other, and that fetch request happens just so super duper, duper fast. It's not limited to the internet connection speed of the user, so that little request takes like two milliseconds to get that data. So it's kind of this cool way to stitch together a site from multiple sources and have it feel like, and behave like, a server rendered page. I think there's a cool future to that.

Drew: Are there any sort of conventions that are sort of springing up around serverless stuff. I'm sort of thinking about how to architect things. Say I've got something where I want to do two sort of requests to different APIs. I want to take in a postal address and geocode it against one, and then take those coordinates and send that to a florist who's going to flower bomb my front yard or something. How would you build that? Would you do two separate things? Or would you turn that into one function and just make the request once from the browser?

Chris: Mm (affirmative). That's a fascinating question. I'd probably have an architect function or something. One function would be the one that's in charge of orchestrating the rest of them. It doesn't have to be, your website is the hub and it only communicates to this array of single sources. Serverless functions can talk to other serverless functions. So I think that's somewhat common to have kind of an orchestrator function that makes the different calls and stitches them together, and returns them as one. I think that is probably smart and faster, because you want servers talking to servers, not the client talking to a whole bunch of servers. If it can make one request and get everything that it needs, I think that's probably generally a good idea-

Drew: Yeah, that sounds smart. 是的。

Chris: But I think that's the ultimate thing. You get a bunch of server nerds talking, they'll talk about the different approaches to that exact idea in 10 different ways.

德鲁：是的。 No, that sounds pretty smart. I mean, you mentioned as well that this approach is ideal if you're using APIs where you've got secret information. You've got API keys or something that you don't want to live in the client. Because I don't know, maybe this florist API charges you $100 dollars every time flower bomb someone.

Chris: Easily.

Drew: You can basically use those functions to almost proxy the request and add in the secret information as it goes, and keep it secret. That's a viable way to work?

Chris: Yeah, yeah. 我想是这样。 I mean, secrets are, I don't know, they're interesting. They're a form of buy in I think to whatever provider you go with, because… I think largely because of source control. It's kind of like, you could just put your API key right in the serverless function, because it's just going to a server, right? You don't even have to abstract it, really. The client will never see that code that executes, but in order for it to get there, there's probably a source control along the way. It's probably like you commit to master, and then master… then some kind of deployment happens that makes that thing go to the serverless function. Then you can't put your API key in there, because then it's in the repo, and you don't put your API keys in repos. 这是个好建议。 Now there's stuff. We've just done… at CodePen recently, we started using this git-crypt thing, which is an interesting way to put keys safely into your repos, because it's encrypted by the time anybody's looking at that file.

Chris: But only locally they're decrypted, so they're useful. So it's just kind of an interesting idea. I don't know if that helps in this case, but usually, cloud providers of these things have a web interface that's, “Put your API keys here, and we'll make them available at runtime of that function.” Then it kind of locks… it doesn't lock you in forever but it kind of is… it's not as easy to move, because all your keys are… you put in some input field and some admin interface somewhere.

Drew: Yeah, I think that's the way that Netlify manage it.

Chris: They all do, you know?

德鲁：是的。 You have the secret environment variables that you can set from the web interface. That seems to work quite nicely.

Chris: Yeah, right. But then you got to leave… I don't know, it's not that big of a deal. I'm not saying they're doing anything nefarious or anything. How do you deal with those secrets? Well, it's a hard problem. So they kind of booted it to, I don't know, “Just put them in this input field and we'll take care of it for you, don't worry about it.”

Drew: Is there anything that you've seen that stands out as an obvious case for things that you can do with serverless, that you just couldn't do with a traditional kind of serverfull approach? Or is it just taking that code and sort of almost deploying it in a different way?

Chris: It's probably mostly that. I don't know that it unlocks any possibility that you just absolutely couldn't run it any other way. Yeah, I think that's a fair answer, but it does kind of commoditize it in an interesting way. Like, if somebody writes a really nice serverless function… I don't know that this exists quite yet, but there could kind of a marketplace, almost, for these functions. Like, I want a really good serverless function that can take a screenshot. That could be an open source project that lots of eyeballs around, that does a tremendously good job of doing it and solves all these weird edge cases. That's the one I want to use. I think that's kind of cool. 你懂的？ That you can kind of benefit from other people's experience in that way. I think that will happen more and more.

Drew: I guess it's the benefit that we talked about, right at the top, of enabling people who write JavaScript and may have written JavaScript only for the front-end, to expand and use those skills on the back-end as well.

克里斯：是的，是的。 我想是的，我认为那是……因为有些时候……您不必非常熟练地知道什么是合适的，什么不适合网站。 就像，前一周我做了一个小教程，有这个故障的地方使用这些......当你保存一个故障时，他们会给你一个你建造的东西的蛞蝓，那就是，“威士忌，探戈，狐步舞。 1000 个。” 这就像一个聪明的小东西。 它独特的机会非常高，因为我认为他们甚至会在其上附加一个数字或其他东西。 但它们最终变成了这些有趣的小东西。 他们开源了包含所有这些单词的库，但它就像一百、数千个单词。 文件很大。 你懂的？ 它只是一个单词字典的兆字节大。 您可能在开发的第一年就学会了“不要发布一个字典大小为 MB 的 JavaScript 文件”。 这不是一件好事。 你懂的？ 但是 Node 不在乎。 您可以运送数百个。 它与服务器上的速度无关。

德鲁：是的。

克里斯：在服务器上没关系。 所以，我可能会说，“嗯，好吧，那我就用 Node 来做吧。” 我将有一个声明说，“单词相等需要单词”或其他任何内容，并在顶部添加一个注释，“让它随机化一个数字。 将其从阵列中拉出并归还。” 因此，无服务器功能是八行代码，带有一个打包的@JSON，可以引入这个开源库。 然后是我的前端代码，有一个无服务器函数的 URL。 它点击了那个 URL。 URL 返回一个单词或一组单词或其他任何内容。 你为它构建了自己的小 API。 而现在，我有一个非常好的、高效的东西。 这样做的好处是，它是如此简单。 我不担心它的安全性。 我不……你知道吗？

Chris：这只是……我认为，一个非常普通或初学者的 JavaScript 开发人员可以做到这一点，这很酷。 这是他们以前没有的使能的东西。 之前，他们会说，“嗯，这是一个 2MB 的单词数组。” “哦，我不能把那个寄给客户。” “哦，那你就关机吧。” 你可能会碰到这堵墙，就像，“那时我不能做那部分。 我需要请其他人帮助我，或者干脆不做，或者选择更无聊的蛞蝓或其他一些……”只是，你必须走其他对你来说是一堵墙的路，因为你做不到。 而现在，你会说，“哦，好吧，我就……”我不会把它放在我的脚本斜杠或我的源斜杠脚本文件夹中，而是把它放在我的函数文件夹中。

克里斯：你有点像将脚本从一个文件夹移到另一个文件夹。 而那个恰好被部署为无服务器功能。 多么酷啊？ 你懂的？ 你几乎使用了相同的技能。 它仍然有一些粗糙的边缘，但它非常接近。

德鲁：太酷了。 你已经建立了一个关于这些想法的小型微型网站，不是吗？

克里斯：是的。 我参加比赛有点早。 不过，我今天只是在处理它，因为……它会收到拉取请求。 这个想法......嗯，它在 serverless.css-tricks.com 并且......顺便说一句，CSS-Tricks 中有一个破折号。 所以它是 CSS-Tricks 的一个子域，我也无服务器地构建了它，所以这是…… CSS-Tricks 就像一个 WordPress 站点，但这是一个静态站点生成器站点。 它的所有内容都在开源的 GitHub 存储库中。 所以如果你想改变网站的内容，你可以提交一个投票请求，这很好，因为随着时间的推移已经有一百个左右。 但我构建了所有原始内容。

Drew：这是一个非常有用的地方，因为它列出了......

克里斯：就是这样，几乎就是技术列表。 是的。

德鲁：这很好，因为否则，你只是在谷歌上搜索，你不知道你在寻找什么。 是的，它是帮助你做这些事情的 API 提供者的列表。

克里斯： Forms 就是其中的一个例子，因为……所以当你选择……假设你要去 JAMstack，我知道这不一定是重点，但你会看到它们是如何携手并进的. 突然之间，您没有 PHP 文件或任何可以用来处理该表单的文件。 你如何在 JAMstack 网站上做表格？ 好吧，有很多方法可以做到这一点。 显然，每个人和他们的姐姐都想帮助你解决这个问题。 所以我想如果我是 JAMstack 这个词的发明者，那么他们自然会尝试帮助你，但你不必使用它们。

克里斯：事实上，我很惊讶把这个网站放在一起。 让我们来看看。 现在有六、九、十二、十五、十八、二十一、二十二个服务，它们希望帮助您立即在此站点上无服务器地处理您的表单。 如果你想成为第 23 名，欢迎你，但你有一些竞争。 所以这背后的想法是你用 HTML 编写一个表单，就像字面上的表单元素一样。 然后是表单的action属性，它内部不能指向任何地方，因为没有什么可以指向的。 你不能处理，所以它指向外部。 它指向他们想要你指向的任何东西。 他们将处理表单，然后他们倾向于做您希望他们做的事情，例如发送电子邮件通知。 或者发送一个 Slack 的东西。 或者然后将其发送到 Zapier，然后 Zapier 会将其发送到其他地方。 他们都有略微不同的功能集、定价和东西，但他们都在努力为你解决这个问题，比如，“你不想处理自己的表单吗？ 没问题。 我们会为您处理。”

德鲁：是的，这是一个超级有用的资源。 我真的建议大家去看看。 它是 serverless.css-tricks.com。 所以，我一直在学习关于无服务器的一切。 克里斯，你最近在学习什么？

克里斯：嗯，我仍然非常喜欢这个世界，并且正在学习无服务器的东西。 我有个主意……我很久以前玩过这个在线角色扮演游戏。 我最近才发现它还活着。 这是一款基于文本的中世纪奇幻游戏。 我在 AOL 成立的时候玩过它，因为 AOL 想要这些游戏，你必须登录才能玩它，因为他们希望你在 AOL 上花费数小时和数小时，这样他们就可以向你发送巨额账单，这是，我敢肯定，为什么他们在某些时候做得这么好。

德鲁：所以按秒计费。 是的。

克里斯：是的。 所以游戏对他们来说很重要。 如果他们能让你在那里和其他人一起玩游戏。 所以这款游戏有点……它并没有在那里首次亮相，但它转移到了 AOL，因为我确信他们得到了一个多汁的交易，但它是如此……我的意思是，它只是，不可能更书呆子了。 你是一个矮人法师，你会从你的皮鞘中得到符文法杖。 你可以像终端一样在其中输入命令。 然后游戏会回应你。 我玩那个游戏很长时间了。 我非常喜欢它。 我进入了它的社区和它的精神。 这有点……就像我一个人在我的电脑前，但我回顾我生命中的那段时光，就像，“那是我生命中美好的时光。” 我真的……我只是喜欢这里的人和游戏等等。 但后来我长大了，不再玩它了，因为生活发生在你身上。

克里斯：我最近才知道，因为有人又开始做播客了……我不知道我是怎么知道的，但我就是这么做的。 我当时想，“这个游戏在当今世界还很活跃，你在开玩笑吗？ 这个基于文本的东西。” 而且我非常高兴能够重新激活并让我的旧角色回归并播放它。 但只是发现他们为这个游戏下载的客户端根本没有发展。 他们很糟糕。 他们几乎假定您使用的是 Windows。 只有这些非常俗气的糟糕渲染......而且它是基于文本的，你认为它至少有很好的排版。 不，所以我想，“我可以参与其中。 我可以为这个游戏写一个客户端。 把漂亮的字体放进去。” 只是把它现代化，我认为游戏的玩家会喜欢它，但它让我感到不知所措。 “我该怎么做？” 但是我发现了一些开源项目。 其中之一就像……你可以通过一个实际的终端窗口玩游戏，它使用一些开源库从终端窗口中制作一个 GUI。

德鲁：真的吗？

克里斯：我不知道。 所以这有点酷。 我当时想，“如果他们写了那个，那里面肯定有代码来说明如何连接到游戏并让一切顺利进行之类的。 所以至少我有一些入门代码。” 我试图使用这个应用程序，“也许我会用 Flutter 或其他什么东西来做”，所以最终的产品应用程序可以在手机上运行，​​“我真的可以让这个东西现代化。” 但后来我不知所措。 我当时想，“啊，这太大了……我不能。 我很忙。” 但我找到了另一个有同样想法的人，他们的想法更进一步，所以我可以在设计层面做出贡献。 工作真的很有趣，但我也学到了很多东西，因为我很少投入到别人喜欢的项目中，而我只是贡献了一点点，这完全不同比我曾经选择的技术选择。

克里斯：这是一个电子应用程序。 他们选择了那个，这也是一种很酷的方式，因为这是我的网络技能……所以我没有学任何太奇怪的东西，而且它是跨平台的，这很棒。 所以，我一直在学习很多关于 Electron 的知识。 我认为这很有趣。

德鲁：这很有趣。 令人惊讶的是，我们为了好玩而做的一些小项目和事情，最终成为我们有时学习最多的地方。 并学习可以反馈到我们日常工作中的技能。

克里斯：这是我学习东西的唯一途径。 我被卷入了一些……我当时想，“他们不是……”它是用一个名为 Mithril 的 JavaScript 库呈现的，它是……我不知道你是否听说过它，但这很奇怪。 不是……这几乎就像在没有 JSX 的情况下编写 React。 你必须“创造元素”并做所有这些……但它应该比它更好地进行基准测试……而且它实际上很重要，因为在这个基于文本的游戏中，文本只是在飞行。 有很多数据操作，就像……你会认为这个基于文本的游戏对于浏览器窗口来说很容易运行，但实际上并非如此。 发生了如此多的数据操作，你真的必须真的……我们必须认真对待渲染的速度。 你懂的？

德鲁：这很迷人——

克里斯：很酷。

德鲁：是的。 亲爱的听众，如果您想从 Chris 那里听到更多信息，您可以在 Twitter 上找到他，他是 @chriscoyier。 当然，CSS-Tricks 可以在 css-tricks.com 和 CodePen 在 codepen.io 上找到。 但最重要的是，如果您还没有订阅 ShopTalk Show 播客，我建议您在 shoptalkshow.com 上订阅。 感谢您今天加入我们，克里斯。 你有什么离别词吗？

克里斯： Smashingpodcast.com。 我希望这是真正的网址。