如果您要用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譯者：阿布銩
