【Node Weekly #419】 Node.js 框架选择指南
🥳 欢迎有兴趣的小伙伴，一起做点有意义的事！本文译者：oil-oil
我发起了一个周刊翻译计划，仓库地址：github.com，访问地址：fedarling.github.io
现在还很缺志同道合的小伙伴，纯属个人兴趣，当然对于提升英语和前端技能也会有帮助，要求：英语不要差的离谱、github熟练使用、有恒心、谦虚、对自己做的事负责。
想参与的小伙伴，可以 wx 联系我，也可以给仓库发issue留言，我博客也有具体的个人联系方式：daodaolee.cn
我经常在社交媒体或者评论区看到有人问：”什么是最好的node.js框架“，得到的回答往往都非常主观， 一些开发者甚至还会为此争论不休。如果你正在为你的项目找一个合适的node.js框架。那这些回答基本对你没啥帮助。
大量可供选择的框架，以及这些偏主观的看法，会让你更难抉择。基于这些框架的功能特性列表来进行选择也会让你很头疼, 而且这些特点也只是框架的一部分描述而已。 如果你有一个清晰的清单可以用于评估和选择 Node.js 框架，那就太棒了。
我无法为你提供详尽的清单，因为每个项目、团队和开发人员都有不同的需求。不过我确实有一些指导方针可以帮助你思考在选择 Node.js 框架时什么对你来说很重要。
感谢以下几位朋友，他们在 Twitter 分享了他们在选择 Node.js 框架时所考虑的因素：Matt Hinchcliffe、Alex Wilson、Alexey Antipov和Anthony Bouch。
你的具体使用情况如何?
一切从实际情况出发。在开始寻找一个框架及其功能之前，请先明确的需求。这将帮助你确定框架是否旨在支持你预期的功能。要是没有提前明确好的话，你可能会发现自己在构建应用程序时与框架有冲突。
以下是一些你可能需要考虑的情况:
- 全栈应用与 API。你的应用程序是提供 HTML 页面还是发送 JSON 响应的 API？如果它是一个 API，它是基于REST还是基于GraphQL？
- 服务端渲染。你打算在你的项目里使用 React 或 Vue 组件吗？一些框架提供了帮助程序来简化在你的项目里集成这些框架的过程。
- Serverless。你是否会将你的应用程序部署到Serverless平台？对于 AWS Lambda 等Serverless平台来说，冷启动时间真的很重要。如果框架在处理请求之前需要进行大量初始化，则可能会对你的请求响应时间产生很大影响。
- 即时通讯。如果你想使用 WebSockets，请寻找内置框架支持，或与框架集成的社区维护库。
- Typescript。你想用TypeScript开发项目吗？有些框架只为 TypeScript 设计，有些框架提供了类型定义，而其他的只提供由社区维护的第三方类型。即使你不打算用 TypeScript 编写代码，你的代码编辑器也可能会根据框架的类型定义为你提供有用的提示。
框架样式
有些开发者喜欢“开箱即用”的框架，有的人就不喜欢。“开箱即用”指的是 HTTP 请求/响应处理和路由之外的功能。这可能包括验证、日志记录、身份验证、数据库抽象和依赖注入等功能。此类别中的框架往往对如何构建项目做了限制。它们要求你以特定方式进行开发，以便你可以利用它们提供的功能。
而另一个极端是你会发现一些最简单框架。它们倾向于只提供 HTTP 请求/响应处理、路由处理，不集成其他功能。他们并不是特别固执己见，并为你提供根据需要自由构建项目的权利。由于它们提供的“开箱即用”功能数量有限，因此你需要选择并集成其他的包以提供其他需要的功能。
有框架就比较均衡。他们有自己的构思并提供一些除基础功能外附加功能，例如日志记录和验证。你选择的框架风格可以通过我上面提到的用例来指导。这也可能取决于你的个人喜好（或你团队的喜好）。你可能还没有任何偏好，但如果你注意每个框架的风格，将会有所帮助。
支持 promises 和 async / await
随着 Node.js 和ECMAScript 的发展，围绕回调模式设计的应用程序已经逐渐消失。相反，我们现在可以愉快地使用 promise 和async/await 进行开发。这意味着 Node.js 框架具有promise化很重要。它们应该允许你编写async路由处理函数，并为你安全地处理未捕获的promise rejections。
如果框架不满足这些基本要求，则会增加应用程序中内存泄漏或崩溃的风险。我写了一篇深入的文章，解释了为什么这很重要以及需要注意什么。
文档
首先，你找的框架有文档吗？！如果没有文档，你可能很难使用框架开发项目。要避免使用没有文档的框架。
一旦你确定框架是有文档的，请尝试了解文档质量。并非所有文档都是一样的，因此需要考虑以下几点：
- 你可以轻松地使用它吗？文档的结构真的很重要。如果有内置搜索功能，它也会有很大帮助。
- 这对你有意义吗？可能有很多文档，但如果它写得不好，它不会有太大帮助。
- 你认为你可以在开发时用上文档吗？阅读和理解如何做某事是一回事，而在构建真正的项目时自己应用它则完全是另一回事。
演示实例
学习使用框架时，阅读长篇大论的文档以可能会让你一时不知所措。如果有可用的实际示例向你展示如何使用它，一旦你对框架的功能有了大致的了解，那对于你上手框架来说很有帮助。“hello world”示例可能会向你展示如何使用框架的基础知识，但如果你想做更复杂的事情，这通常没有多大帮助。实际示例将展示你可能需要解决的实际问题的解决方案。理想情况下，他们还将展示使用该特定框架的“最佳实践”。
你可能会在框架文档中或examples在项目的 GitHub 存储库中的文件夹中找到实际示例。一些框架甚至在 GitHub 上有完整的演示示例，你可以浏览、运行和挑选它们。
了解创建框架的人如何使用它是学习如何自己使用它的绝佳方式。不仅仅是通过文档磨练你的方式，实际示例将帮助你使用新框架加快学习曲线。
社区和生态系统
围绕框架存在的社区确实很重要。当遇到莫名其妙的bug时，最重要的是知道可以去哪里寻求帮助。看看你正在考虑的框架是否有评论区、Slack 或 Discord 服务器。深入了解并感受社区。那里的人看起来热情和支持吗？他们乐于接受贡献吗？围绕框架的社区在第一天对你来说可能并不重要，但从长远来看，你肯定会需要它。
框架流行度并不是一切，但你将围绕它构建整个项目。因此看看框架当前其他开发者的使用情况特别重要。如果一个框架被广泛采用，会更容易找到一些周边的库（例如中间件或插件）。在你的项目中将一个库替换为另一个库可能相当简单，但框架通常不是这种情况。
GitHub 上star通常被引用为受欢迎程度的指标，但我认为将它们视为普遍兴趣而不是实际使用情况的衡量标准更好。确定框架是否有其他开发者使用的一种简单方法是查看其包下载数。
它们不能用来衡量有多少项目在使用一个框架——许多框架与其他库捆绑在一起但没有被使用——但它们可以让你了解一个框架是否被广泛使用。你可以在包的 npm 页面上查看每周下载量，npm 趋势会显示随时间推移的包下载量。它还允许你比较包。
系统健壮性
在选择用于构建项目的框架时，你肯定希望能够保证项目能正常运行，并且在可预见的未来将继续得到维护。以下是一些可以用来评估的指标：
- Releases。一些开发人员认为，如果框架已经“功能完整”，那它不需要新版本了，但安全更新和错误修复是必要的。框架（或其依赖项之一）中始终存在重大漏洞的可能性。避免任何未维护且不再发布版本的框架是明智的。
- issues积极度。维护人员最近有很多问题没有回复说明这个项目可能没有在维护了。另一方面，如果根本没有人提问题，则可能表明该框架的使用率非常低。
- 拉取请求。一个持续维护的项目通常会有一些最近的pull request。许多旧的或者不活跃的的突然开放pull request，可能表明该项目不再被维护。
- 贡献者。如果一个框架只有一两个贡献者，则可能表明它周围没有太多社区。如果这些贡献者退出项目，它也会对该框架的长期维护产生风险。一个可持续的项目将有许多贡献者，添加大大小小的变化。
- 依赖图表。一个框架的依赖越多，风险就越大，而且还会使排查项目中的问题变得更加困难。你不需要找到一个零依赖的框架，但你应该对一个框架的依赖图有一定的了解。工具npm graph可以为你提供出色的概览。
总结
事实证明，在选择 Node.js 框架时确实需要考虑很多事情。然而，在评估框架时，你可能要问自己最后一件事：你觉得你会喜欢用它开发项目吗？就我个人而言，如果我不喜欢使用这个框架，那么每次我需要使用它都会成为一件苦差事。最佳的选择是一个满足你的要求并且你喜欢使用的框架。
选择 Node.js 框架可能会很棘手，但希望我分享的指南将帮助你完善你的框架选择清单。祝愿你能为你的项目选择一个“最佳的”框架！
