魔天记忘语小说,完美世界,最好看的小说排行

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

React Server Components：我們即將和 API 告別？

2020 年底，React 公布了一個全新的特性：Server Components，當時它還處于調(diào)研和試驗階段，并沒有正式發(fā)布，隨著 React 18.0 版本的正式發(fā)布，Server Component 的腳步聲也越來越近了，不出意外的話，應(yīng)該會在今年的某個 React 18 的 minor 版本中正式發(fā)布。

Server Components 聽起來好像并不那么激動人心，React 18 所發(fā)布的各種特性也似乎平平無奇，自從 Hooks 面世已經(jīng)三年多過去了，React 似乎停滯了前進的腳步，只是在現(xiàn)有的基礎(chǔ)上做些小修小補?

No。

Concurrent rendering(React 18 新帶來的特性)是一種本質(zhì)上的改變，它本身不像 Hooks 那樣對開發(fā)體驗有著近乎翻天覆地的變革，但是這種底層渲染能力/機制的調(diào)整，會帶來非常非常多的可能性，例如：

Suspense、OffScreen、Server Components。

這三種特性，目前都沒有生產(chǎn)可用，但是等到未來他們正式發(fā)布并漸漸被大面積使用時，每一項特性都會帶來非常顯著的開發(fā)體驗的提升。而如果讓我從這些未來會出現(xiàn)的新特性中選一個最期待的，那毫不疑問會是 Server Component。

所以，Server Components 到底是什么?他會像當年的 Hooks 一樣對整個 React 生態(tài)帶來巨大的影響么?在我們回答這些問題之前，很有必要先解釋一下 Server Components 是什么，又解決了什么問題。

注：下文中的很多內(nèi)容受 Dan 和 Lauren 的這份演講視頻[1]所啟發(fā)，如果你想更深入的了解即將到來的 React Server Component，那么非常推薦這段視頻事實上，這篇文章并不是一份對 Server Components 的用法教學，也不會涵蓋 Server Components 的每一處細節(jié)(甚至為了方便表述會有意地略過一些細節(jié))，因此，在讀下文之前，最好是對 Server Components 已經(jīng)有所了解

背景：前后端分離

“前后端分離”是當下主流的 web 研發(fā)模式，后端存儲數(shù)據(jù)，并把對數(shù)據(jù)的操作(增刪改查)封裝成接口，通過后端服務(wù)提供給前端，前端應(yīng)用發(fā)送請求(例如 http 請求或者 rpc 請求)去調(diào)用后端提供的接口，從而獲取到數(shù)據(jù)或者是對數(shù)據(jù)進行修改。

這可能是十幾年以來非常普遍的研發(fā)模式了，也因此，我們被區(qū)分成前端開發(fā)和后端開發(fā)，各自負責著“楚河漢界”的一側(cè)。我們在各自那一側(cè)都做了非常多的優(yōu)化、創(chuàng)新、突破，在后端，我們有容器化、微服務(wù)、SSR，在前端，我們有 code spliting、前端路由、React Hooks。

但是對于 API 層，我們似乎這么多年以來都未曾有過關(guān)注，即便是有，也僅僅是停留于 API 傳輸性能(例如 grpc)、API 的存在形式(例如 Restful 和 GraphQL)、API 的工程化管理(例如 Postman)。

并非是想說 API 一個邪惡而糟糕的設(shè)計，但是自從 Restful 的概念被提出以來，已經(jīng) 22 年過去了，我們是不是應(yīng)該在現(xiàn)在重新思考一下：

以網(wǎng)絡(luò)請求作為前后端的分界是最優(yōu)解嗎?
如果沒有 API，我們該如何架構(gòu)和開發(fā) Web 應(yīng)用?

癥結(jié)所在

讓我們再回到剛剛的那張圖，考慮一下 API 在帶來職責分工明晰之外，同時也帶來了哪些問題。

