Nine pillars of great Node apps
01:04:14 Share

这是爵士派对，您每周庆祝 JavaScript 和网络的节目。如果您喜欢这个节目，您会喜欢这些变化，它包含关于单一访谈、一些脱口秀节目的新闻。这很像杰伊的派对。现在我想到了 IT，通过搜索您收听播客的任何地方的变更日志来找到我们，大型承包商合作伙伴在 FlightIO 上启动您的应用程序，全球各地只需五分钟或更短时间。了解 FlightIO 如何运作，嘿，它是一份兼职工作。

好的，朋友们，我现在痴迷于使用 Notion AI。是的，我是一个 Notion 用户，一个高手。你会说我把它用于我自己。

我把它用于变更日志和 IT，它非常有效地组织所有内容。通过添加 Notion AI，它是一个单一工具包。所有 Notion 和其他应用程序的搜索都生成了我的风格。

而且，除了 PDF 和图像之外，它还可以与我分享任何内容，现在您可能知道 Notion 是组织任务、跟踪任务或拥有美丽狗狗的理想场所。您可以使用 Notion 做的所有事情，但添加 Notion 的工作上下文，这简直是革命性的。与需要您在六个不同应用程序之间切换的特殊工具或旧版软件不同，Notion 非常流畅地集成、填充和灵活。

是的，它看起来很漂亮。是的，我痴迷于 Notion AI，因为它几乎可以回答我任何问题，它就在那里等着我。它非常快速，并且与我 Notion 中的所有内容相关。

今天免费试用 Notion，访问 notion.com/flashparty，所有小写字母。Notion.com/GSParty，尝试功能强大、易于使用的 Notion，我们使用一个链接来支持本节目，这太棒了。Notion 赞助派对。

大家好，派对人士。我是杰罗德，您的互联网朋友，今天我与……一起加入。再见，在名为“九个节点”的精彩文档背后的一半青少年。

支柱，也许你听说过它们。塔亚在这里。什么？陶。

很高兴再次在这里。一切都很棒。蒂克，我刚从岛上回来，不，只是关闭提交。

很好，总是最后一个拥有人类尾巴的人。杰罗德派对的常客，以及第一次来访的纳塔莉·维迪托，她是 Azure 的 JavaScript 开发人员和开发工具负责人。纳塔莉，欢迎你。

谢谢。感谢您邀请我，我非常兴奋。

我对这份文档，你们共同完成的这份作品感到兴奋，我认为它为人们提供了在企业环境中构建节点应用程序的坚实基础。我们希望深入探讨这些支柱。我可能会改变它们的顺序，因为其中一些非常通用，我认为适用于许多类型的应用程序。

然后有一些不是特定于某一方面的。我喜欢先介绍通用的那些。因此，我们确保涵盖所有这些，然后回头看看。你可能不同意我的看法，马特奥，但我们会讨论这个问题。

我同意你的看法。我实际上，你做得很好。让我们开始吧。让我们开始吧。

首先，让我们快速了解一下它是如何产生的。你们四个人写了一份文档，这个想法是谁的？

为什么我们要写它，或者如何进行？这个主要想法是我的。我们开始收集很多想法，比如你可能已经做了很长时间，帮助公司，在为平台做咨询之前，我的创业公司，我开始做咨询很长时间。

基本上，我收集了很多关于公司在没有 GS 的情况下做错的事情的糟糕经验。然后我决定，嗯，有很多糟糕的公开问题。好的，所以也许我们应该传播好的意见。

那么我该怎么办？好的？我说，嗯，如果我写出来，那么也许我只需要，我的意见，让一群人来写出来，好吗？因此，我们在这里。一开始，我认为它们少于九个，五个。我们从……开始。

很多数字。

我们有九个，九个，一个很好的数字。

作为一个很好的数字，特别是字面上的九个节点支柱。告诉我，你是如何参与其中的？

我与我的团队合作了一段时间。自从我加入 Azure 以来，但我想早一点，也因为他在技术卓越委员会的工作而关注他。我一直在使用 JS。

实际上，在企业中已经很长时间了，超过十年，我说网络必须在那个时间之前起飞。那不是用 JS，但无论如何，是用 JavaScript。T，是的，我也看到了所有失败的案例，所有错误的案例，所有好的案例，实际上领导着顾问。

在前面和团队或部门中，在那个时代与顾问一起，在很多事情上领导企业，是的，基本上破坏了他们的应用程序，并尝试告知人们如何避免犯同样的错误，对吧？因为我不会说我从未犯过任何错误。我可能犯了很多错误，试图避免人们将来犯这些错误。

当然。你只有在知道坏事之后才能真正知道好东西。你知道，你犯了错误，你讨厌所有不好的东西。我们以后不要再那样做了。这是一个非常重要的学习过程，我们不必每次都经历它。

当然，有些事情你必须自己学习，但是如果你能从犯过错误的人那里学习如何避免这些错误，那么你就领先了。我很高兴你们将你们的知识融入这九个支柱中。现在我想改变它们的顺序，但它们是按顺序排列的吗？1 到 9？以及最重要的会议。

或者营销决策，关于它们的顺序，可能有一些东西在其他东西之前，但它主要取决于什么对构建该年的用户更有共鸣。

所以我会快速浏览一下它们。然后，我们将根据需要进行讨论，我们不会全面深入地涵盖所有九个方面。这就是文档的目的。

当然，我们的听众，如果您从这次谈话中学到了一些东西，请深入研究并从中获得一些精华。但是，九个节点支柱：一、不要阻塞事件循环。二、监控节点特定指标并采取行动。

三、在生产中使用节点 LTS 版本，尽可能自动化测试、代码审查和一致性。五、避免依赖性蔓延。六、避免风险依赖性。

