与 Leslie Cohn-Wein 合作的 Smashing Podcast 第 29 集：Netlify Dogfood The Jamstack 是如何实现的？

在这一集中，我们要问的是在 Netlify 对 Jamstack 进行测试是什么感觉。 您可以将整个应用程序部署到 CDN 吗？ Drew McLellan 与 Netlify 高级工程师 Leslie Cohn-Wein 交谈以找出答案。

显示注释

• 莱斯利的个人网站
• 莱斯利在推特上
• 网络化

每周更新

• 使用 react-three-fiber 深入 React 和 Three.js
  作者：财富池地
• 电子商务 UI 设计的最佳实践
  作者：苏珊娜·斯卡卡
• 使用 Auth0 对 React 应用程序进行身份验证
  由 Nefe Emadamerho-Atori 撰写
• 来自专家：COVID-19 期间的全球数字可访问性发展
  由罗宾克里斯托弗森撰写
• Vue 3 有什么新功能？
  蒂米·奥莫耶尼 (Timi Omoyeni) 撰写

成绩单

Drew McLellan：她是一位屡获殊荣的前端专家，最初来自奥斯汀，但现在住在德克萨斯州的达拉斯，并在纽约市工作过一段时间。 在代理机构工作期间，她为 Nintendo、WorldPride 和 Jerry Seinfeld 等客户建立了网站。 她现在是 Netlify 的一名前端工程师，除其他外，她致力于构建客户用于管理其服务和部署的应用程序。 所以，我们知道她是一位出色的前端工程师，但你知道吗，当她住在纽约市时，她连续三年担任辣椒烹饪助理裁判。 那是真的。 我的好朋友们，请欢迎莱斯利·科恩-韦恩。 嗨，莱斯利。 你好吗？

Leslie Cohn-Wein：我太棒了。

德鲁：我今天想和你谈谈 Netlify 是如何吃自己的狗粮的，当谈到在 Jamstack 上构建时，使用这种迷人的表达方式。 我应该稍微说明一下，直到几个月前，我们还在 Netlify 的同一个团队中一起工作。 当我到达那里时，开发过程对我来说真的很陌生，即使在做了 20 年的开发人员之后。 我认为这真的很吸引人，值得探索一下，有更广泛的观众。 我可能应该指出，我们正在讨论这个问题，因为它是一个真正有趣的案例研究，而且它不是 Netlify 的赞助大广告。 每个人都应该看看 Vercel。 但我认为从讨论中可以学到很多有价值的东西，特别是从 Jamstack 的角度来看。 因为 Netlify 是 Jamstack 方法的真正支持者，并且该服务是提供给客户的，并且是围绕构建 Jamstack 项目的想法构建的。 但是该服务本身也是使用这些原则构建的。 不是吗？

莱斯利：是的，是的。 很多人都认为 Jamstack 架构是静态站点，但我们真的在尝试用 Netlify 前端构建 Jamstack 应用程序的意义。 因为它是一个 React 应用程序，是一个完整的 Jamstack 应用程序，我们在 Netlify 上部署了 Netlify，所以……是的，我们真的在尝试它并推动可能的极限。

Drew：我认为有时有人认为 Jamstack 仅适用于静态站点，正如你所说，如果你想将表单发送到电子邮件地址，那么 API 方面就会出现，你可以做一些简单的事情，但是你可以这样构建一个完整的网络应用程序。 但是，你这样做不是吗？

莱斯利：是的，绝对的。 我们的应用程序，特别是在您登录 app.netlify.com 时所看到的内容，由……我们有一个内部 REST API 提供支持，但就像我说的，前端是纯 Jamstack。 所以，我们有自己的构建步骤，我们观察应用程序在应用程序中的构建，然后在我们自己的系统上进行部署。

Drew：所以，当涉及到后端进程时，总会有某种级别的后端进程，你知道，持久化数据，或者在 Netlify 的案例中，从部署开始，或者你有什么，那个后端只是某种被构建为一系列 API，然后可以被前端使用？

Leslie：是的，所以有几种不同的模型可以让你完成这项工作。 在大多数情况下，在我们的应用程序中，我们使用 React 的客户端获取，对吗？ 因此，我们为应用程序提供某种静态外壳，然后在请求时从内部 REST API 获取用户信息。 Jamstack 很有趣，因为您可以预先构建一些东西，我们尽可能地尝试并依赖它。 然后当我们谈论一些更动态的数据时，我们将使用客户端获取来确保我们正在提取最新的数据。