請求瀑布流(Waterfall)

就像 Remix[2] 首頁上所展示的，基于 API 和嵌套路由的前端站點，在請求時會出現(xiàn)瀑布流的現(xiàn)象：

數(shù)據(jù)的之間可能是有前后的依賴關(guān)系，抑或是和組件強耦合在一起，需要等待組件的 bundle 加載完成之后才能發(fā)出請求，這些都導致了請求瀑布流現(xiàn)象的出現(xiàn)。

并發(fā)請求

后端希望實現(xiàn)小而美的接口，每個接口有獨立的職責，例如：

getUser 獲取用戶信息。
getSongs?page=12 獲取歌曲列表。
getNotifactions 獲取通知列表。
getFavoirateSongs 獲取收藏的歌曲。
getNewSongs 獲取新發(fā)布的歌曲。
getRecommendSong 獲取今日推薦的歌曲及對應(yīng)的文案。
getSearchBarHotKeywords 獲取熱門的搜索詞。
getAdBanner 獲取廣告 banner 內(nèi)容。
getRecentSongs 獲取最近聽歌記錄。
getRecommendedPlayList 獲取推薦的歌單列表。
……(實在太多了)。

每一個接口，單獨拿出來看都是合理的，但是放在一起，就會發(fā)現(xiàn)用戶每次打開這樣一個音樂 web app，都要發(fā)送至少十幾個接口，對于一些稍微復(fù)雜一點的網(wǎng)頁，首次加載就需要請求幾十個接口也絲毫不奇怪。

每一個接口的請求，都會帶來網(wǎng)絡(luò)開銷，甚至在有些環(huán)境下會有最大并發(fā)請求數(shù)量的限制(例如在支付寶客戶端那的 rpc 請求)，或許網(wǎng)絡(luò)層的 automatic batching 可以解決這個問題，但是遺憾的是，在目前的技術(shù)體系內(nèi)，這個問題并不好解決(這里沒有寫不能解決，是因為的確有一些可行的方案，例如 BFF、依賴網(wǎng)關(guān)來做接口聚合，但它們都引入的新的問題)。

前端包體積(Bundle size)

包體積已經(jīng)是“現(xiàn)代”前端開發(fā)領(lǐng)域飽受詬病的一點了，動輒幾百 k 的 js 文件，似乎已經(jīng)背離了瀏覽器是用來“瀏覽”網(wǎng)頁的初衷了。并不是說我們都要做一個瀏覽器原教旨主義者，但是如果網(wǎng)頁能夠在不損失用戶體驗和開發(fā)體驗的前提下，恢復(fù)到非常輕量和快速的狀態(tài)，難道不是一件好事么?

協(xié)作成本(溝通、邏輯感知和封閉)

在我個人看來，這是大型項目或需要長期維護的應(yīng)用中最令人頭疼的問題了。

假設(shè)我們現(xiàn)在有一個非常巨大的應(yīng)用，需要有十幾位開發(fā)者共同編寫和維護，那如何分工?答案必然是先做模塊化，我們把整個應(yīng)用拆分成幾個彼此盡量獨立的模塊，再由每個人或每幾個人負責其中的一個模塊。模塊化帶來的好處是邊界清晰(看到一個需求就能判斷出來涉及到哪個或哪些模塊做哪些改動)、職責明確(每個人都有自己確定的職責)、減少溝通成本(由于模塊內(nèi)部的邏輯是封閉的，不需要外部感知，所以可以降低溝通成本)。

對于前兩點，目前的前后端分離架構(gòu)都還是及格的，但對于第三點，我覺得基于網(wǎng)絡(luò)請求接口的協(xié)作模式，在很多情況下并沒有有效地做到邏輯內(nèi)部封閉、減少需要前后端之間來回溝通的信息量。

舉個例子，對于這樣的一個頁面：

看起來非常簡單，一些信息的展示，加上一個充值按鈕，這就是我最開始所設(shè)想的。