七、避免全局变量配置或单一依赖项。八、处理错误并提供详细日志，九、使用 API 规范并自动生成客户端。这就是这些人的好企业级 JS 应用程序的九大支柱。

现在我认为其中一些适用于几乎任何应用程序。我认为其中一些不是特定于某一方面的，马特奥。你同意我的看法吗？我听不到你不同意我的地方。

我完全同意。其中一些是。所以这是要说的。好的，其中一些就像原则可能是通用的，对吧？但是该部分中的很多内容都不是特定于某一方面的。

因此，虽然原则可能是通用的，但其中的内容并没有具体说明如何实施该原则。无论如何，它们值得一提。所以让我们开始……

从我认为最通用的那些开始，我们可以深入探讨所有细节，这些是像避免依赖性蔓延这样的。这是你们所有人第五个。当然，对我来说，这就像所有开发工作中的普遍问题。

避免依赖性蔓延。同样的，意大利语。你认为你不同意什么？你对这个节点支柱有什么看法？

JS 人们和我一起工作？不，我讨厌有时因为我试图避免所有不必要的麻烦。当然，你不会重新发明轮子，也不会编写其他人已经编写并维护的东西。

你知道它是可靠的，你可以将其添加到你的代码库中。但我认为我们可以说，因为这是一个系统问题。我们倾向于添加我们不需要的依赖项。我们倾向于不考虑维护成本。

我们倾向于不考虑被绑定到其他人正在领导或控制其路线图的代码的成本，是的，我们需要控制这一点，这就是我们所做的。你绝对是对的。这不仅仅是 JavaScript 的系统问题，它也是软件开发或网络开发的一般问题。但这是一个非常重要的考虑因素，是的。

我与成千上万的人谈过这个问题，我们都同意这一点，但我们仍然发现自己陷入依赖性循环中。也许问题在于我们如何达成共识，我们应该如何做，但你实际上如何决定？你如何做到这一点？

这是一个非常重要的问题。好的，npm 社区，npm 解决了困扰该行业数十年的问题。他们知道如何使用可扩展的软件，这是，你知道的，但你知道的，每当你想解决一个大问题时，你需要说，好的，小心你所希望的。

现在我们有充满了可能使用、可能不使用、可能不需要的模块。好的？还有几件事要说。

很多时候，一些模块可能不再需要，因为我们已经有了用于 JS 核心和网络本身的 API 很长时间了。因此，你知道……让我举个例子。

Fetch 是一个很棒的规范，是一个很棒的 API。每个人都喜欢 Fetch，好吗？但是，每当我打开一个企业代码库时，我通常会看到……

我缺少一些东西。我举个例子，我喜欢实际的。好的。我只是说，这是一个例子，最近他们仍然使用 request 模块。现在我只是想看看 request 模块（它已经过时很久了）每天仍在使用多少次。好的，因为这是一个非常好的数字。request 模块每周仍在加载和使用 7000 万次。

哇，这真是令人震惊。

它已经过时五年了，五年了，这些东西已经过时了，但每周仍在下载 7000 万次。好的，这是我的问题，你需要保持这些 API 的最新状态，并尝试重用它们，但你知道，在做出选择时要聪明。你今天做什么，两年后做什么，事情会发生变化。

你需要保持你的代码库灵活。从这个意义上说，你不能把事情定下来。很多团队把事情定下来，说，我们，这是我们的猫，我们三年前决定了，但你不需要它了，我们三年前决定了，而资深工程师说，所以……

是的，这就是我们大力支持网络平台的原因，对吧？因为，首先，去看看哪些是未来证明的，然后去看看其他人是否已经为其提供了本地支持。

关于依赖项选择或选择在 npm 中搜索而不是自己编写代码的建议或最佳实践是什么？是否存在特定大小或功能难度，你认为应该使用依赖项（例如，Fetch）？例如，你将要……我应该自己编写路由和 HTTP 东西，你认为应该使用 Polly 吗？你很可能……

这很有趣。

如果我有时间，我可能会这样做，你知道的，因为我喜欢这样做。我做了，你看？是的。所以我的意思是，我们如何，在那个时刻，那个临界点，我如何决定使用某个东西还是自己构建它？

我倾向于不编写代码。所以如果我发现一些有用的东西，就使用它。好的，我从 A、B 中使用它。问题是我的标准通常很高。

因此，每当我使用某些东西时，我的问题是，如果我采用它，我是否能够维护它？这是每个人都需要问的问题。他们采用了一个软件包。

特别是公司，好的，如果事情变得更大，那么你必须问，好的，我无法维护它。如果我无法维护它，那么谁可以维护它，我如何让他们访问它？你知道，然后他必须，你知道，我们必须支付给谁，基本上是公司，是的，好的。

这对于公司版本很重要。个人开发人员有不同的思维方式。你需要考虑你的项目的长期稳定性。

所以，如果出现问题，你不知道该怎么办，我最近一直在……我陷入困境，所以大多数时候我就像一个模块。也许我……我需要同意，嗯，一些容器的痕迹。我不会这样做，我会修复它，让它成为我自己的，这是公平的。

这让我们进入下一个主题，我们绝对可以为此专门做一集。我们的下一个支柱实际上与同一主题有关，即避免风险依赖项。所以，马特奥，你正在谈论依赖项、风险以及维护自己。

是的，依赖性越大，我认为风险越大。有一些方面可以从爆炸因素的角度来看，例如，这种东西被放弃的可能性有多大，但冒着你的日本natta的风险，这是第六个支柱。谈谈这一点。

你知道，在企业环境中，我认为其中一个建议是，我们似乎想鼓励利益相关者参与更多开源项目，因为你无法理解你没有参与的代码的风险。