Drew：当我开始开发应用程序时，我觉得它让我感到惊讶，前端实现了多少，特别是在与外部 API 和事物交互方面。 我知道，当 Netlify 与您的 Git 提供程序交互时，它会转到 GitHub 并获取存储库列表，这一切都发生在您的浏览器和 GitHub 之间。 除了可能……通过一个无服务器功能，在请求上放置一些秘密或类似的轻量级功能，大部分只是以 Jamstack-y 的方式发生。 它没有通过 Netlify 类型的核心后端基础设施。 所以，这很吸引人。 这真的远远超出了一个静态站点，只需调用几个 API 来做一些小事。 这才是真正的核心功能，不是吗，正在浏览器中实现？

莱斯利：当然。 我认为，它确实推动了前端开发工程师的概念，对吧？ 作为一名前端工程师，这促使我变得更好，并更多地考虑这些……API 层，这不是我传统上所接近的东西。 我在 UI、颜色和设计系统方面工作得更多，所以真的……我发现大规模开发 Jamstack 应用程序，促使我成为一名更好的开发人员。

Drew：作为一名前端开发人员并不知道从头到尾的 CSS，尽管这是其中的一部分。 它不知道从头到尾的 HTML，但这是其中的一部分。 它也误入了这个传统上由后端工程师保留的领域，这很有趣。 Netlify 是否使用新的服务器端渲染 -

莱斯利：我不知道。

Drew：所以，这一切都只是字面上完成了，正如你所说，你提供一个 shell，然后它被填充到不同的 API 端点的请求，以填充它。

莱斯利：没错。

Drew：你说它是一个 React 应用程序？

莱斯利：是的。 是的。 做出反应。 我们现在使用 React Redux，现在我们是 PostCSS，但我们也在试验我们的 CSS 架构。

德鲁：我们不都是吗？ 那么，您在 React 中构建应用程序，然后将其部署在 Netlify 上？

莱斯利：是的。 也许整个过程中我最喜欢的部分是部署预览的魔力，我们通过 Netlify 获得了它。 所以，发生的事情是，你会……你在 GitHub 上工作，你推你的 PR。 因此，您在 GitHub 中打开您的 PR，这将自动创建应用程序的 Deploy Preview 的构建。 因此，我们实际上使用应用程序本身的 Deploy Previews 来进行测试，以确保一切正常。 我们运行我们的测试。 这就是我们在代码审查期间用来手动验证的内容。 所以，我们已经从 GitHub 上设置了所有的持续部署。

Leslie：然后我们设置的其他很酷的事情之一是，我们实际上有几个不同的 Netlify 站点，它们从我们的应用程序所在的同一个存储库中提取。 所以，我们有我们的应用程序，我们有一个 Storybook 的实例，它有我们的应用程序的 UI 组件。 所以，我们有我们的应用程序本身，我们有 Storybook UI 组件，我们基本上有一个 Netlify 站点来显示我们的 Storybook UI。 然后我们还有第三个站点运行 webpack 包分析器。 所以，它是一个可视化的 UI，它为您提供了一个树形图，所有应用程序包的可视化，我们可以衡量它们的大小，它只是提醒我们仔细检查。 随着应用程序的每次部署结束，我们可以检查并确保我们在那里的包大小没有做任何奇怪的事情。 因此，所有这三个站点都是在应用程序的一个拉取请求中生成的。 因此，您将获得应用程序 Storybook 和该应用程序配置文件的预览链接，本质上是您的部署预览，以供我们检查。

Drew：通过 Deploy Previews，这基本上成为了您的暂存环境，是吗？

莱斯利：没错。 我们并没有真正运行传统的暂存环境，因为我们真的相信，当我们点击合并按钮并在我们的主应用程序中启动我们的主分支的正式构建时，我们的部署预览基本上会上线。 所以，我喜欢我们可以依赖 Deploy Previews 作为暂存环境。 我们真的相信它将与生产相匹配。 我们正在使用所有生产变量构建它，一切……环境变量，所有这些东西都在部署预览中构建。 所以，这几乎就像一个无忧无虑的情况。 只要您的 Deploy Preview 正常工作，您就知道该应用程序也将正常工作。

Drew：我想，作为一个组织，如果您的 Deploy Preview 与发布的内容不匹配，那么这就是 Netlify 想要解决的服务问题。 因此，从这个角度来看，它实际上效果很好。 因此，您已经查看了部署预览，一切看起来都很棒，PR 被合并了。 那会发生什么？

