mvc - 服務端渲染全域所需資料, 客戶端用 React 呈現, 這樣一套方案可行嗎?

Question

用了React 以後, 從數據渲染View 流程就相對輕鬆了, 但是更實用應用需要是有服務端支持, 多用戶, 實時同步, 這些等等, 我在已有的實踐當中遇到一些問題(我不是很熟悉後端的架構, 所以從前端角度看): 瀏覽器端緩...

滿天的星座 · Answer

我這個應該不算答案，就當是一起探討一下吧。你描述的一些東西我覺得看不明白，我先來問問好保證我們在同一條線上：

瀏覽器端快取資料時, 有時會遇到外部的資料只能從伺服器抓, 而伺服器並不總是知道瀏覽器端需要什麼資料

等一下，從伺服器上抓資料的時候，不是要聲明請求類型的嗎？為什麼伺服器需要「知道」瀏覽器需要什麼資料？我的意思是，假設你快取的資料缺少（比方說）“作者資訊”，那應該 GET /author/:id 對嗎？這樣怎麼會變成伺服器「不總是知道」瀏覽器需要什麼資料？能否舉個例子說清楚你的意思？

瀏覽器有一份資料備份, 就需要手動維護, 保持跟伺服器更新等等、而類似操作在伺服器推送資料時也會做, 這樣兩邊就有重複程式碼

我覺得「推」表示：瀏覽器其實不知道資料有更新，伺服器知道，所以伺服器推給瀏覽器更新後的資料。而你在瀏覽器手動維護的資料則表示：你知道資料變更了，所以才要手動維護，並且要提交給伺服器以同步資料。

你不覺得這兩者剛好是一條線的兩端，其實不矛盾嗎？為什麼會有重複程式碼？你指的是用來同步資料的程式碼？

所以你所思考的方案：

瀏覽器端進行資料的操作, 全部靠伺服器推送的資料進行更改
意思是客戶端不做資料快取？只要有資料變更操作就從伺服器即時取得完整的資料（或者說，一個使用者做了操作就立刻把資料更新推給其他所有的客戶端）？

……哪個表格的哪個資料
若我沒理解錯，你的意思是假設我是用戶 A，我正在看 /author/5 的資料，伺服器上應該有一個遊標機制註明：“用戶 A 正在瀏覽 authors 表 id 為 5 的數據”，是嗎？換句話說，每當 URL 改變的時候就應該發送給伺服器“我目前的位置”，然後伺服器就把相應的資料推送給我，是這個意思？

那…這和我直接 GET /author/5 拿到資料有多大的差別？

你描述的東西，我看得出來有你自己的想法，但是我覺得場景還是太模糊了。更想聽聽具體的東西，以具體場景為例到底解決了哪些問題？

淡淡烟草味 · Answer

而伺服器並不總是知道瀏覽器端需要什麼資料

伺服器和瀏覽器端的溝通需要依據規範，backend和fontend的溝通在應用程式開發中，本身就很重要

瀏覽器有一份資料備份, 就需要手動維護, 保持跟伺服器更新等等

其實業務資料最後都是要保存到伺服器上，資料庫（mysql等）提供這類服務。而資料在伺服器和客戶端之間交互，準備的講，瀏覽器的資料可以叫做快取。快取範圍很廣，last_modified和etag也是快取之一，還有伺服器應用程式內部的快取

至於重複程式碼，其實很可能由於backend和fontend的分工不明確導致的，技術架構。不過有時候專案為了快速啟動，是允許重複程式碼的。後期可以慢慢重構。前期只能根據目前的技術水平選擇，而不應該陷入技術太深，導致專案無法按期完成

瀏覽器端進行資料的操作, 全部靠伺服器推送的資料進行更改
也就是說伺服器上會有一個使用者需要的完整的資料存在, 瀏覽器端僅僅被動同步

應用程式都是這樣子的，數據最後都是落地在伺服器上。

伺服器上保存每個使用者目前所有的狀態, 例如瀏覽器到哪個表的哪個位置等等
這樣伺服器就能計算出目前使用者所需的全部資料

一般來講，伺服器都是設計成無狀態的，這個以後專案發展壯大時，伺服器擴充的需要。而瀏覽器需要數據時去伺服器獲取數據，伺服器根據瀏覽器的發送的參數和接口協議提供數據，並且瀏覽器很容易知道當前用戶在哪個表哪個位置。例如，新浪微薄網站，快到頁面尾部的時候，就主動去伺服器拉數據，到達一定數量後，採取下一頁的連結去取得下一頁數據。

客戶端與資料相關的 Action 一律透過 WebSocket 向伺服器發送由伺服器處理,
伺服器透過 jsonpatch 和 WebSocket 對本地的資料備份進行更新

這個技術實作主要跟應用場景有關，websocket適合長連線獲取資料。如果僅僅是一般的更新資料用用普通的http協定就夠了。

mvc - 服務端渲染全域所需資料, 客戶端用 React 呈現, 這樣一套方案可行嗎?

全部回覆(2)我來回復