然而，隨著這個項目不斷的推進，我發(fā)現(xiàn)，原本以為是純靜態(tài)的標題文案，實際上是需要后端控制的，根據(jù)當前用戶的所屬人群來動態(tài)判斷文案內(nèi)容;我發(fā)現(xiàn)，由于前端金額計算的可靠性問題，折扣和實際支付相關(guān)的內(nèi)容都是需要在后端預(yù)處理之后展示在前端的;我發(fā)現(xiàn)，倒計時的參考時間是需要依靠后端返回的;我發(fā)現(xiàn)，按鈕的文案、點擊行為，是需要后端控制的，特別是按鈕的點擊行為，最終方案是后端返回一個枚舉，前端根據(jù)這個值來 switch case 一下走不同的邏輯(例如下單、引導先進行注冊和綁卡)……

為了閱讀體驗，我只是列舉了其中隨手想到的一小部分，如果總結(jié)一下，那就是，后端和前端并沒有因為“前后端分離”而做到解藕，反倒是藕斷絲連，剪不斷理還亂。后端感知了過多的前端視圖層邏輯，就像是發(fā)明了一套 DSL(Domain Specific Language)，而前端則是要寫一個針對這套 DSL 的解析器和渲染器。

回到我們剛剛提到的，模塊化帶來的好處。模塊化能夠降低溝通成本，有一個不可忽略前提，就是架構(gòu)的合理性。模塊化并非是降低溝通成本的本質(zhì)原因，也并非所有的模塊化實踐都能帶來溝通成本的降低。當前后端分離的實踐成為一個僵硬的、死板的“規(guī)范”，那它還能真正起到多少降低溝通成本的作用?一個大大的問號。

Server Components

再次申明一下，下文是假設(shè)讀者朋友已經(jīng)對 Server Components[3] 有所了解。

基于網(wǎng)絡(luò)請求的 API 模型，有一個大大的前提假設(shè)，就是前端應(yīng)用和后端應(yīng)用是兩個獨立的應(yīng)用，但是為什么一定要是這樣?

或許我們可以讓后端應(yīng)用直接渲染 HTML，用戶操作時，重新渲染一遍頁面?這其實就是在 Restful 時代之前的架構(gòu)，有很多弊端，特別是可交互性差，不然也就不會出現(xiàn)后來 Restful 的盛行了。

那再或許，我們可以讓前端的 React 組件，運行在后端?

這就是 React Server Components。

一圖勝千言，在現(xiàn)在的前后端分離模式下，后端提供接口，前端的 React 組件調(diào)用接口。

而如果后端可以運行 React 組件，直接渲染 React 節(jié)點樹到前端，就不需要所謂的 API 的概念了。

后端運行 React 組件并不是什么新鮮事，我們在 SSR(Server Side Rending)早就習以為常了，但是需要特別注明的一點是，在 SSR 中，后端是運行了 React 組件，生成了一份初始狀態(tài)的 html，但這份 html 是沒有可交互性的，它只是為了讓用戶能盡早看到頁面而做的一種改良式的、修修補補一樣的優(yōu)化。

而 Server Components 所帶來的，是我們可以把同一個項目中，一部分的組件作為 Server Components，另一部分組件，作為 Client Components，因此我們可以既享受到后端內(nèi)部調(diào)用帶來的便捷、可維護性，又能保證頁面的可交互性幾乎沒有任何妥協(xié)。

如果你用過 PHP 或 Django，那你肯定非常熟悉這種模式：后端直接渲染 html 內(nèi)容，瀏覽器只負責顯示，用戶點擊按鈕，那就重新請求、重新渲染頁面，如果頁面上需要一些復(fù)雜的動態(tài)交互，比如讓用戶可以把一個列表展開/收起，或者是點擊某個按鈕之后展示一個模態(tài)框，那可以借助于 jQuery 來實現(xiàn)。