Leslie：所以，因为 Netlify 运行我们所有的持续部署，本质上我们已经将它们全部连接起来，以便任何合并到我们的主分支中都会自动启动应用程序的正式生产部署。 因此，通常如果您是合并了您自己的 PR 的开发人员，您会弹出实际的……您必须确保仔细检查您的选项卡，因为如果您打开了应用程序的部署预览并且应用程序，你必须确保......你通常想在真实的应用程序中跟随。 所以，你必须检查你的标签。 但是，是的，在应用程序中，您通常会进入，您可以查看刚刚启动的合并的构建日志，因此这一切都是自动的。 然后，一旦这些构建日志完成，并且站点处于活动状态，您所要做的就是刷新浏览器窗口，您会看到刚刚部署的任何内容都应该在应用程序中更新。

德鲁：假设你发现问题一旦上线，你会怎么做？

莱斯利：这是一个非常好的问题。 也许在我在 Netlify 工作之前就使用 Netlify 是我最喜欢的事情之一，这对我来说有点神奇，因为 Netlify 已经融入了我们所说的回滚。 所以，基本上每次部署都在 Netlify 上……因为我们使用的是这种 Jamstack 架构，所以每次部署都是原子的。 因此，这意味着您拥有您在站点上进行的各种部署的完整历史记录，并且您可以立即回滚到其中的任何一个。 所以，如果我们不小心部署了一个错误或某些东西被破坏了，我们通常做的第一件事就是我们实际上停止了持续集成。 因此，我们将进入，它只是 Netlify UI 中的一个按钮，您说“停止自动发布”，然后它会停止与 GitHub 的连接。 所以，如果我的队友突然也合并了他们的 PR，我们不会重新引入这个 bug，这样的事情不会发生。

Leslie：所以，我们停止了所有这些自动部署。 然后我所要做的就是回到我的部署列表并找到最后一个有效的部署，再点击一个按钮，上面写着“发布这个”，它就会上线。 所以，这样做是为了减轻压力，才能真正返回，查看代码，弄清楚实际发生了什么。 有时这意味着在您的主分支上执行 Git 还原并将主分支恢复到需要的位置。 有时它是一个热修复，或者你在一个分支上得到修复，你甚至不需要担心在 Git 中恢复。 然后，当您准备好返回时，请确保一切都在您的应用程序的部署预览中正常运行，您可以将所有这些内容重新设置回来。 所以，一旦你开始这些自动部署，你基本上就恢复了业务。

Drew：所以，我在这里发现了一个问题。

莱斯利：哦哦。

Drew：您正在使用 Netlify 将更改部署到 Netlify 应用程序。 如果您部署的错误阻止您回滚怎么办？ 那你怎么办呢？

莱斯利：我做噩梦。 不。实际上，我们有几种方法可以解决这个问题。 因此，如果我们关闭应用程序并且我们不能使用 UI 来完成这个过程，我们的部署预览实际上是针对我们的生产 API 运行的。 所以，这意味着，即使应用程序不工作，我们仍然有这些原子部署。 因此，如果您有来自 GitHub 的链接，可能来自旧的或最近的 PR，并且您有该部署预览 URL，您实际上可以访问应用程序的部署预览并进行所需的任何更改，然后返回并发布较旧的部署从部署预览。 而且它仍然在影响我们的生产 API，所以它仍然会影响应用程序，然后这将使应用程序恢复正常。 这就像在那里爆炸的大脑表情符号，但这是一种方法。 我们还可以从我们的一些后端系统发布较旧的部署。 我们可以让我们的后端工程师为我们发布它。 或者你总是可以使用 Git 来恢复并尝试将其推高，但这有点吓人，因为你无法看到你在做什么。

德鲁：我想你只需要一个非常清晰的头脑来处理这种情况。

莱斯利：是的。

德鲁：但它是完全可以恢复的，听起来是这样。

莱斯利：是的。 好吧，一旦你发布了你的工作部署，所有的压力都消失了。 这真的是最好的部分。 我发现这也适用于代理机构。 能够回滚真的是一个救命稻草……它也让你不用担心发布新的变化。 如果您破坏了某些东西，则需要一秒钟才能将其回滚，这非常适合快速移动并将其取出的模型。

德鲁：当然。 我认为通常这种整个工作流程在您处理非常小的更改时效果最好。 我的意思是，理想情况下，您希望创建一个分支，实施一个小改动，提出一个 PR，然后尽快将其合并回来。 这显然适用于调整和错误修复以及一些小事情，但它不适用于主要功能工作，因为该功能可能需要数周甚至数月才能开始准备部署。 你如何管理这样的过程？