所以，如果你使用X、Y、C，或者你决定要使用X、Y、C模块，就去调查一下，参与其中，了解三个方面的活动，了解人们可能提出的关于特定选择、设计选择和架构选择的安全性问题。这是一种冒险的方式。另一种是确保你了解冷启动、集成，因为你将不得不偏离，你可能不得不做出捕捉某些东西的决定。

你，如果你必须这样做，你可能想要回馈上游，对吧？所以每个人都能从你解决的任何问题中受益。但是，绝对要了解你要使用的代码。这是一个，然后持续关注整个系统，无论你依赖的漏洞是什么，它都可能成为访问应用程序其他部分的途径，对吧？

是的，是的。让我举一个非常简单的例子。正如你们所有人一样，你们知道，express项目在领导层发生变化时声名狼藉。

新领导层上任后做的其中一件事就是发布了一系列的CV。现在很多人早就知道这些CV了。

问题是什么？嗯，因为这个项目并没有真正处于良好的状态。所以，这是要考虑的重要问题之一。

嗯，维护者可以做到这一点。工具可以帮助你很多，比如工具。我说的不是工具，但工具是最低限度的。

但是你需要做的不止是使用工具。工具在问题发生后有所帮助。工具就像，而且，而且，而且，这是著名的黑暗时代。好的，在那边，好的，但是，你需要事先考虑问题。

大多数时候，关注点在于了解代码和风险。让其他维护者、其他团队参与进来，了解他们的问题，打个招呼，或者只是阅读他们的动机、他们是谁、他们为什么要构建它，了解他们的一些意图。我申请维护这个项目未来十年，或者这是我发现自己的问题。

它免费供你使用，但我与它同在。这类信息对于了解风险非常有用。所以要了解代码，也要了解团队或个人。

你不需要像我与马特奥那样建立昵称关系，例如，我是他的节日维护者。但是我了解节日背后的团队，这让我对这个项目更有信心。所以。

朋友们，我今天和我的朋友，我的合伙人兼WorkOS的首席执行官在一起。我们非常喜欢WorkOS。因为在这里。

迈克尔，告诉我关于OffKit。它是什么？为什么它有用？

我们一直在构建身份验证工具很长时间了，从一开始就如此，但我们最初的重点只是集中在单一登录示例作者上。但是一年后，我们从更多人那里得知，他们希望涵盖所有身份验证方面，包括密码重用问题、阻止重用密码，以及与其他第三方系统的集成。

他们还希望我们能够处理与其他身份相关的业务逻辑、用户配置，甚至更高级的功能，例如基于角色的访问控制和权限。因此，我们开始更多地讨论如何将这些功能作为API提供。我们意识到，我们拥有在Radix上的出色经验，这是一个构建前端和开发人员体验的组件系统API。Radix每月下载次数达到数百万次，用于执行此类操作。

因此，我们将这两者结合起来，构建了OffKit。OffKit是向任何应用程序添加身份验证的最简单方法，不仅仅是Next.js。如果你正在构建一个Rails应用程序、一个Gatsby应用程序、一个Express应用程序或其他类似的应用程序，它附带了一个托管日志箱，因此你可以自定义它。

你可以对其进行样式化。你可以构建自己的日志体验，使其非常模块化。或者，你也可以以无头方式使用其API。但默认情况下，它提供构建服务所需的一切，并且与WorkOS平台集成。

因此，你可以非常快速地添加任何所需的企业功能。因此，我们看到很多公司开始使用它，因为他们预计市场会增长，希望服务于企业，并且不想在这样做时重新架构他们的堆栈。这是一种让你的身份验证系统为未来的增长做好准备的方式。我们有客户，他们最初只是试用，然后他们成为Coinbase、迪士尼或联合航空等主要客户。而不是说，“哦，对不起，我们没有新的企业功能，我们将不得不重建所有内容”，他们只需进入WorkOS仪表盘并查看。

一个盒子，你就完成了。一个关于OffKit很棒的事情是，它免费提供高达一百万用户的服务。是的，这些其他功能包含一百万月活跃用户。所以从第一天开始使用它。当你需要扩展到企业级时，你已经准备好。它易于学习。更多信息请访问offkit.com或workos.com。WorkOS的忠实粉丝，请查看它。免费试用WorkOS。com或offkit.com。

许多应用程序的另一个良好支柱。第七个，避免全局变量、配置或单例。我的大学教授曾经非常严厉地批评过我这一点，但我当时并不真正明白原因。

但是，我就像，全局变量是邪恶的。全局变量是邪恶的。然后，我就像，好吧，我不会使用它们。

现在，过了几年，你们都说了，不要使用全局变量或避免使用它们，说，为什么？为什么？为什么？为什么？为什么？它们如此方便。它们很有用，它们很容易。谁想。

来谈谈这个问题？我在这里，打自己。

打到某人。

我当时觉得，我，这太疯狂了。好的？有多少JavaScript应用程序充满了全局变量，将数据库粘贴到全局变量中，粘贴，你知道，它们需要在系统之间来回传递数据，而没有任何控制数据或项目如何启动的方式，它无处不在，好的，代码库在很短的时间内就会变得一团糟，因为，你知道，哦，我需要一些数据，它在某个地方。

哦，我只是从我的模块中导出，然后导入，我不知道，经过一万次交互后，代码库变得难以维护。现在，这是一个需要解决的问题，你知道，而且，你知道，这会使现有问题变得更糟，因此你需要做其他事情来修复它，并将其变成，你知道，从杰西到那里的电影，是的，一些东西，但现实是，你可能没有为你的代码应用任何结构。这源于JavaScript的历史。好的。

在浏览器中，我们可以使用局部变量，好的？一个全局变量，一个用户，一个全局变量，好的，在Node.js中可能不是。好的。然后，为了支持这种模式，我们必须发明各种方法，使全局变量对用户来说是可行的，而无需实际使用全局变量，这样他们就可以有一个很好的轴和一个很好的x，称为全局变量。

