部署React前端和Django后端的3种方法
如果您要用Django REST开发web应用程序后端，并使用React或Vue开发应用程序前端。有很多方法实现。你需要做出很多选择：
- 您的前端是独立的静态站点还是通过Django视图实现？
- 你把后端和前端放在不同的子域上吗？
- 您是单独部署后端和前端，还是一起部署？
你怎么选择？哪一种是“正确的方式”？
坏消息是，没有正确的方式来做这件事，而且有很多东西要权衡。好消息是，我整理了三种不同的常见选择，各有利弊。
选项1-将所有内容塞进Django
这是“默认”方法，您有一个Django站点，只需添加React即可。所有HTML都通过Django视图提供，所有JavaScript和CSS都由Django负责打包，并以静态文件的形式部署。所有代码，前端和后端，都在一个Git存储库中。您可以在单个域（如www.myapp.com）部署应用程序。
部署代码时，需要：
- 使用webpack或类似的工具构建JavaScript和CSS资源，并将它们放入Django静态文件目录
- 像往常一样部署Django
- 您将需要使用类似django webpack loader的东西来集成webpack的构建资源和django的静态文件系统和模板。除此之外，这是一个普通的Django部署。
优点是：
- 最简单的基础设施。除了设置django webpack loader和在部署过程开始时添加webpack构建之外，您无需对生产结构执行任何其他操作。没有额外的创建，费用，配置，调试或焦虑。
- 同时更新。如果您需要做出影响前端和后端的更改，那么您可以在一次Git提交中完成所有更改，并使用单个部署将更改导入生产环境。
- 更紧密的整合。通过此设置，您可以使用Django的视图通过模板将上下文数据从后端传递到前端。此外，还可以进行服务器端渲染（使用NodeJS进行额外的处理）。
缺点是：
- 前端和后端的单一部署。通常您只想在前端部署一个小的CSS或内容更改，或者只部署后端更改。通过此设置，您必须始终同时部署后端和前端。这意味着您需要等待前端生成，即使您没有进行任何前端更改！更糟糕的是，如果您使用持续集成实践，则其他代码库中的失败测试或linter错误可能会导致部署失败。您不希望仅仅因为有人忘记在JavaScript中使用分号而导致数据库迁移部署失败。
- 混乱的技术堆栈。后端开发人员需要知道一点React，前端开发人员需要知道一点Django才能使这个系统工作。
- 精密的django网页包加载程序。在Webpack和Django之间建立集成对我来说是一个痛苦的过程。我不记得为什么，我只记得痛苦。事实上，这个列表中的每一个选项都会导致你想在某个时刻把你的计算机扔出窗口，而这个也不例外。
适用于：
- 你想让你的基础设施保持简单
- 你不在乎部署时间
- 通常将前端和后端一起部署
- 您需要在前端和后端之间进行紧密集成（例如，数据传递、服务器端呈现）
选项2-完全独立的基础设施
这种方法在过去几年中变得越来越流行。在这个设置中，您有两个独立的代码库，一个用于前端，一个用于后端，每个都有自己的Git存储库。
前端部署为一个“静态站点”，仅包含HTML CSS和JavaScript文件。它与Django分别部署，部署在在AWS S3 bucket、Netlify或类似的东西中。前端是独立于后端构建、测试和部署的。前端通过REST API调用从后端获取数据。
后端是一个Django REST API，没有HTML视图（除了管理页面），并且不承载静态内容（除了admin所需的内容）。它是独立于后端构建、测试和部署的。
重要的是，由于前端和后端在不同的服务器上，它们也将有不同的域名。后端可能位于api.myapp.com上，前端可能位于www.myapp.com上。
优点是：
- 独立部署。部署前端时不需要等待后端，反之亦然。
- 关注点分离。后端开发人员只需要考虑API，而不需要考虑视图或CSS。前端开发人员只需要考虑后端提供的API，而不需要考虑Django的内部工作。您可以使用选项1来实现这一点，但此方法会更严格地执行它。
- 如果后端坏了，前端仍然可以工作。您的用户仍会遇到错误，但网站不会彻底没有响应。
- 安全权限可以拆分。您可以允许部署前端与后端的人员分开，这通常意味着更多的人将有部署权限，从而使您的团队更具生产力。
缺点是：
- 更多的基础设施。您将需要设置和维护静态站点，外加一个额外的部署过程，这将需要更多的工作，更复杂。
- 跨域困境。您遇到了更多问题，因为前端与后端位于不同的子域上。您需要对Django进行一些额外配置，以允许前端正确地与后端对话。显然这是安全问题。如果不解决这个问题，您可能会遇到向后端发出API请求、接收cookies等问题。我不太明白。我不想太明白。我有比找出SESSION_COOKIE_DOMAIN，CORS_ORIGIN_REGEX_WHITELIST和friends的正确值更重要的事情要做。更糟糕的是，跨域问题不会出现在您的本地计算机上，因为一切都是从本地主机提供的，所以您需要在知道配置是否正确之前部署配置。
以下是一些跨域Django设置，希望您永远不需要考虑：
- SESSION_COOKIE_DOMAIN
- CSRF_COOKIE_DOMAIN
- CSRF_TRUSTED_ORIGINS
- CORS_ORIGIN_ALLOW_ALL
- CORS_ALLOW_CREDENTIALS
- CORS_ORIGIN_REGEX_WHITELIST
适用于：
- 您有独立的前端和后端开发人员
- 要分别部署后端和前端
- 您希望完全分离后端和前端基础结构
- 您不介意再增加一点操作复杂性和配置
选项3-一台服务器，单独部署
这种方法试图融合方案1和2。我们的想法是仍然将前端部署为一个单独的静态站点，但是您可以将所有内容部署到一个服务器上，使用一个域名：
- 后端和前端分别有两个独立的代码库
- 两个代码库都是独立部署的，但是部署到同一个服务器上
- 两个代码库都托管在一个域上，如www.myapp.com
- 您可以使用一个web服务器来管理它，比如NGINX，它处理所有传入的请求。对URL path/api/get的请求被转发到运行Django应用程序（传统的反向代理设置）的WSGI服务器，而所有其他请求发送到前端，前端被设置为静态站点并限定访问的路径（例如/var/www/）。
优点是：
- 方案2的大部分好处。分离关注点和独立部署仍然是可行的。
- 没有“跨域困境”。因为所有的请求都是从一个域发出的，所以您不必在Django中处理那些可怕的跨域设置。
缺点是：
- 更多的基础设施。这个设置仍然比“将所有内容塞进Django”选项更复杂。
- 需要完全控制主机Web服务器。您需要能够安装和配置NGINX，将文件部署到文件系统等来完成这项工作。如果您使用的是典型的云虚拟机，这很简单，但如果您使用的是Heroku之类的东西，则可能会更加棘手（不确定）。
适用于：
- 你想把前端和后端分开，但你不需要完全分离基础设施
- 您对主机Web服务器有足够的控制权限
实际上，我从未尝试过选项3（我以前使用过1+2）。我是在回复Reddit的帖子时想到的。不过，我想它会起作用的。祝你好运！
英文原文：https://mattsegal.dev/django-spa-infrastructure.html
译者：阿布铥