莱斯利：是的，这是一个很好的问题。 因此，我们最近开始更多地使用功能标志。 在我更多地谈论我们如何做到这一点之前，我将谈谈我们过去所做的事情。 所以，在我们使用特性标志之前，我想每个人都对长期运行特性分支的想法有点熟悉。 我们都讨厌他们，对吧？ 但我们会致力于我们较小的 PR。 在代码审查之后，我们会将其中的每一个单独合并到这个运行时间更长的功能分支中。 因此，您基本上将所有新功能都放在一个地方，您可以拥有一个部署预览版，您可以使用它来测试该新功能。 有时，这种模型需要跨其他团队进行协调部署。 所以，当我们准备说，“好的，这个功能分支，我们准备好合并它并让它上线”时，有时这意味着，“好的，你必须确保后端已经部署了他们的更改，”所以不管我们在功能中所做的 API 工作已准备就绪。 如果我们的文档网站上的文档需要与该功能同时上线，那么您必须同时协调并点击按钮。

Leslie：这个模型……它对我们有用，但你说得对，它可能不是最流畅的。 这实际上有点有趣，我们在 Netlify 的联合创始人兼首席执行官 Matt Biilmann 实际上在去年的 Jamstack Conf London 的舞台上使用这个过程推出了我们的分析功能。 因此，他使用我们的锁定部署功能基本上采用了分析新功能的部署预览并在舞台上实时发布。 所以，这很酷。

Leslie：但是，就像你说的，这是……你的信心少了一点。 一切仍然隐藏在这个拉取请求中。 它变得有点笨拙。 必须有人批准通常很大的最终拉取请求。 这有点压倒性。 所以，现在我们主要使用功能标志。 我们使用了一个名为 LaunchDarkly 的服务，它让我们基本上可以用这些标志来包装我们的新功能 UI，这样我们就可以不断地合并代码，即使 UI 不是我们希望客户看到的东西。 因此，您只需确保在生产环境中您的功能标志处于关闭状态，我们就可以部署代码、合并它，并且没有人……假设您是普通用户，您不会看到新的 UI。

Drew：所以，功能标志基本上就像代码中的一个开关，“如果启用此功能，请使用此新代码，否则使用此旧代码。”

莱斯利：没错。

Drew：这是否意味着你会得到一个带有所有这些分支的混乱代码库？ 你怎么处理？

Leslie：是的，我认为那是……任何使用功能标志的人可能已经习惯了这种你什么时候清理功能标志的战斗？ 你把它们放在那里多久？ 我们已经在一个主要功能发布后大约两周登陆了，我们有提醒。 幸运的是，LaunchDarkly 最近实际上设置了一个会通知 Slack 的功能。 所以，你可以将它与 Slack 连接起来，它只会告诉你，“嘿，你的功能标志已经……你已经在生产中生活了两周。 现在是时候确保清理代码中的标志了。”

Leslie：所以，我们确实尝试并很快清理它，但在这期间，很高兴知道旗帜仍然在那里。 即使您已经发布了该功能，这意味着再次单击，您可以进入并将该标志切换回来，如果有弹出的内容，则存在错误。 因此，我们希望将它们保留一段时间，就在该功能真正成熟的时候，而人们正在习惯它，以确保没有任何重大问题。 但是我们确实尝试回到代码中，这有点清理，所以这不是一个理想的过程，但通常删除标志不会花费很长时间，你只是删除了几行代码。

Drew：所以，我想实现功能标志的最简单方法可能只是......就像你的应用程序中的一个配置变量，它说“这个功能是打开或关闭”，但是你需要一些方法来确保它为正确的人开启，为正确的人关闭。 我想这就是像 LaunchDarkly 这样的服务的用武之地，因为它需要...

莱斯利：是的。 是的。 就是这样。 因此，即使没有 LaunchDarkly，我们也有一些方法可以基本上自己设置一个配置变量，我们可以自行管理。 我喜欢 LaunchDarkly 的一件事是有不同的环境。 因此，我们可以做的基本上是为我们的部署预览打开一个功能标志。 因此，任何在 Netlify 内部查看的人，应用程序的部署预览都可以访问新功能，可以对其进行测试，但话又说回来，一旦它投入生产，该标志就会关闭。 所以，很少……再一次，你必须检查你的标签，并确保你知道你所处的部分，因为你不想让自己感到惊讶并认为你已经推出了一些你没有，你必须在那里小心一点。 但是，总的来说，它工作得很好，而且 LaunchDarkly 还允许您进行这些选择性的推出。 因此，您可以将某个功能推广到您的代码库的某个百分比或特定用户群、具有特定类型计划的人或特定类型的用户。 因此，它使您可以更好地控制要向谁发布。