现在，好的，对于某些框架来说，但现实是，我们有很多同步时钟魔法在幕后工作，以使这些流行的框架正常工作。例如，如果你想要请求的标头，你可以直接调用标头函数。从市场角度来看，这很重要。

你可以得到标头。很棒，对吧？为什么需要这样做？好的？幕后有很多状态被处理，以便正确的请求获得正确的标头。并且在提供这种开发人员体验时，有很多复杂性和性能损失。好的？大多数开发人员都喜欢全局变量，好的？

而且它非常方便。

如果你想避免这些东西，那就不要这样做，好的？另一个问题是没有人等于生产。这是我的另一个问题。

嗯，意大利，你想谈谈这个灾难吗？不，我们生产。

同样的，告诉你。

我认为你非常擅长解释为什么不应该使用它们。我希望你能够进一步阐述这一点。但我认为你真的区分了在浏览器中使用全局变量和在服务器端使用全局变量。

这是不同的故事。我们已经看到很多工程在浏览器端管理状态，我想谈谈，因为我将要。但是，那将是另一个主题，对吧？在另一个节目中。但是，在开始编写脚本之前，非常重要的一点是不要污染全局变量。在学习框架之前，我让很多人对我生气，因为我让他们先学习脚本的机制。

是的，对。嗯，这是一个非常有趣的话题，我认为我们陷入困境的原因是，在小规模上有效的东西在大型项目中并不适用。他说的是数千次迭代之后，或者类似的东西，或者就像你开始时，在小规模上是有意义的。

这只是一个单一文件。我只需要运行一个小的Node.js服务器。我将有一个全局变量来存储我的数据库，并且在该规模的代码中，它运行良好。

然后，我们将其逐个添加，并逐渐构建这些应用程序，从一个单一文件开始，经过数千次迭代后，你手上就变成了一个巨大的混乱，而你并没有在早期考虑结构。当它很小的时候，它会反过来咬你。当然，责怪整个团队，但我们经常看到这种情况发生。

所以，嗯，我们如何避免这种情况？嗯，你必须了解你的应用程序最终会变成什么样子，并且可能需要一个结构，或者干脆完全避免使用它们，或者始终将“不等于生产”作为一种原则。这就是这份文件所说的。

但是为什么？嗯，他们知道生产是这种模式最明显的失败案例。很久以前，我的朋友蒂姆·戈斯韦尔决定在连接库中添加“不等于生产”环境变量。我不知道你们所有人都在使用JavaScript时是否使用过连接。

还记得连接吗？我知道他。我们之前在节目中邀请过他，但很多人都认识他。不要。所以请随意补充细节。

好的？好的。顺便说一下，团队，因为，嗨，你们做得很好，你们为社区做了很棒的工作。所以，我开始让你们为此负责。

但是他提出了一个想法，你知道，我们需要这个库在开发环境和生产环境之间做出不同的选择，这是一个非常棒的想法，好的？我们需要它。我们需要它。

如今，任何应用程序都有开发模式和生产模式。好的？没有，这很棒。

这个想法很棒。然后，一些人想出了一个想法，那就是环境。因此，我可以有一个暂存环境，我的数据可以从中选择。这就是灾难发生的原因，因为人们还认为环境是一个运行在某个地方的服务器。Java开发人员认为环境是我的电脑，这基本上是一个巨大的语言障碍，一个关于两个完全不同含义的术语的双重问题。

因此，为了解决这个问题，你只需要在所有地方都设置“生产”环境。

是的，不要使用它。并且，对于使用该库的特定冲突，请不要使用该模块，伙计们。你，你，你将陷入麻烦。

顺便说一下，很多人正在使用它。那么，你如何实现与现实世界中相同目标？

哦，你可以使用任何你想要的东西。你甚至可以使用“不等于生产”这个词，但它有不同的含义，或者说“生产”不等于“暂存”，好的，因为很多库在代码中会对这个特定的反应做出反应，会对这个特定的反应做出反应，好的。如果你不设置它，你将得到非常不同的结果。因此，你需要始终在部署到服务器时设置它。即使在暂存环境中，也需要这样做，是的，你的暂存环境不等于你的生产环境，那么你就麻烦了。

我实际上已经掉进过那个精确的陷阱，或者是在一个测试环境中，但我必须将环境设置为生产环境，以便让它看起来像生产环境。我无法将其设置为测试环境，因为事情无法正常运行。所以我能体会你在说什么。

我已经感受到了。我同意IT的单一十倍。同样的故事，不同的东西，对吧？所以基本上是一样的，我认为我们可以跳过这一条。

让我们完全转向更少。我们无法上线，我就会变成一个骗子。第八点，处理错误并提供有意义的日志记录。

这听起来就像，你知道，呼吸，吃饭，但一次脚从另一个脚上。但有时我们必须陈述显而易见的事情，而且很多时候，作为开发人员，我们很匆忙。我们有很多事情要做，功能要发布，我们有倾向，我限制，有时会有点懒惰。

我们知道错误不太可能经常发生。有什么大不了的？Nota，你anna，开始讨论这个话题，处理错误并提供有意义的日志记录。

即使错误只发生一次，那也是对的。但是，是的，就一次。我认为它不能。

我们有时不太擅长处理从数据到应用程序的错误。应用程序。所以我们应该从非常低级别开始，然后向上走。当然，你需要创建有意义的日志记录，以便在出现问题时简化你的工作。

但这也因为我们正在构建与用户交互的应用程序，对吧？你还要将这些信息传递给客户端，并确保每个人都能随时了解情况，这至关重要。错误处理就像一种技能，就像开发人员的本能一样，应该自然而然地出现在脑海中，应该放在首位。而且还有其他一些盐。

