React + backend - 共享代码时的项目结构

Posted 2023-02-22

【中文标题】React + backend - 共享代码时的项目结构

【英文标题】：React + backend - project structure when sharing code

【发布时间】：2020-04-21 14:39:36

【问题描述】：

我真的很喜欢 here 在处理 React 前端和一些带有 express 的后端时看到的文件夹结构：

root
├── backend
|   ├── node_modules
|   ├── public
|   ├── src
│   │   └── Server.ts
|   ├── package.json
|   └── tsconfig.json
├── frontend (created using create-react-app)
|   ├── node_modules
|   ├── public
|   ├── src
│   │   └── Index.js
|   ├── package.json
|   └── tsconfig.json

我认为将单独的包与单独的 node_modules 分开是合理的，因为前端和后端基本上是完全不同的东西，例如。 G。他们需要不同的节点模块。此外，这种模块化方法在视觉上对我很有吸引力，并且存储库看起来很整洁。

---

但是，当我需要在前端和后端之间共享内容时，我遇到了这种结构的问题。我在项目根目录下添加了一个shared 文件夹，其中包含自己的项目以及自己的tsconfig.json、package.json 等。这种方法是here 和here 方法的混合。对于后端，这完全没问题：正确设置了tsconfig.json（使用TypeScript Project References 和aliased imports），我可以像这样引用文件root/shared/src/myFile.ts：

import  myFunction  from @shared/myFile;

我使用 create-react-app 创建了 React 前端。别名导入不起作用对我来说没关系，所以我必须使用（在前端的 src 文件夹内）：

import  myFunction  from '../../shared/src/myFile';

可悲的是，这些从 src 目录 are not supported 外部由 create-react-app 导入，我不想使用 eject，因为我没有使用 webpack 的经验并且不想要自己维护所有配置文件（这就是我首先使用create-react-app 的原因）。

---

我知道我可以将共享内容移动到前端的src 目录。但这意味着，我必须添加使用Project References in TypeScript 所需的标签，例如。 G。在前端的tsconfig.json 中将composite 设置为true，这对我来说似乎很奇怪，感觉更像是一个黑客。我想要一个单独的 npm 项目来包含我的共享内容。

由于create-react-app 本身并不支持从src 目录之外的导入，我想我可能搞错了大局。我现在使用的文件夹结构不是如何设置带有后端的 React 项目的有效方法吗？ create-react-app 提供什么机制来链接前端和后端之间的文件？我还可以考虑拥有一个带有src 文件夹的根项目，其中有两个文件夹backend 和frontend。但这意味着，我们将在根目录中拥有一个共享的 node_modules 文件夹。

这是我使用 React 的第一个项目，我很想了解一些此类架构问题的最佳实践。一些指向可靠资源的链接，其中解释了全栈 React 开发的项目结构，这将非常有帮助。谢谢？？？？

【问题讨论】：

作为一个花了 650 多小时维护我们产品的同构部分的人； （s-s-r、共享代码、实用程序等）我现在可以告诉你最好的方法是放弃 CRA 并为你的服务器转换为 next.js + typescript + 内置 /pages/api。您的前端和后端将融合为一个可维护性提高 100 倍的项目

【参考方案1】：

希望在前端和后端之间共享代码是完全合理的。这是使用 javascript 而不是 Ruby 或 php 编写代码的原因之一。

你可以通过使用 yarn 而不是 npm 和 yarn 工作区来完成你想要的：https://yarnpkg.com/lang/en/docs/workspaces/。在顶层，您在 package.json 中设置了三个模块/包（确保在各自的 package.json 文件中正确命名工作区）：

"workspaces": 
    "packages": [
        "backend",
        "frontend",
        "shared"
    ]
,

完成后，您可以像这样在 CRA 应用或后端导入共享代码：

import  myFunction  from 'shared/src/myFile';

唯一的缺点是，只要您使用 CRA，就无法将 shared 目录中的 react 组件导入 frontend。现在这不会影响您，因为您只有一个 react 应用程序。如果您需要在多个项目之间共享 React 组件，请查看上面的一些建议，例如 bit.dev。

这不是唯一的方法，但它是最简单、最直接的方法之一。

【参考方案2】：

架构是一个棘手的问题，每个人都有不同的意见，每个选项都有优点和缺点。

我个人认为最好将后端和前端分成独立的项目并保持这种方式。现在，由于 JavaScript/React/Node 鼓励基于组件的方法，在它们之间共享代码的一种非常好的方式是 Bit.dev。

https://bit.dev

我目前正在使用它在三个 Web 应用程序和几个 Node 微服务之间共享组件和功能。

可以在这里找到一个很好的 React 应用程序结构，这个结构很好并且可以很好地扩展：

https://hackernoon.com/fractal-a-react-app-structure-for-infinite-scale-4dab943092af

对于 Express，有很多方法可以构建项目，但我个人推荐一个文件夹用于 Routes，一个文件夹用于 Controllers，这就是 Routes 逻辑所在的地方。然后从那里去。看看这个链接：

https://www.freecodecamp.org/news/how-to-write-a-production-ready-node-and-express-app-f214f0b17d8c/

根据您的建筑，您甚至可能不需要完整的后端，您可以在此处查看 JAMStack 以获取更多信息：

https://jamstack.org

我会考虑将它们分开，但随着项目规模的扩大，管理起来会容易得多。你可以在 Netlify 之类的东西上发布你的前端，然后使用 AWS 或 Azure 之类的东西来托管你的 Node/Express 服务器。

【参考方案3】：

由于完全不同的依赖关系，为前端和后端设置单独的子项目非常有意义。混合使用会增加生产部署中的磁盘空间消耗，并违反安全准则。您的文件夹结构是合理的（除了我不确定的public/ 子文件夹，也许我遗漏了什么）。

import myFunction from @shared/myFile; 的方法很好。只是不要使用 CRA。

对于具有单个前端和单个后端的项目，不需要shared\ ***文件夹，因为前端是“UI 真相”的唯一来源（例如类型和组件的来源与 UI 相关）由前端和后端消耗是前端和后端消耗的“API 真相”的唯一来源。通过这种安排，只需共享 @backend/api_shared_stuff。

一些可靠资源的链接，其中解释了全栈 React 开发的项目结构，这将非常有帮助。 一方面，通常项目作者必须解释很多其他事情，并且另一方面，保持文档（通常是自述文件）合理简洁。您可能会发现，提供理由/解释为什么子目录结构是这个而不是那个不是首要任务。