德鲁：是的。 我猜这可能非常强大，尤其是您可能希望解决问题的新特性或特性。 也许您正在增强一项功能以使其更易于理解，您也许可以与 10% 的用户一起尝试，看看他们是否遇到同样的问题，然后……

莱斯利：没错。 这也是获得反馈的好方法，是的。

Drew：我猜想以这种方式使用 LaunchDarkly，而不是推出自己的解决方案，是 Jamstack 方法的另一个方面，不是吗？ 它只是使用为您提供此功能的 API，而不必担心您自己如何实现该功能以及如何开发以及如何维护和保留它，以便您可以外包它，说：“对，我们是将使用这个 API，其他一切都得到照顾。”

莱斯利：是的。 是的，正是。

Drew：所以，这种方法使您能够在本质上将少量新功能投入生产，但它们只是隐藏在旗帜后面。 然后当一切准备就绪时，您只需翻转标志，如果出现问题，您可以快速将其重新切换回来。

莱斯利：是的，没错。 它使我们的发布变得不那么令人兴奋。 过去是你按下这些大按钮，所有这些代码都被合并，你正在查看你的构建日志，这是期待的时刻。 现在，您可以拨打 Zoom 电话，单击一个按钮，它就开始了。

德鲁：是的。 我认为上一个功能发布，我在 Netlify 上工作，我们使用了这种方法。 整个团队已经花费了数周的时间，我们接到了一个 Zoom 电话来协调发布，每个人都确认他们的部分已经准备好了。 然后我翻转功能标志并为所有用户打开它，就是这样。

莱斯利：完成。

德鲁：几分钟就结束了，真是虎头蛇尾。

莱斯利：是的，有点悲伤。

德鲁：没有出汗的手掌，什么也没有，这当然正是你想要的，不是吗？ 这就是你如何知道你有一个强大的过程，如果为每个人打开一些东西并不是什么大不了的事。

莱斯利：没错。 如果您必须再次回滚，就这么简单，只需单击一下即可。 它减轻了一些压力，焦虑。

Drew：所以，大概，我的意思是，并不是所有的变化都只是前端的变化。 有时会有后端更改，并且可能在大多数后端系统中它们也有自己的功能标志。 所以，你也提到了文档。 有没有办法将所有这些协调在一起？ 每个人都只是同时翻转他们的旗帜吗？ 或者它是如何工作的？

莱斯利：是的。 因此，这是我们目前在 Netlify 跨团队积极开展工作的一个领域，正在努力寻找一种解决方案，使我们能够将所有内容与 LaunchDarkly 中的一个标志联系起来，我们所有的系统都在使用，我们所有的代码库都在使用。 所以，在一个理想的世界里，我们可以翻转一个标志，然后说，“好的，这是切换新的 API 端点，这个端点也在前端使用这个新的 UI 被包装在一个特性标志中，以及文档网站的这一部分，其中包含有关此新功能的新信息。” 你翻转其中的一个标志会影响所有这些存储库。 我们还没有完全做到。 我们正在努力解决这个问题，但我很高兴看到我们是否能够让所有这些协调和工作。

Drew： Netlify 作为一种服务非常适合以这种方式构建网站。 您和您的团队使用产品所做的工作是否真的影响了产品开发？

莱斯利：我会说它确实如此。 每个人都说你不是你的用户，我认为大多数时候都是如此，除非有时你是你的用户。 这在 Netlify 很有趣，因为我认为前端团队中的大多数人尤其是以前使用过 Netlify 作为产品的人。 当然，因为我们使用 Netlify 来部署 Netlify，我们遇到了与我认为我们的一些用户相同的挑战。 因此，在某些方面，如果我们遇到问题，我们会尝试将其提交给公司的其他成员。 我们会在工程电话中提到它，或者我们会请我们的 CTO 说，“嘿，这是我们正在努力解决的问题。 我们是否可以在产品中构建一些东西，让我们和所有正在部署与我们类似的东西的用户更容易做到这一点？” 所以，这是一个独特的位置，但看到产品路线图是如何开发的很有趣。

Drew：我想可能很少有人像 Netlify 本身那样密集地使用 Netlify。

莱斯利：是的。 是的。 我认为这是对的。 我在构建和部署 Netlify 时都会盯着它，所以我对它非常熟悉。