这是重复和不承认我过去二十多年编码生涯中犯过无数次错误的一部分。大多数时候，我不处理错误，是因为我不知道该怎么做。我当时想，如果真的出现错误，我该怎么办？

我不知道。记录错误并继续。但是，你有什么关于错误处理的建议吗？我想这取决于具体情况。所以也许你可以提供一些通用的建议，但你是否遇到过这种情况，你不知道错误是否出在这里？

我们该怎么办？最大的问题是知道有人会捕获你的错误，尤其是在长期的承诺链和更长的异步操作中。你需要知道有人在最后捕获你的东西，承担责任，美丽，是的。

另一个要点是实施优雅的关闭模式。这对于你的应用程序来说非常重要，除非你明确不想这样做。但我不会深入探讨这种情况。所以当发生错误时，如果它没有被捕获，它会崩溃你的系统。它会摧毁你的Node服务器。

你想做的是尽可能优雅地处理，这意味着通常停止接受新连接，停止接受新请求，处理正在进行的请求，然后，然后，好吧，但你不知道否则？如果你有十个同时运行的连接，你中断它们。它们将一无所获。

所以这通常是一个问题，很多人都解决了这个问题。我用运行的j在我的lambda函数中，我解决了这个问题。他们为此付出了代价，这是一个解决方案。但否则，你可能想要优雅地关闭。

你想。你经常看到这一点，只是缺乏优雅的退出。

它们一直存在，而且经常实现不正确，这意味着一直如此。

这很难。我感觉好像聊天机器人可以为你做到。

聊天机器人不能，你不需要这样做。

好的。

好的模块链接。如果模块有问题，那么你就可以了。但是，在做这些事情时，你还需要考虑其他一些情况。我很好地处理了这些情况，你知道，与其他许多情况一样。

对吧？所以这里的重点是npm安装优雅关闭，母亲你。

在谈论优雅关闭。

是的，就是这样。再听一个依赖项，你继续。

这是一个好主意。这是一个我们允许的。

好的。嗯，你在这里也有一小节，关于如何处理。你不会深入探讨，因为有时你记录的信息太多，有时又太少。

有不同的日志级别。这非常详细，但我们可能不想在节目中深入探讨。你认为呢？阅读文档？是的。

阅读文档。

阅读文档。让我们继续。第九点，使用API规范并自动生成客户端。这是一个非常有争议的观点，因为你知道自动生成的客户端有时可能不太好。

但是，如果你不喜欢API规范呢？我应该使用哪个API规范？为什么我不能简单地手动处理所有事情？谁想接手这个话题？因为我认为我同意你的观点，但我看到自己可能会在我的应用程序中跳过这一条。

你总是独自工作吗？

因为我，是的，这就是为什么我会跳过很多仪式，因为我这样做。所以，是的，这不是你的目标受众。

因为这是针对企业的。所以你们会就API的形状达成一致。这没错。

所以不要问我任何我说的。我来自后端。继续。告诉我们你需要合同。你需要就API规范达成一致。你，我假设，你不想每次都不得不自己发明。

对吧？你希望在你的许多API中保持一致。对吧？

你想使用相同的模式。你想确保。你想使用相同的异常。你想确保任何来到你这里的人都能立即理解如何建立连接，无论是客户端到服务器还是服务器到服务器。

那么我该如何选择规范？有开放的API。有图形化的。

它是OpenAI。但我认为我们不一定同意。

可能会有不同意见。

但是，是的，开放API，是的，我说。

开放API，我看看。

你认为呢？

我想说图形化输出。我只是想有一些。

意见分歧。我喜欢诚实的意见。这真的取决于应用程序。你真的可以使用任何东西。

我只是使用一些东西，然后如何生成客户端。那么我们在这方面使用什么？我认为可能有一些专有解决方案。有很多方法可以做到这一点。

也许会偏离主题，但我们正在开发一个开源生成器和API规范工具。微软的OpenAPI规范类型支持，这是一个工具，是的，定义规范并生成。

代码是，是的。

类型规范，我实际上将在即将举行的类型脚本会议上谈论类型脚本。巴黎，所以是的，我们正在推出它。

好的，在节目中讨论这个话题，不是那么好，OpenAPI规范类型支持。你对此表示认可。你是否。

做一些事情，老实说，或者可能做一些事情，玩一下，好的。我更倾向于开放API。

好的。大多数来自ma。而且它们整合得很好，很不错。

好的？我也真的很喜欢图形化，这取决于我们作为一部分需要做什么，这取决于用例，好的？所以有些事情用图形化更好。

如果你不知道数据将如何创建，那么图形化可能是一个不错的选择。如果你有多个不同的客户端，并且你知道团队之间缺乏沟通，否则，如果可以的话，开放API实际上还不错。所以这取决于公司，取决于用例，取决于业务，取决于很多因素。

不，我曾经在讨论中被困住，只是想在某个时候做一些事情。我当时在聊天。每次，因为他们需要做的流程，他们都需要添加更多。我作为公司消费者的API调用，与他们咨询，花了他们四个小时。

哇。就像。

这简直就是烧钱，就像你真的在烧钱。而且我喜欢一些东西，你知道，这是计算机应该做的事情。也许甚至收费，但这可能甚至会让我想要改变你，因为这似乎是很多繁琐的工作。好的。我不会在那个点上交付任何东西。

是的，我不想隐藏，讨论这些支柱，但我们也写下了它们，因为在企业中工作，你理解为什么利益相关者，比如经济买家，以及那些开发人员需要理解的人。因为有时开发人员会说，我需要X、Y、Z时间，因为我需要编写规范，因为我需要编写错误处理，等等。不，不，不，你只需要完成功能并将其发布。不，因为这会带来更多收入，你可能会更快地完成工作，但你将不得不解决很多问题，这些问题最终会让设计、规范和架构人员感到沮丧。这是一种错误，箭头指向。

