NodeJS应用架构最佳实践

Question

我们有 Nodejs 项目，其中一个是主项目。 我们在其他项目中使用这个（主项目）功能。 我们将我们的主项目安装为 package 和 NPM 到其他项目，然后使用我们需要的功能。

但是这种方式在主项目和其他项目之间产生了许多紧密的依赖关系。 每次我们更改主项目时，我们都需要在其他项目中更新它的版本，并在其他项目中安装 NPM。

请告诉我您在这种情况下的最佳做法的想法。 我们如何处理主项目和其他项目之间的这种依赖关系？

谢谢

Answer 1

让我们从全局模式和措辞开始。 如果一盒函数被用作其他项目的工具箱，你不应该把它当做主项目。 它只是一个需要的库。 如果您愿意，可以将其称为基本库。

一个主要项目将是唯一的顶级 package，它需要所有其他包。 由于您有多个项目，因此主要项目一词不合适。

框架是一个更复杂的案例。 好像不是，你在说什么。 如果它是一个通用框架，我仍然会称它为框架而不是主项目。

现在已经将部分设置到适当的位置，让我们谈谈依赖关系。 所有项目都依赖于这一工具箱。 如果此工具箱编码良好，它将适用于所有项目。

如果它不适用于所有项目，则其中有代码，这不是通用的，而是专门针对单个项目的。 这部分代码是罪魁祸首。 单个项目专用的代码，应作为回调 function 注入。 然后工具箱会执行它，但是特殊代码仍然在特殊项目的代码库中，因为那里定义了回调。 这种回调注入是javascript最强大的部分之一。

然后为您的代码编写测试。 编写测试是干净注入和良好架构的最佳顾问。 我还暗示了“依赖注入”这个术语。

所有这些听起来都很棒，但是如果您调整公共库，作为副作用，其他项目仍然会中断，对吗？

这不是架构问题，而是库的维护和发布周期问题。 API 在次要版本中进行了扩展。 重大更改应该只发生在主要版本中。 如果升级到主版本，所有项目都需要调整为更改后的 API。 因此，中断版本应该很少见。

同样，完整的测试覆盖有助于快速将代码调整为主要版本。 测试揭示了每一个破坏 function 的测试。

您仍然需要从当前情况到令人满意的情况的迁移路径。 这里的答案是 git 存储库。 为每个项目创建一个基本库的分支，以保持您的业务正常运行。 然后随着时间的推移将不同的分支合并为一个抽象的稳定分支。

所以我的回答有五个部分：

1. 在您的思维方式中将术语“主项目”替换为“基础库”。

2. 使用 git 中的不同分支作为迁移路径。

3. 然后了解注入，回调形式的注入和依赖项的注入。

4. 尽可能测试你的代码。 还有更多的理由这样做。

5. 最后遵循基本库的标准发布周期。

当您要求最佳实践时，第五点的答案是“语义版本控制”。 https://semver.org

在semver之后，您的 package 将干净地工作npm的基于版本的依赖项管理器。