Drew：然后在周末你从事一个业余项目，你发现自己又回到了 Netlify。

莱斯利：是的。 这实际上是非常正确的。 是的。 是的。 确实是的。

Drew：你有没有任何例子说明产品方向如何受到团队所做工作的影响？

莱斯利：是的。 因此，我们最近为我们称为团队概述的应用程序推出了一种新的登陆仪表板。 因此，过去当您登录 Netlify 时，您会登陆该网站的页面，这基本上就是您网站的一长串列表。 我们想给人们更多的任务控制区域，在那里他们可以一目了然地看到很多重要信息，访问对他们最有用的东西。 因此，这是我们构建的一个新功能。 在最初的迭代中，我们试图快速推出它，我们在那个 UI 上有一张小卡片，可以链接到您的最新版本。 它向您展示了整个团队的任何构建，都应该出现在该卡中。

Leslie：起初，我们实际上并没有将这些与构建相关联……显示日志本身。 因此，这只是一个您可以查看的列表。 您可以单击构建页面以获得类似的视图。 但实际上我周末在做一些事情，一个个人网站，我打开了这个团队概述，我很生气，因为我意识到我登录了 Netlify，我想去看看我的项目正在发生的这个构建，我不能只点击它就可以直接使用它。 我不得不点击进入构建页面，然后再次点击。 因此，第二天上班时，我进去添加了更改并链接了这些构建，因为这让我很困扰。 因此，这是通过使用该产品才意识到，改进它的机会很小的一个例子。 我们接受了。

莱斯利：但我们也有一些其他的例子。 可能影响更大一些。 一个是我们添加了这个表单检测功能。 因此，如果您不熟悉一点背景知识，Netlify 表单是 Netlify 中的一个功能，可让您构建前端表单。 Netlify 负责管理提交的所有后端工作。 它有点像您在前端构建的表单数据库。 这意味着您不必编写任何服务器端代码或大量额外的 JavaScript 来管理表单提交。 实际上，您部署到 Netlify 的任何站点，当您的构建正在进行时，我们的构建机器人都会在部署时解析您站点的 HTML，以基本上检测您是否有 Netlify 需要注意和管理的 Netlify 表单。 默认情况下，构建机器人正在寻找的这种表单检测是启用的。

Leslie：但这意味着，正如您可以想象的那样，这会占用您的构建时间，因为机器人必须去寻找这额外的步骤。 所以，Netlify 应用程序本身，实际上，我们没有使用，我们现在在应用程序上没有任何 Netlify 表单。 所以，这一步基本上会增加我们的构建时间，但不一定需要发生。 因此，Netlify 实际上构建了一个新功能，允许任何用户禁用该表单检测。 这意味着您可以在站点设置中关闭该设置，构建机器人意识到他们不需要寻找任何东西，因此您可以在构建中节省一点额外的处理时间。

德鲁：我想这在生产力方面很好，因为事情完成得更快一点。

莱斯利：没错。

德鲁：而且，作为一种计量服务，您可以从现有的津贴中获得更多收益。

莱斯利：是的。 确切地。 因此，我们也从一些用户和客户那里听到了这一点，我们也注意到了这一点。 它是，“好吧，我们自己的产品不需要这个额外的步骤。 那么，有没有一种方法，我们可以为所有用户提供一些东西，让每个人的生活更轻松一些，如果每个人不使用这个功能，他们的构建速度会更快一点吗？”

Drew：有没有危险……我的意思是，你说你不是你的用户，但使用 Netlify，你通常是你的用户。 是否存在危险，随着您使用该产品的强度，您可能会忽略那些仅非常轻松地使用它的用户，并且一切都可能变得过于复杂和过于先进，并且变得非常难以获得开始于？

莱斯利：这是一个很好的问题。 我们还在 Netlify 建立了用户研究功能和数据科学功能，我认为，总的来说，我们对他们的信任远远超过我使用和部署该应用程序的轶事经验。 但我认为所有这些数据汇集在一起​​，可以让我们更好地了解谁在使用 Netlify，我们在与哪种类型的用户交谈？ 有些人有不同类型的需求。 我们的初学者团队中有负责管理博客和个人网站的人员，我们也有大型企业，他们正在发起大型营销活动和大型网络应用程序，与 Netlify 本身并无太大区别。 因此，看到用户群增长并考虑所有这些用例并弄清楚我们如何迎合所有这些用户是令人兴奋的。 当然，使用我们更多的研究功能来了解这些用户是谁，而不仅仅是我们的内部经验。