我多年来一直在重复的相同内容，那就是放慢速度才能更快。很难让人理解这一点，但这绝对是正确的。做软件的正确方法是放慢速度才能更快。

好吧，现在让我们加快速度。我们已经到达了终点。还有一个通用的。但我将把它放在最后，因为我们不想让听众睡着。现在在谈论。

测试是朋友和派对的人。我在这里。我与Jam的联合创始人兼首席执行官坐在那里。

我们的新赞助商之一，Jam.dev，提供开发人员喜欢的错误报告，非常简单。今天免费获取Jam，访问jam.dev。Dane，你如何解释Jam以及它如何帮助团队更高效？

Jam是捕获错误并让开发人员更快地调试错误的最快速方法。它是一个浏览器插件，连接到开发工具。

因此，当团队中的任何人都发现错误时，他们只需点击一下即可捕获发生的情况，以及开发工具控制台日志、网络请求、会话信息等所有内容。它会将其放入工具链接中，当你打开工单时，你拥有调试所需的一切，你无需提出任何后续问题。这可以让开发人员专注于构建新功能，而不是修复旧功能。我认为软件工程师所能产生的最大影响是为客户构建未来，让事情变得更容易。

这是构建未来。因此，我们希望确保你不会花整个下午来回溯错误。相反，你拥有所有所需信息，可以立即开始。

好的，朋友们，访问jam.dev，了解更多关于Jam如何让团队轻松快速地进行错误报告和所有这些事情的信息。今天免费获取Jam。Jam.dev，再次是jam.dev。

现在让我们回到，我称之为没有特定主题的，也许不是特别针对Node的，回到顶部。第一点，不要阻塞事件循环。其他事物也有事件循环，但Node当然也有。是的，这似乎是一个很好的第一点。所以我们想从这个话题开始。

嗯，不要阻塞事件循环是我最喜欢的，但我可能会像大多数人一样，如果他们不了解开发人员的工作方式。这就是为什么第一点，老实说，当你调用它时，你没有收到任何反馈，你没有意识到它正在事件循环中执行。其他人不明白这一点，他们不认为这是一个问题。

所以他们不认为我不知道一些事情需要5000万秒的CPU时间才能完成。这总是很快。

对我的机器来说非常快。结果在生产环境中非常慢。第二，5000万秒，好的，意味着你知道。

你可以在一台机器上每秒处理20个请求。现在，一台机器上每秒20个请求是否足够快？这就是重点。

而且，如果我在本地尝试，我可能会说它很快。好的，就像我经历过一些这样的争论。好的。然后，这就是主要问题。

哦，你可以解决它，有很多技巧，它们列在那里，但可能需要意识到这是一个问题？如果你认为你大多数时候解决性能问题的解决方案是最明显的，那么你已经设计好了你的应用程序，你需要真正思考你的系统，这样。

它不会锁定。

我同意你的观点，我认为有很多人正在努力教育社区关于事件循环的工作原理，因为在JavaScript中正确理解所有逻辑，当然，理解事件循环的工作原理，以及事情如何顺利进行或卡住的原因以及如何确保你不会造成这些阻塞。但是，是的，基本上，我最喜欢的也是。

低垂的果实。就鹰而言，我知道狗有细节，但人们总是做的一件事就是不明白事件循环本身。

不明白它如何工作，退出时如何工作，对吧？

我们会把人们带出来，让他们理解事件循环，这会让你少受很多痛苦。这可能成立。

因为你理解了你的事件循环，你可能会在使用的工具上做出不同的选择，因为大多数时候问题出在你的选择上，你做出了选择。你认为根据某些参数来说这是很好的，然后你又学到了一些其他的东西，然后你看到，哦，也许我犯了一个错误。好吧，至少你知道……

现在，你可以……

修复它，这会让你在可以做的事情方面陷入困境，其中一件事是监控事件循环利用率。你可以指出一些工具，以便了解，你知道，如果你目前没有事件问题，然后你引入一个依赖项，现在你有了事件循环问题，这对你来说是一个非常明显的反应。如果你监控它，那么至少你可以看到那件事什么时候爆炸以及它如何变慢。

是的，我想你提过一些工具。

我们基本上正在转向第二点，这是一个很好的循环。是的，啊，马蒂，或者不是特定的矩阵，等等。最大的问题，就像我经常被问到的，你能告诉我为什么进程会崩溃，好吗？或者如何获得良好的性能？你知道你用什么来监控和衡量系统的性能吗？当我在使用遗传指标时，你知道你在驾驶，你知道你在用盲目的方式做出道路选择。

所以，你期望崩溃，好吗？你尝试用正确的方向驾驶，你看着错误的东西，你根本没有关注你需要关注的东西。这基本上就是这个原则，特别是关于事件循环，你需要知道，如果你有生产应用程序，你需要知道你的应用程序和基础设施的健康状况。如果你不采取行动，你的应用程序会崩溃，你知道你没有流量，没有用户。如果你没有流量，没有用户……

什么都不会发生。

我觉得我建立了一些……

这样的网站。没有流量，没有用户。

是的，没有资源。

是的。是的，一切进展顺利。不，负载从未……

只是有点。关键指标是什么？你关心什么，你知道吗？关键指标是什么？

嗯，我说的最终是这些新方法，我们最近大多数人都不知道，它基本上是事件循环处理事件的百分比。好的，它给我们一个非常直接的数字。然后我们想要内存，但不是访问内存。

居民集大小不使用它。这是一个糟糕的指标，好吗？你需要关注它。

但老实说，这不是重要的一个。重要的是堆使用率。所以，我们做所有内存，你给它。

