作为一个有一定工作经验的工程师，工作中经常会遇到技术选型的问题。比如当我们在工作中需要使用到 NodeJS 时，第一个要解决的问题就是如何选择一个合适的框架。

不同的框架有不同的特点，如果我们仅仅从框架提供的能力出发，往往会迷失在对不同框架能力的对比中。如果能有一个清单，照着这个清单来考察每个框架，最终选出最符合要求的框架，那就真是太棒了！

我们今天就试图来讨论出一个检查清单，通过这个清单，我们可以找出最适合我们的框架。

我们的使用场景是什么？

使用场景是最重要的考虑因素。在选择框架之前，先搞清楚我们的诉求是什么。

下面是一些常见的需要考虑的点：

• 我们的应用是全栈应用还是只提供 API 服务？ 如果只提供 API 服务的话，是 REST 接口还是 GraphQL 接口？
• 是否需要服务端渲染？ 如果我们使用 React 或者 Vue 来开发页面的话，一些 NodeJS 框架本身提供了对这些 UI 框架的支持。
• 是否需要实时响应？ 如果我们需要使用到 WebSockets，是选择一个支持 WebSockets 的框架，还是找一个社区维护的第三方库来集成到框架中？
• 是否支持 TypeScript？ 我们是否要用 TypeScript 来开发应用？有些框架是使用 TypeScript 开发的，有些框架只提供了类型声明，而有些框架只有社区第三方维护的类型声明。即使我们不使用 TypeScript 开发，类型声明也可以通过编辑器提示给我们带来巨大的帮助。

框架的风格

有些框架除了处理 HTTP 请求和响应以外，还提供了类似于校验、日志、认证、数据库抽象以及依赖注入等其他丰富的功能。这些框架通常对开发者有一些额外的要求，比如要按照框架要求的形式来组织代码才能使用框架的一些能力。

有一些框架只提供处理 HTTP 请求和响应的基本能力。其他能力需要开发者自行实现或者从框架的生态中自行获取。使用这些框架的开发者自由度很高，可以自由组织代码形式。但是当需要一些其他功能时，开发者需要额外付出精力来筛选合适的社区实现。

还有一些框架采取了中庸的形式，即除了提供 HTTP 请求和响应的基本能力以外，还提供了稍许功能，比如日志和校验等。

选择哪种风格的框架，可以从上面列出的使用场景出发，也可以从个人和团队的风格偏好出发。

文档

丰富的文档至关重要。没有人会想一边开发业务，一边通过阅读框架的代码来了解框架的能力。如果一个框架没有文档，我们应该拒绝使用。对于有文档的框架，我们如何评价文档的质量呢？

可以从下面几点出发：

• 是否可以方便的查找？ 比如文档的结构是否容易理解？是否提供搜索功能？
• 文档是否有意义？ 文档很重要，有用的文档更重要。没有用的文档写的再多也没有意义。
• 当写代码的时候，这些文档是否能派上用场？ 阅读和理解如果做一件事是一回事，动手做一件事是另一回事。在我们写代码的时候，文档是否可以直接明确的帮助我们？

实用的样例

说的再多不如写一个样例给我。阅读文档有时候会让我们迷失方向，如同坠入一团雾中。如果有一些官方提供的实用样例的话，对理解框架以及解决实际问题的帮助就很大。官方提供的样例通常也会是解决某一个具体问题的最佳实践。

通常，我们可以在框架源代码的 examples 目录中找到样例，有些框架还会有一个专门的仓库来存放各种各样的样例。

社区生态

一个框架的社区生态非常重要。在选择框架的时候，观察下框架是否有讨论组之类的东西。参与其中的人是否友好、是否乐于帮助他人等。

框架是否流行不能决定我们是否选择这个框架。但是我们在选择框架的时候，要了解是否有其他开发者也在使用。如果我们选择了一个被广泛使用的框架，那么我们通常可以找到其他开发者开发的类库（中间件或者插件等）。

一个仓库的 star 数量某种意义上能够代表框架的受欢迎程度。但是却不能准确的表达框架的使用情况，我们可以从框架的下载量着手。虽然有一些框架被其他类库内置使用，导致下载量很高，但是一定程度上可以说明框架在市面上的使用程度。我们可以在 npm trends 上看到框架的下载量变化。

项目的健康程度

当我们决定选择一个框架的时候，我们还需要确保这个框架在可见的未来时间内依然能够得到有效的维护。

我们可以从下面几个方面来考察项目的健康程度：

• 版本发布频率 即使一个框架的功能已经非常完善了，安全更新和问题修复依然十分重要。因此在面对已经暂停维护或者很长时间没有发版的项目的时候，需要慎重考虑。
• 官方在 issue 的活跃程度 如果一个项目的 issue 里官方成员的参与程度很低，可能在暗示这个项目已经不再维护了。相反，如果一个项目的 issue 很少，有可能说明社区对这个框架的使用程度很低。
• Pull request 一个健康的项目，通常都会有一些近期刚提交的 pull request。如果一个项目有很多很好的 pull request 没有合并，可能说明这个项目已经不再维护了。
• 贡献者 如果一个框架的贡献者只有一两个人，说明社区对这个框架的关注度不高。同时较少的贡献者，会给框架的长期维护带来不确定性。一个健康的框架，应该有很多贡献者参与进来。
• 项目依赖 一个有着很多依赖的框架，可能受攻击的地方也很多。同时，太多的依赖也可能给开发调试带来很多问题。我们可以通过 npmgraph 这个工具才查看一个项目的依赖情况。

这里有一些评价一个项目健康度的工具可以使用：

• Synk Open Source Advisor 这个工具会从多方收集一个包的数据，然后给出这个包的打分。
• GitHub 仓库的 "Insights" Tab 页 GitHub 上每个仓库中的这个 Tab 提供了这个仓库近期的活动情况，包括发版、pull request、issue 和贡献者等。
• Moiva 这是一个开源工具，与上面两个工具提供的能力相同。但是这个工具允许我们同时对比多个框架。

总结

在选择一个 NodeJS 框架的时候，我们有很多方面需要考虑。但是最后也是最重要的一点是，我们在使用这个框架的时候，是否享受使用它的过程。如果不是，那么即使框架解决了一些问题，我们也会非常难受。

选择一个靠谱的 NodeJS 框架有时候非常棘手，希望这个检查列表能给正在做框架选型的人一些帮助。

常见面试知识点、技术解决方案、教程，都可以扫码关注公众号“众里千寻”获取，或者来这里 https://everfind.github.io 。