Drew： Leslie，告诉我 Netlify 提供的截图服务？ 因为我发现这真的很有趣。

莱斯利：是的。 在我们的 UI 中……当您在 Netlify 上部署一个站点时，在 UI 中，我们有一个小屏幕截图，通常会向您展示您认为该站点的主页是什么样的。 我们提出这个问题实际上很有趣，因为不久前我正在听 Chris Coyier 他在 Serverless 上的一集，他也在谈论他们如何在 CodePen 中进行截图，这实际上与 Netlify 的做法并没有太大的不同。 但基本上我们运行 Puppeteer 来捕获用户站点的屏幕截图，它的运行方式是它设置了一个 Netlify 函数。 所以，这又是一个我们对自己的产品进行测试的例子。 所以，基本上我们使用这个端点，即我们自己的应用程序中的一个 Netlify 函数来返回该屏幕截图图像的 URL，然后我们可以在应用程序中提供它。

Drew：所以 Netlify 函数是 Netlify 对无服务器函数的实现，不是吗？ 您基本上只需将 JavaScript 文件作为源代码的一部分放入指定的文件夹中，然后就可以将其作为云功能执行。

莱斯利：是的，没错。

德鲁：超级聪明，不是吗？

莱斯利：是的。 这个棒极了。 这是其中一个真正推动我作为前端工程师真正成为这种 JavaScript 或无服务器工程师的领域之一，并在创建时多思考一下你基本上是如何编写的，就像你自己的内部 API 端点一样one of these Serverless functions. So, it's exciting because there's so much you can do, but that can make it a little intimidating also because there's so much you can do.

Drew: I sort of find it funny how it's like… that's seemingly a core piece of functionality for Netlify, displaying images alongside your site of what it looks like, yet, it's just implemented with another Netlify feature. And you wonder how far you go before it all disappears in on itself in a big cloud of smoke.

Leslie: Yeah. 是的。

Drew: This sounds like a really nice way to be working, and a very modern way to we're working, but it can't be without its challenges, can it?

Leslie: Absolutely not. I think I've spoken a little bit about what it means sort of as a frontend engineer pushing into sort of some new areas just for me to be thinking about in terms of Serverless and how can we leverage this in the product? I think for me, mastering that sort of back of the frontend side has been an exciting challenge, but certainly there's a lot to learn there. An example of that in our app right now, is that we use Cypress for end-to-end testing of some of the critical flows in our app, and right now we have that set up so that the Cypress end-to-end tests are running on our Deploy Previews in Pull Requests using a GitHub action. So, we use the GitHub action to run those Cyprus tests against the Deploy Previews of the app.

Leslie: Which is really cool, but there's probably a better way to do this than actually using a GitHub action. I actually think that we could use a Netlify Serverless function because those can be triggered on certain events, like a deploy succeeded event. So, there's an opportunity there for us to actually leverage again, Netlify, a little bit more, instead of relying on some of these other tools that maybe we're more familiar with or more comfortable using. So, in terms of challenges, I think it's opening our minds to what this sort of new model of development allows us to do and trying to leverage it.

Drew: Yes, there's so many different ways on there to… with the tooling that's available, to be able to attack a particular problem. At Smashing, we probably shouldn't say there's more than one way to skin a cat.

Leslie: Yikes.

Drew: What's interesting about the workflow as well, is that it's really intensively Git based, which I think suits… it's really developer friendly, isn't it? As a frontend engineer, something that's Git based kind of just feels like home. So, is that all great or are there any problems that come in with that?

Leslie: I think as a developer Git is wonderful. I think in general it solves big, big problems and I'm very happy to have it. But, because we rely on it so heavily and as our internal team has grown as well, you end up having the same problems that Git has when you're talking about Netlify in this workflow, right? So, you end up with a bug on your main branch, yes, it's really easy to roll back the app itself, we talked through what that looks like, and then go in the code and fix it. But what if someone else on your team is working from a broken version of that main branch? Everyone's going to have to rebase, everyone's going to have to communicate, or at least be aware of what happened. And so, it's not so much a Jamstack problem or a Netlify problem, but more of just the age old, how do you coordinate on a team of human beings and how do you use the technology to do that properly?

Drew: And of course, as you add more tools and infrastructure in around what you're doing, then you've got the problem of everything taking a long time to run. I mean, you mentioned Cypress is one thing. I know Cypress is a real headache with the amount of time those end-to-end tests can take to run. Is there other challenges around that growing build time?