如果你注意，你说，好吧，不要使用 1GB，好的，是的，但我这样做。我遵循它，我遵循它，好的，啊，但是然后它，它，我们都用 Chrome 做过。好的，当你打开很多 Chrome 标签页时，每个标签页都可以占用 1GB。兆，对吧？总之，关于有多少内存正在积极使用，好的，等等。

这指的是，当你的应用程序需要它时，它将分配一定数量的内存，并且它可能被大量过度分配，我可以说我正在使用 1GB 的 RAM。

不，情况并非如此，你拥有 1GB，你知道通常是这样的。好的，你有一个应用程序块。你可以称它为，嗯，应用程序的一部分，它分配了很多内存。好的，这部分内存不会很快被清理。

然后基本上他们有这个垃圾收集器，想，你知道，清理这个东西需要很长时间，所以我把它停在那里，你知道，也许以后我们有时间清理它，但是系统中仍然有可用内存。它是免费的。我可以得到它，所以我得到更多内存。它非常懒惰。

所以，然后他全部……

是的，那个人是对的，他更喜欢，而不是清理，你知道，它在某种程度上看起来像一个青少年，他更喜欢做其他事情而不是今天清理你的房间。

去外面买些新衣服，先把地上的那些清理干净。

清理起来很累人。所以我只是让你在那里出汗，免费给我。

就是这样。所以关键在于堆使用率与堆总量。你从居民集大小中获得的信息会更少，不幸的是，它也是 RSS，但它并不是一个真正简单的指示，当然，在上下文中，它不会造成混淆。

但就我们谈论它而言，也许它就是，当然，就像你说的，事件循环利用率，这是最重要的一个。然后当然还有 CPU 使用率，比如处理器整体使用情况，对吧？我通常会关注这些。

好的，让我们继续第三点，在生产中使用 Node LTS 长期支持版本。对我来说，这似乎是最企业化的。但是，别名却在摇头，心想，人们应该这样做。

是的，我见过很多这样的情况，你知道，你的，我知道，很好，但它不起作用，然后你检查他们正在使用哪个版本的 Node，当然，15、17、19。但为什么？

但为什么，我能回答这个问题吗？我的意思是，因为你知道，没有人在这方面做了一些我想要使用的东西。

对吧？没错，但在发布 LTS 之前，不要在生产中使用它。

那么 LTS 与非 LTS 相比给我们带来了什么？对于那些不知道的人，不是刚刚发布……

所有最初的几个，长期支持，持续 18 个月……

现在是当前版本，6 个月后，支持……

再过 2 年半……

好的。

但是他们只从中获得 12 个月作为活跃的 LTS，这意味着它会落后于新功能和改进，这很好，但不是……

LTS 获得了大约我认为你写过的 7 个月。

6 个月、7 个月、7 个月。1 个月，我会称之为 6 个月。

但 7 个月，几个月。

6 个月加 1 个月的宽限期，我们也在……

修复安全漏洞，好的。慢……

是的，对于那些低级的人来说。但老实说，我会直接把它砍掉。如果我，如果我不这样做，我会喜欢它。

是的，如果你正在发布 Node 版本。

D。

D、F、L 或其他什么，你只需要问一下。但你做错了。所以 LTS，长期支持，你获得的好处包括降低风险、减少破坏性更改、增强安全性、提高稳定性。

我告诉你，为什么不呢？为什么不直接使用它并在生产中获得所有好处？在 6 个月或 7 个月内，在尾部有 6 个月……

还有使用 LTS 但使用它长达 10 年的人，对吧？所以，所以，在版本发布的那一天。现在，不要这样做。

保持你的……

版本更新。

我现在想知道 Node 的向后兼容性如何。我不断收到新版本，其中包含破坏性的大量更改，这让我非常痛苦。但是升级你的 Node 版本，你们有什么经验吗？

我维护了这个东西。所以老实说，我们尽量不要破坏任何东西。

大多数人离你太近了，离你太近了。

我离你很近。我开放，但我如果我们这样做，我们会很抱歉。

但是你需要考虑，你无法永远保持向后兼容性，否则你永远不会在规范中引入任何创新更改。你如何做到这一点？没有办法，对吧？你必须两者取其一。

对吧？你想创新，你想改变。

你想得到它，这就是问题所在。

在其中获得类型安全支持。

不，这不是破坏。

不，不，这不是破坏……

因为你不使用它，因为你使用一个标志来使用它。

没错，它已经……

所以，一个团队，感觉就像一个个人……

g 对抗……

独自一人，他一直……

在图中走着……

在类型类型方面关注我。所以，来吧，什么不是。

不。但我我是 AT。我在……

我这里只有三个 JavaScript 用户。我也不是 TypeScript 团队的一员，主要是因为微软的宿主不在这里，而尼克·内西是你可以想象到的最大的 TypeScript 支持者。所以我们不能在这一点上达成太多共识。

所以我只是采取了我的立场，只使用 TypeScript。而且，正如我之前所说，我不喜欢仪式，我不需要所有这些面向团队的活动，你知道，这让我们来到了我们的最后一项原则，它也是通用的。

但我把它留到最后，因为你知道，就像吃西兰花一样，关于西兰花的通用提示是，如果你不喜欢它，先吃它，因为当它冷的时候？它甚至更糟，对吧？当它热的时候，至少是这样。所以我们在这里，自动化测试、代码审查和一致性。

哦，这是三件事。为什么？为什么我必须这样做？我们可以跳过这一部分吗？

测试生产？

要了要了，就像……

如果你关心你的工作，如果你关心你的工作，不要这样做，这是一种好的遗传原则，就像高门槛一样。

如果你关心你的身体，你会吃西兰花，对吧？所以，我听说它对你有好处。

告诉你该怎么做。

你不需要喜欢它。

但是你必须这样做，我不喜欢它。我不是那种总是找到如何编写测试的人，因为我不喜欢它，但你必须这样做，没有办法绕过它。

