基于 express 和 react 的应用程序的一般做法是什么。将服务器和客户端代码保存在相同或不同的项目/文件夹中？

Question

我来自微软背景，我总是习惯将服务器和客户端应用程序放在不同的项目中。

现在我正在编写一个客户端 - 服务器应用程序，后端为 express，前端为 react js。由于我完全是这两个工具的新手，我想知道..

一般做法是什么？：

将快递（服务器）代码库和反应（客户端）代码库作为单独的项目？或者将服务器和客户端代码库放在同一个项目中？我想不出这两种方法的任何优缺点。

欢迎您提出宝贵的建议！

PS：请不要将此问题标记为自以为是..我相信有正当理由要求建议。

Answer 1

在我看来，最好在这里有单独的项目。但你让我思考了一些乍一看似乎显而易见但实际上并非如此的“原因”。

我的期望是，一个项目应该主要是一对一地组织构建单一类型的目标，无论是网站、移动应用程序还是后端服务。项目通常是构建或以其他方式输出一个功能性独立软件组件所需的所有依赖项的表达。软件开发生态系统中的构建和测试工具是围绕此约定组织的，正如行业期望一样。

即使您可以提出生成多个软件组件的整体项目有优势的论点，您也违背了人们的期望，并且这就产生了更多学习和沟通的需要。因此，在所有条件相同的情况下，最好选择更受欢迎的选择。

单体项目的其他常见缺点：

制作与多个子项目一起使用的宏观项目也是很有可能的，并且在某种程度上具有这两种方法的优点。这基本上只是某种构建脚本，它获取子项目构建的输出并结合它们执行一些有用的操作，例如部署到服务器环境、运行自动化测试。

最后，所有开发人员都应该配备可以让他们轻松地在不同项目之间切换的工具。如果这样做很困难，最好解决它们，而不是诉诸单一的项目结构。

一些有助于开发依赖于多个项目的基于 React/Node 的软件的实践示例：

IDE 轻松支持编辑多个项目。而不是以某种繁琐的“一次加载一个项目”的方式。
项目被部署到一个存储库，npm 或yarn 可以轻松使用该存储库作为依赖项加载到软件组件中。
使用“npm link”一次性处理子项目的可编辑本地版本。更一般而言，不需要完整的发布和部署操作即可访问您正在开发的子项目以及基于 React 的主项目。
使用 Jenkins 等自动化构建系统来处理宏观任务，例如一起构建项目、部署或运行自动化测试。
在 package.json 中谨慎使用版本控制。让每个软件组件都有自己的版本号并遵循 semver 约定，该约定指示更改何时可能会破坏兼容性。
如果您有一个团队（开发人员）开发前端和后端软件，请在 package.json 中设置依赖项版本，以始终获取子项目（包）的最新版本。
如果您有单独的团队负责前端和后端软件，您可能希望将依赖版本放宽为仅在 package.json 中使用 semver 范围的主要版本#s。（基本上，您需要一些保护来防止重大更改。）