Leslie: Yeah, I think that's one of the other things that Jamstack… You're introducing this build time, which for developers is not great. I always try and think about it as what I sort of eat up in that build time, my users are saving in the performance of what they're getting. So, I always try to keep that in mind when I'm frustrated about how long something is taking to build, but certainly I think that's an area of opportunity and a challenge, is figuring out how to keep those build times fast, how to make sure that we can deploy as quickly as possible. Some of it is this sort of tension between wanting to run all your tests, wanting to make sure that you don't deploy a build if a test fails, but at the same time, then you've got to run all those tests.

Leslie: So, it's this constant sort of back and forth between wanting to keep the build times fast, while also making sure that you feel like you're doing your due diligence before you actually deploy something. And we're playing around with some ideas here as well about potentially moving our Cypress tests to be running against production and having some alerting setup that would let us know after the fact, if something had failed. Which is sort of an interesting model, too. So yeah, stay tuned.

Drew: I certainly know that, yes, the dangers of growing build times, just from a developer point of view, from productivity point of view, that if something takes too long to run, you context switch, you start working on something else, and then it just… you lose all the momentum, and maybe you forget to go back and find out whether the build succeeded because you're then so far into the next task.

Leslie: Yeah, definitely.

Drew: So, I guess this isn't the ultimate workflow as it stands at the moment. There must be further we can take it. What sort of opportunities might lie ahead for this way of working?

Leslie: Yeah. So, I think for me, and Netlify in particular, is sort of the thought of collaboration for larger teams. I mean, I know a lot of developers are sort of… have used Netlify for side projects and other things that they're working on, on their own, but thinking about how it can be leveraged on larger teams, like mine. As we get larger and we're growing, more of us are in the app, more of us are using Netlify to deploy our own services, and so everything from even more robust audit logs so that you can go and see who changed this site setting, or who was the last person to deploy something. I think having the ability to organize your sites within your Netlify dashboard, even knowing… assigning someone to a build is sort of an interesting idea to me. Could that be helpful if I knew that my teammate had worked on this build, but then I realized they had to roll it back? And maybe I'm just aware of who's managing that process could be a really useful thing within Netlify itself.

Leslie: And one thing that I've seen sort of thrown around a little bit is perhaps the ability to link to a specific log line in build log. So, for debugging, if you have your build log of your Deploy Preview, and there's an error that got thrown, either from Netlify or from your own code, it'd be nice to be able to link directly to that log line. So, that's sort of a fun, small improvement that I've been thinking about a bit. And that's not even to say we have some new features at Netlify as well, that are pretty exciting. Edge handlers and background functions. I'm still trying to wrap my head around what they all do and exactly how they work, but I know that edge handlers are going to give us the opportunity to do some things with localized content, which could be… have some interesting implications for features we could build in the Netlify app as well.

Drew: Yeah, it's really exciting. I think there are all sorts of people within the Jamstack community who are pushing this the whole thing forward. But I think Netlify, as a service, is one that is really behind it and doing exciting things. And, as I say, I didn't want this to be a big ad for Netlify, but I think you and I both really love the service, so it is exciting to talk about isn't it? If listeners want to get more engaged with learning how to build Jamstack sites or want to get more into this ecosystem, is there a good place to go to learn this stuff?

Leslie: I feel like it's exploding right now. I would certainly point you to the Netlify blog. We try and post some tips and tricks there and announce new features as well. I would give a shout out too, to Learn With Jason. My coworker, Jason Lengstorf does sort of a live stream show, and he does cover… he covers a range of topics, but does some Jamstack specific ones as well. And it's a fun hour of live coding and picking that out. Twitter, I think, is huge, too. So check out Jamstack hashtag.

Drew: Good advice. So, we've been learning all about how Netlify builds Netlify on Netlify. What have you been learning about, Leslie?

Leslie: Oh, that's always a big question. I mentioned Cypress before, we've been working through some of our processes around exactly how we want to run our end-to-end tests, and so I would say that, in general, I've been thinking a lot about that workflow. So, less about the technology itself, but more about what workflows exist for end-to-end testing on the frontend, and what makes sense sort of in this Jamstack model. So, that's been a fun sort of side tangent. And then, on the CSS side of things, we talked a bit about CSS architecture, and I'm starting to get my hands dirty with Tailwind, which has been a fun and exciting and lots to learn and lots of class names to memorize and… Yeah.

Drew: That's exciting stuff. If you, dear listener, would like to hear more from Leslie, you can find her on Twitter where she's @lesliecdubs, and her personal site is leslie.dev. Thanks for joining us today, Leslie, did you have any parting words?

Leslie: Have a great day?