在過去的幾十年里，我們見證了應用架構以快速的速度演變。當我還是一個年輕的程序員時，開始編寫一個簡單的代碼庫，我們可以稱之為單體應用。
我記得為前端編寫了一些html/css，后端用了一些JAVA。但后來，隨著時代發展和需求改變，分布式架構（我們現在稱之為“微服務”）應運而生。
單體應用的衰落
這暫且不談單體應用如何變得越來越不受歡迎，但需要開發者開始鼓吹微服務卻是事實。
通常，微服務提供了以下好處：
微服務更小，更容易維護。
減少了團隊之間的摩擦。每個團隊可以獨立地處理每個微服務。
編寫速度更快（不需要遵循現有且有時繁瑣的架構）。
團隊使用最適合任務的工具（例如，處理大量JSON數據？也許可以使用Node.js。需要高性能？也許可以考慮Rust。只有Ruby開發者？那么Ruby似乎是解決方案）。
減少認知負荷，這意味著每個開發者只需要了解代碼的一個子集，而不是整個代碼庫。
關于微服務的誤解
然而，經常或者有時，過度使用微服務也存在一些缺點：
代碼重復：一些代碼（數據或函數）在多個倉庫之間重復出現，這會導致共享庫與單一倉庫的分歧和爭論。
事務處理復雜：處理多個微服務之間的事務具有一定的挑戰性，并需要額外的模式（Saga、事件溯源等）。
增加認知負荷：取決于上下文的不同，可能會極大地增加認知負荷。每個開發人員不僅需要知道微服務能夠做什么/應該做什么，還需要知道它可以/應該與哪些其他微服務進行通信。
易受故障影響：在幾乎所有的場景中，都更容易受到故障的影響：數據庫連接、網絡延遲、緩存、異常等。
但是，任何明智的開發者都會告訴你，對于任何架構選擇，答案總是“看具體情況”。
單體與微服務的平衡
單體與微服務之爭中，一個設計良好的、高度解耦的架構只需要處理最多四個不同的部分：
UI，也稱為前端（front-end）
BFF，即面向前端的后臺（Backend For Frontend），或者說是單一前端的后端（Backend for a Single Frontend, BSF）
傳統后端，充當前端和數據之間的粘合劑。稱之為 BFD (Backend For Database) 或多BSF的后端。
數據庫，也稱為數據庫及其查詢機制。
完全解耦的微服務架構的表示
從熟悉的模式中，我們已經擁有合適的技術棧：
前端框架（Angular、React、Vue、Svelte 等）
使用適當技術的 BFF（簡單的 REST API？node.js 中的 GraphQL 服務器？）
一個傳統的后端（暫且稱之為BFD），再次使用適當的技術（另一個REST API？一個高性能的gRPC服務器？）
最后是所需的最小數據庫數量（關系數據庫和/或文檔數據庫和/或圖數據庫和/或搜索引擎）
如果我們重視簡單性，還有改進的空間。我們還應該商定需要技術棧的每個部分的比例：
至少一個前端，但你可以無限擴展這個數字，無論是在編寫微型前端、大量的 web 應用程序，還是兩者兼而有之
一個前端 = 一個 BFF，如果我們遵循邏輯
一個傳統的后端，你可以根據需要將其拆分成 N 個微服務。但是，如果我們使用單體架構，那就說 1 個吧。
每個類型的數據庫至少一個。假設我們需要 3 種類型的數據庫來滿足中等規模的應用程序。
img
N = (2 * UI) + (1 * BFD) + (3 * DB)
正如俗話所說，“少即是多”，因此我們的目標是嘗試將這個數字 (N) 減少到絕對最低。
進入Serverless單體架構時代
前端元框架的興起
過去我們見證了一個令人難以置信的演變，那就是誕生了眾多前端元框架。其中最著名的有 Next.js、Remix 和 SvelteKit。
一個元框架的目標是同時處理前端的前端和后端（是的，當你這樣說的時候，這聽起來并不聰明）。換句話說，這意味著使用單一技術構建 UI + BFF。
而且，由于如今的云和托管解決方案，我們可以輕松以無服務器模式部署元框架。
BFD和元框架單體架構
N = META-FRAMEWORK + (1 * BFD) + (3 * DB)
從這里開始，我們為每個前端減少了 1 個技術！
Serverless數據庫時代
目前，圍繞數據庫作為服務（DaaS）的解決方案或者說后端作為服務（BaaS）正在興起。BaaS的目標是提供應用程序所需的所有功能，以便你無需在后端編寫一行代碼。你只需要在你的BFF中編寫查詢，就完成了。
最著名的BaaS無疑是Firebase，它提供了許多功能，如實時文檔數據庫、身份驗證服務、數據庫之上的權限機制、文件系統存儲等等。
然而，Firebase也有一些嚴重的限制：
Firebase 數據庫，無論是 Realtime 數據庫還是 Firestore，都是單模型數據庫（文檔數據庫）。
它只能作為一個單向圖進行遍歷（如果我們可以將其視為圖的話）。
還有另一個叫做Supabase的著名BaaS，試圖與Firebase相媲美。使用類似PostgreSQL的關系型數據庫消除了Firebase的一些限制，但它仍然是單模型數據庫...
最近引起我注意的一個項目是SurrealDB。它是一個帶有內置后端的數據庫，具有許多許多功能（我覺得“許多”這個詞寫得還不夠）。作為一個真正的多模型數據庫，并且有一種新的查詢語言，他們能夠提供應該讓你寫一些代碼的功能。
最近，這種類型的數據庫被越來越廣泛地稱為元數據庫。
完全單體架構
N = META-FRAMEWORK + META-DATABASE
從那里開始，我們在另一個層面上大大減少了技術數量。
附加內容：利用單一倉庫架構
與微服務一樣，編寫單體應用意味著擁有正確的工具箱。這個工具箱可以解決我們通常遇到的約束，比如：
太龐大以至于無法失敗，一個簡單的錯誤可能會導致整個服務崩潰。
長時間部署，編譯大型項目通常需要很長時間。
無法跨團隊隔離和共享的單一代碼庫。
使用這種架構，對純凈和全面的單體架構（前端 + 后端）的需求就不再存在。然而，元框架是超過 80% 的代碼將駐留的部分。為此，現在有一些工具可以使用，例如 turborepo。
我們還沒有提到的一個不可避免的需求是數據庫腳本遷移。當然，這些腳本需要存儲在單獨的倉庫中，沒有什么復雜的。
