考慮到運行成本，我應該將 UI 和后端分開還是結合起來

Question

我正在開發我的第一個 SaaS 應用程序，它將托管在 Google Cloud 或任何其他類似的雲中。 讓我們了解一下項目的性質：它是一個有點簡單的 SaaS，基於多租戶，客戶創建一個帳戶並獲取一個系統來使用。 最初，計算量很低，沒有主要的數據處理。 客戶可以保存提醒、創建某些分層列表、管理其內部數據的某些方面等。該服務將從免費層開始，非常有限（或試用），然后最終我將啟動付費訂閱層。 要弄清楚所有這些細節還有很長的路要走。 盡管如此，我確實需要在非常合理的性能范圍內盡可能地保持這種設計的成本效益。 我沒有任何具體的使用估計，但可能會從 50-100 個客戶開始，並可能增長到數萬個。

所以最初，我將有兩個組件：Web UI（React）和 REST 后端（Spring + MySQL）。 我可以用兩種不同的方式設計它：

A. As separate micro services: -Spring based REST API backend + MySQL (two containers) - Nodejs Express + React Web UI front-end (separate service) - Total of three containers running

或者

B. Spring REST API backend + React Web UI front-end in one service + MySQL - Total of two containers running

我的想法……從設計和擴展的角度來看，我個人更喜歡 A。通過這種情況，我得到了服務的清晰分離和真正面向微服務的架構。 我可以相應地擴展每項服務。 缺點是有點復雜，有點響應時間下降和可能更高的運行成本。

使用 BI 顯然可以獲得更簡單的系統，很可能會減少維護並降低成本。

我正在尋找的是有經驗的人對此的一些想法。 對於上述情況，我應該考慮什么最重要，哪個似乎是更好的選擇？

Answer 1

根據我的經驗，從長遠來看，我更喜歡 A 的可擴展性，因此您的后端開發人員不必處理前端問題。 我工作過的每個系統都沒有在 UI 和后端之間進行清晰的分離，最終成為部署和構建的噩夢。

我會使用 B 進行原型設計，同時盡量保持 UI 和后端分離，這樣一旦你有足夠的收入 stream 來支持它，你就可以切換到 A。

Answer 2

引用 Michael Washburn Jr 的文章：

1. 模塊化 將您的應用程序拆分為單獨的后端和前端應用程序的一個好處是模塊化。 由於您的應用程序邏輯與您的用戶界面完全分離，您將擁有一個更加模塊化的 web 應用程序。 模塊化有助於許多事情，包括測試、可讀性和可維護性。

2. 可重用性 通過單獨的 API，您的應用程序邏輯可以被任意數量的應用程序重用。 這意味着您可以制作一個使用 API 的移動應用程序，在一個完全獨立的應用程序中使用您的 API，甚至允許其他人訪問您的 API（免費或收費）。

3. 內容交付 由於您的客戶端應用程序是一個完全獨立的實體，您可以處理高級 static 文件服務技術，這些技術在需要在服務器端呈現 UI 的應用程序中是不可用的。 例如，您現在可以使用 NGINX 和一些簡單的規則來緩存整個客戶端應用程序。

4. 響應性 “一體式”服務器端應用程序的最大缺陷之一是為用戶提供響應式反饋。 用戶單擊按鈕以獲取數據的典型工作流程在服務器端應用程序中如下所示：

用戶單擊按鈕獲取數據 瀏覽器向服務器發送請求 服務器查詢數據庫 應用程序對數據執行邏輯 應用程序在視圖中呈現數據 服務器將響應返回給用戶 用戶在等待后看到反饋頁面加載的整個時間。 使用單獨的客戶端應用程序，您可以利用許多反饋機制，例如使用加載微調器或進度條。 一旦您的請求返回（例如，通過 AJAX 調用），您就可以更新您的視圖。

編輯 1

5. 版本控制 是的，我添加了 #5。 通過單獨的 API 和 UI 項目，您可以升級和部署一個而無需另一個。 如果您的新 UI 部署中存在嚴重問題，您可以回滾它而不犧牲您剛剛在 API 項目中所做的性能改進。

編輯 2

單體架構的優勢是什么？ 這種分體式架構有許多出色的好處。 然而，使用單體架構也有一些好處。 例如，如果您的應用程序包含在單個項目中，您可以更快地開發它。 制作單獨的用戶界面和 API 需要更多的編碼，這已經不是什么秘密了（但許多框架使這變得更容易）。 您還可以獲得開箱即用的安全優勢。 例如，您根本沒有公開 API 的事實。 有多種方法可以保護您的 API，但不必這樣做會更好。 如果你有更多的優勢你想談談留下評論，讓我們談談。

參考： https://michaelwashburnjr.com/blog/4-reasons-web-app-separated-frontend-backend