代码审查中的一致性部分是什么？理解？测试？你理解一致性。

哦，你需要……

标准。

你需要，是的，但是你还要有约定。所以，是的，你需要有约定，你需要有标准。你需要任何你公司同意的内部标准，让每个人都对我们将如何做这件事，我们将如何编写代码，我们将如何理解彼此在编写代码时达成共识。我……

正在审查它，对吧？

你如何审查某些东西？如果你不知道什么是正确的，什么是错误的。

那么这就是工具的世界，对吧？工具在这方面非常有帮助。否则，它就像一堆小挑剔的代码审查，说，嘿，我们不要在那里放分号，等等。

所以，像 linters、样式指南，等等。可能还有更大的架构文档，你决定我们将如何做。我们不会使用单线程。我们不会，我们将阅读 Node 原则，等等。

是的，我们不会……

我可以阻止事件循环吗？你有一些团队成员这样做，对吧？我们不会阻止事件循环，但简单地编写时间，在谈话中工作，在家庭中工作，对吧？所以，我们已经到了九项原则的结尾，一个相当不错的覆盖范围。

当然，细节才是关键，它们都在文档中。所以我们不想只阅读文档，而想谈论它。那些没有完全实现的原则呢？我相信这是一种聪明或过程。我知道你从四五个增加到九个，但肯定有一些遗漏的，还有 10 个，等等，为什么不把它们放进去？但仍然是好建议，在编辑室地板上遗漏的东西仍然值得提出。

我认为 TypeScript 在某种意义上可以成为一个原则。但是，但是，你想要让每个人都像你一样使用 TypeScript 吗？不，对吧？是的，我们说过你，是的，但是我们没有说，请不要使用 Node 的有效版本，这应该很明显，对吧？

我们坚持……嗯，我……

我想激发人们，好的，我真的很喜欢在编写 TypeScript 代码、与团队合作和构建应用程序时获得的经验。我绝对认为，从一个开发人员的角度来看，作者的经历，有人自动化了 NBM。

使用 JavaScript 并编写类型比手动编写要好得多，你知道，好吧，我可能不会那样做，它就像旧的船只故事一样困难，对吧？它让维护这些东西变得更加困难。我可以维护很多模型，因为他们只是给我添加了 Java 注释。

但是，是的，如果我想把它作为建议，我会说，你知道，所以需要花费时间来围绕它构建工具，使其可用，这会给你带来很多好处。所以这是真的。但是，如果我维护的东西需要很长时间，优化消耗的时间通常是……你有没有看过……

在 JavaScript 团队的文档中，新的注册表，他们正在尝试使发布类型化包变得非常容易。

这是一个朝着正确方向迈出的好步骤。我认为这基本上意味着减少类型选项的范围，减少测试、工具等方面的能力。这是一个好步骤。

好的？目前我们有一些需要注意的消息。很遗憾。

我有没有选择？好的，我的意思是这对库作者和依赖项作者来说很棒，对吧？但是，在你的应用程序中，你仍然需要进行转换，对吧？所以你仍然需要……

是的，如果你……

一个应用程序。

当然。

所以，丹尼尔。

是的，我认为当前的销售策略是针对套餐优惠。两个套餐优惠是否比你通常的活跃用户（他们仍然像你说的那样拥有这些工具）更好？如果你走到最后，还有任何未说的话，你们想大声喊出来或提供链接吗？

现在是如何连接到一个平台。你可以在 Matic 的博客文章中找到它。你也可以在我们的节目说明中找到它。

还有什么吗？我想感谢其他两位嘉宾。好的，迈克尔和詹姆斯。

现在，每个人都回顾一下这个适合度不好的部分。这是合作、合作的成果。好的？是的，这可能是我能做的。

我想强调一个非常重要但未提及的关键点。在为维护者提供经济支持方面，已经出现了一个明确的转变。这非常重要，并且已经成为一个名为“开源冰箱”的东西。我想建议大型公司为维护公共资源贡献开发时间或资金。这并不意味着加入承诺，但你基本上需要使用很多开源资源。

如果你依赖一个关键的开源组件，向维护者发送一些资金通常会对他们有很大帮助，或者甚至只是给他们一份工作，让他们有机会作为你的团队的一部分来完成这项工作。不，最后一点更重要，因为许多大型公司不会将开源或公共开源作为其促销套餐的一部分，这对许多想要从事这种开源工作的人来说是一个巨大的问题。你看，我做了所有这些工作，但这并没有给我带来任何工作上的好处。

那么，我为什么要做这些呢？在某些时候，你会感到精疲力竭，一切都会变得一团糟。所以这可能是我最后要说的。请考虑赞助支持，看看你如何让维护者的生活更轻松，而不是试图像吸血鬼一样吸他们的血并让他们精疲力竭。

好，说了这么多。你还有什么最后想说的吗？

你知道……第二，那个承诺来自市场，并且积极参与开源。

说得很好。好的，代表塔奥和……我感谢大家收听本期杰斯派对的节目。所有相关链接都在节目说明中，也感谢其他……

我认为在码头崩溃是一个对整个社区非常有用的资源。感谢你的写作。我是杰里。这是本期节目……

下一个。谢谢。

好的，这就是本周的杰斯派对。谢谢。我们今天有……你知道吗，我们正在进行一年一度的合并促销活动？所有合并产品都打折，先到先得。

给自己或你关心的人买一些新产品，在 merchthatchangelog.com 上享受高达 40% 的折扣。再次感谢我们的合作伙伴 FlightIO 和长期赞助商 CenturyUse。使用代码 changelog-s 在 AN、Plan the Freak 和 MC 上观看我们的节目，没有你们，我们的节目不会一样。接下来在播客中，尼克和凯布尔从 React US 回来了。他们在那里进行了很多精彩的对话，我们正在整理并准备在下周发布。