React：我們即將和后端 API 告別？
2020 年底，React 公布了一個全新的特性：Server Components，當時它還處于調研和試驗階段，并沒有正式發布，隨著 React 18.0 版本的正式發布，Server Component 的腳步聲也越來越近了，不出意外的話，應該會在今年的某個 React 18 的 minor 版本中正式發布。
Server Components 聽起來好像并不那么激動人心，React 18 所發布的各種特性也似乎平平無奇，自從 Hooks 面世已經三年多過去了，React 似乎停滯了前進的腳步，只是在現有的基礎上做些小修小補？
No。
Concurrent rendering（React 18 新帶來的特性）是一種本質上的改變，它本身不像 Hooks 那樣對開發體驗有著近乎翻天覆地的變革，但是這種底層渲染能力/機制的調整，會帶來非常非常多的可能性，例如：Suspense、OffScreen、Server Components
這三種特性，目前都沒有生產可用，但是等到未來他們正式發布并漸漸被大面積使用時，每一項特性都會帶來非常顯著的開發體驗的提升。而如果讓我從這些未來會出現的新特性中選一個最期待的，那毫不疑問會是 Server Component。
所以，Server Components 到底是什么？他會像當年的 Hooks 一樣對整個 React 生態帶來巨大的影響么？在我們回答這些問題之前，很有必要先解釋一下 Server Components 是什么，又解決了什么問題。
注：下文中的很多內容受 Dan 和 Lauren 的這份 演講視頻 [1] 所啟發，如果你想更深入的了解即將到來的 React Server Component，那么非常推薦這段視頻 事實上，這篇文章并不是一份對 Server Components 的用法教學，也不會涵蓋 Server Components 的每一處細節（甚至為了方便表述會有意地略過一些細節），因此， 在讀下文之前，最好是對 Server Components 已經有所了解
背景：前后端分離
“前后端分離”是當下主流的 web 研發模式，后端存儲數據，并把對數據的操作（增刪改查）封裝成接口，通過后端服務提供給前端，前端應用發送請求（例如 http 請求或者 rpc 請求）去調用后端提供的接口，從而獲取到數據或者是對數據進行修改。
這可能是十幾年以來非常普遍的研發模式了，也因此，我們被區分成前端開發和后端開發，各自負責著“楚河漢界”的一側。我們在各自那一側都做了非常多的優化、創新、突破，在后端，我們有容器化、微服務、SSR，在前端，我們有 code spliting、前端路由、React Hooks。
但是對于 API 層，我們似乎這么多年以來都未曾有過關注，即便是有，也僅僅是停留于 API 傳輸性能（例如 grpc）、API 的存在形式（例如 Restful 和 GraphQL）、API 的工程化管理（例如 Postman）。
并非是想說 API 一個邪惡而糟糕的設計，但是自從 Restful 的概念被提出以來，已經 22 年過去了，我們是不是應該在現在重新思考一下：
以網絡請求作為前后端的分界是最優解嗎？
如果沒有 API，我們該如何架構和開發 Web 應用？
癥結所在
讓我們再回到剛剛的那張圖，考慮一下 API 在帶來職責分工明晰之外，同時也帶來了哪些問題。
請求瀑布流（Waterfall）
就像 Remix [2] 首頁上所展示的，基于 API 和嵌套路由的前端站點，在請求時會出現瀑布流的現象：
數據的之間可能是有前后的依賴關系，抑或是和組件強耦合在一起，需要等待組件的 bundle 加載完成之后才能發出請求，這些都導致了請求瀑布流現象的出現。
并發請求
后端希望實現小而美的接口，每個接口有獨立的職責，例如：
- getUser 獲取用戶信息
- getSongs?page=12 獲取歌曲列表
- getNotifactions 獲取通知列表
- getFavoirateSongs 獲取收藏的歌曲
- getNewSongs 獲取新發布的歌曲
- getRecommendSong 獲取今日推薦的歌曲及對應的文案
- getSearchBarHotKeywords 獲取熱門的搜索詞
- getAdBanner 獲取廣告 banner 內容
- getRecentSongs 獲取最近聽歌記錄
- getRecommendedPlayList 獲取推薦的歌單列表
- ……（實在太多了）
每一個接口，單獨拿出來看都是合理的，但是放在一起，就會發現用戶每次打開這樣一個音樂 web app，都要發送至少十幾個接口，對于一些稍微復雜一點的網頁，首次加載就需要請求幾十個接口也絲毫不奇怪。
每一個接口的請求，都會帶來網絡開銷，甚至在有些環境下會有最大并發請求數量的限制（例如在支付寶客戶端那的 rpc 請求），或許網絡層的 automatic batching 可以解決這個問題，但是遺憾的是，在目前的技術體系內，這個問題并不好解決（這里沒有寫不能解決，是因為的確有一些可行的方案，例如 BFF、依賴網關來做接口聚合，但它們都引入的新的問題）。
前端包體積（Bundle size）
包體積已經是“現代”前端開發領域飽受詬病的一點了，動輒幾百 k 的 js 文件，似乎已經背離了瀏覽器是用來“瀏覽”網頁的初衷了。并不是說我們都要做一個瀏覽器原教旨主義者，但是如果網頁能夠在不損失用戶體驗和開發體驗的前提下，恢復到非常輕量和快速的狀態，難道不是一件好事么？
協作成本（溝通、邏輯感知和封閉）
在我個人看來，這是大型項目或需要長期維護的應用中最令人頭疼的問題了。
假設我們現在有一個非常巨大的應用，需要有十幾位開發者共同編寫和維護，那如何分工？答案必然是先做模塊化，我們把整個應用拆分成幾個彼此盡量獨立的模塊，再由每個人或每幾個人負責其中的一個模塊。
模塊化帶來的好處是邊界清晰（看到一個需求就能判斷出來涉及到哪個或哪些模塊做哪些改動）、職責明確（每個人都有自己確定的職責）、減少溝通成本（由于模塊內部的邏輯是封閉的，不需要外部感知，所以可以降低溝通成本）。
對于前兩點，目前的前后端分離架構都還是及格的，但對于第三點，我覺得基于網絡請求接口的協作模式，在很多情況下并沒有有效地做到邏輯內部封閉、減少需要前后端之間來回溝通的信息量。
舉個例子，對于這樣的一個頁面：
看起來非常簡單，一些信息的展示，加上一個充值按鈕，這就是我最開始所設想的。
然而，隨著這個項目不斷的推進，我發現，原本以為是純靜態的標題文案，實際上是需要后端控制的，根據當前用戶的所屬人群來動態判斷文案內容；我發現，由于前端金額計算的可靠性問題，折扣和實際支付相關的內容都是需要在后端預處理之后展示在前端的；
我發現，倒計時的參考時間是需要依靠后端返回的；我發現，按鈕的文案、點擊行為，是需要后端控制的，特別是按鈕的點擊行為，最終方案是后端返回一個枚舉，前端根據這個值來 switch case 一下走不同的邏輯（例如下單、引導先進行注冊和綁卡）……
為了閱讀體驗，我只是列舉了其中隨手想到的一小部分，如果總結一下，那就是，后端和前端并沒有因為“前后端分離”而做到解藕，反倒是藕斷絲連，剪不斷理還亂。后端感知了過多的前端視圖層邏輯，就像是發明了一套 DSL（Domain Specific Language），而前端則是要寫一個針對這套 DSL 的解析器和渲染器。
回到我們剛剛提到的，模塊化帶來的好處。模塊化能夠降低溝通成本，有一個不可忽略前提，就是架構的合理性。模塊化并非是降低溝通成本的本質原因，也并非所有的模塊化實踐都能帶來溝通成本的降低。當前后端分離的實踐成為一個僵硬的、死板的“規范”，那它還能真正起到多少降低溝通成本的作用？一個大大的問號。
Server Components
再次申明一下，下文是假設讀者朋友已經對 Server Components [3] 有所了解
基于網絡請求的 API 模型，有一個大大的前提假設，就是前端應用和后端應用是兩個獨立的應用，但是為什么一定要是這樣？
或許我們可以讓后端應用直接渲染 HTML，用戶操作時，重新渲染一遍頁面？這其實就是在 Restful 時代之前的架構，有很多弊端，特別是可交互性差，不然也就不會出現后來 Restful 的盛行了。
那再或許，我們可以讓前端的 React 組件，運行在后端？
這就是 React Server Components。
一圖勝千言，在現在的前后端分離模式下，后端提供接口，前端的 React 組件調用接口。
而如果后端可以運行 React 組件，直接渲染 React 節點樹到前端，就不需要所謂的 API 的概念了。
后端運行 React 組件并不是什么新鮮事，我們在 SSR（Server Side Rending）早就習以為常了，但是需要特別注明的一點是，在 SSR 中，后端是運行了 React 組件，生成了一份初始狀態的 html，但這份 html 是沒有可交互性的，它只是為了讓用戶能盡早看到頁面而做的一種改良式的、修修補補一樣的優化。
而 Server Components 所帶來的，是我們可以把同一個項目中，一部分的組件作為 Server Components，另一部分組件，作為 Client Components，因此我們可以既享受到后端內部調用帶來的便捷、可維護性，又能保證頁面的可交互性幾乎沒有任何妥協。
如果你用過 PHP 或 Django，那你肯定非常熟悉這種模式：后端直接渲染 html 內容，瀏覽器只負責顯示，用戶點擊按鈕，那就重新請求、重新渲染頁面，如果頁面上需要一些復雜的動態交互，比如讓用戶可以把一個列表展開/收起，或者是點擊某個按鈕之后展示一個模態框，那可以借助于 jQuery 來實現。
PHP + bootstrap + jQuery，現在，Server Components 就像是這套范式的升級版，可以被稱為一種全新的“全棧”開發模式。
因為是在后端環境下，這些 Server Components 可以使用全部的后端能力，不管是中間件，還是其他后端微服務的調用，甚至是 db 的訪問（當然可以直接跑 SQL，但是更好的實踐是通過一個數據中間層），都可以實現。這樣一來，我們就可以直接把數據從源頭獲取，放到 React 組件的上下文中，那自然就不需要傳統意義上的 API 了。
更準確的說，API 并未消失，我們其實也不會和 API 就此說再見，而是讓它換了一種形式。有模塊化的地方，就會有 API，Restful 的 http 網絡請求固然是 API，但中間件暴露出來的方法，瀏覽器提供的 Date 對象，node 提供的文件讀取函數，db 提供的 SQL，這些全都是 API。
在這種新架構下，API 變成了后端里業務應用和上游服務之間的調用，變成了 Server Components 和 Client Components 之間的 props 傳遞，前者讓 API 變得更加干凈、更符合單一職責的原則，而后者讓 API 變得自然到你幾乎感知不到。
所以：
- Server Components 允許我們不再按照 前端 - 后端 進行模塊的拆分，而是依照 業務應用 - 底層服務 來進行更合理的模塊拆分。從而可以理論上降低模塊之間的溝通成本（因為目前還沒有辦法實踐證明）。
- 由于 Server Components 是在后端運行組件，直接通過網絡傳輸給前端進行渲染，因此很多大體積的包（例如 markdown 渲染、html sanitize）都不需要在前端下載和運行，從而很大程度上降低包體積。
- 由于底層 db 或上游服務的調用都是發生在后端內部的，因此即便出現并發請求，所帶來開銷也遠遠小于前端并發調用后端的 Restful API。
- 同理，請求瀑布流的問題也會因為調用開銷降低而消失或減輕。
想象
如果大膽想象一下的話，未來的研發模式可能這樣的：
開發者將不會再區分前端和后端，而是區分為業務應用開發和上游服務開發。現在的后端開發將（真正地）不再需要關注視圖邏輯，只聚焦于底層業務邏輯，為前端提供清晰好用、原子化的服務/接口；而現在的前端開發將會拓展到橫跨前端和后端（代碼運行環境上），負責的是在后端封裝好的一個個原子化的底層能力上，構建視圖層，而我們也需要一套全新的框架和基礎設施，來適配 Server Components。
目前，Server Components 還沒有正式發布，而即便正式發布之后，也還有長長的工程化落地的路要走，Server Components 增加了很多額外的限制，server、client、shared 的區分也可能會帶來一些理解成本。緩存、性能、server 重新渲染時的增量更新策略、發布時的可灰度性和可回滾性、業務中邊界情況的處理，還有很多的問題需要去解決，還有很多的未知尚未被驗證。