PHP + bootstrap + jQuery，現(xiàn)在，Server Components 就像是這套范式的升級版，可以被稱為一種全新的“全?！遍_發(fā)模式。

因為是在后端環(huán)境下，這些 Server Components 可以使用全部的后端能力，不管是中間件，還是其他后端微服務(wù)的調(diào)用，甚至是 db 的訪問(當然可以直接跑 SQL，但是更好的實踐是通過一個數(shù)據(jù)中間層)，都可以實現(xiàn)。這樣一來，我們就可以直接把數(shù)據(jù)從源頭獲取，放到 React 組件的上下文中，那自然就不需要傳統(tǒng)意義上的 API 了。

更準確的說，API 并未消失，我們其實也不會和 API 就此說再見，而是讓它換了一種形式。有模塊化的地方，就會有 API，Restful 的 http 網(wǎng)絡(luò)請求固然是 API，但中間件暴露出來的方法，瀏覽器提供的 Date 對象，node 提供的文件讀取函數(shù)，db 提供的 SQL，這些全都是 API。在這種新架構(gòu)下，API 變成了后端里業(yè)務(wù)應(yīng)用和上游服務(wù)之間的調(diào)用，變成了 Server Components 和 Client Components 之間的 props 傳遞，前者讓 API 變得更加干凈、更符合單一職責的原則，而后者讓 API 變得自然到你幾乎感知不到。

所以：

Server Components 允許我們不再按照前端 - 后端進行模塊的拆分，而是依照業(yè)務(wù)應(yīng)用 - 底層服務(wù) 來進行更合理的模塊拆分。從而可以理論上降低模塊之間的溝通成本(因為目前還沒有辦法實踐證明)。
由于 Server Components 是在后端運行組件，直接通過網(wǎng)絡(luò)傳輸給前端進行渲染，因此很多大體積的包(例如 markdown 渲染、html sanitize)都不需要在前端下載和運行，從而很大程度上降低包體積。
由于底層 db 或上游服務(wù)的調(diào)用都是發(fā)生在后端內(nèi)部的，因此即便出現(xiàn)并發(fā)請求，所帶來開銷也遠遠小于前端并發(fā)調(diào)用后端的 Restful API。
同理，請求瀑布流的問題也會因為調(diào)用開銷降低而消失或減輕。

想象

如果大膽想象一下的話，未來的研發(fā)模式可能這樣的：

開發(fā)者將不會再區(qū)分前端和后端，而是區(qū)分為業(yè)務(wù)應(yīng)用開發(fā)和上游服務(wù)開發(fā)?，F(xiàn)在的后端開發(fā)將(真正地)不再需要關(guān)注視圖邏輯，只聚焦于底層業(yè)務(wù)邏輯，為前端提供清晰好用、原子化的服務(wù)/接口;而現(xiàn)在的前端開發(fā)將會拓展到橫跨前端和后端(代碼運行環(huán)境上)，負責的是在后端封裝好的一個個原子化的底層能力上，構(gòu)建視圖層，而我們也需要一套全新的框架和基礎(chǔ)設(shè)施，來適配 Server Components。

目前，Server Components 還沒有正式發(fā)布，而即便正式發(fā)布之后，也還有長長的工程化落地的路要走，Server Components 增加了很多額外的限制，server、client、shared 的區(qū)分也可能會帶來一些理解成本。緩存、性能、server 重新渲染時的增量更新策略、發(fā)布時的可灰度性和可回滾性、業(yè)務(wù)中邊界情況的處理，還有很多的問題需要去解決，還有很多的未知尚未被驗證。

參考資料

[1]演講視頻: https://www.youtube.com/watch?v=TQQPAU21ZUw。

[2]Remix: https://remix.run。

[3]Server Components: https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html。

文章題目：React Server Components：我們即將和 API 告別？
URL標題：http://www.fisionsoft.com.cn/article/dhojjoh.html