花了 React 以後, 從資料渲染 View 流程就相對輕鬆了,
但更實用應用程式需要是有服務端支援, 多用戶, 即時同步, 這些等等,
我在已有的實踐當中遇到一些問題(我不是很熟悉後端的架構, 所以從前端角度看):
瀏覽器端快取資料時, 有時會遇到外部的資料只能從伺服器抓,
而伺服器並不總是知道瀏覽器端需要什麼資料
瀏覽器有一份資料備份, 就需要手動維護, 保持跟伺服器更新等等
而類似操作在伺服器推送資料時也會做, 這樣兩邊就有重複程式碼
#於是我在思考一個方案, 讓整個流程更清晰更簡單(小型的應用, 先不考慮性能):
瀏覽器端進行資料的操作, 全部靠伺服器推送的資料進行更改
也就是說伺服器上會有一個使用者需要的完整的資料存在, 瀏覽器端僅僅被動同步
伺服器上保存每個使用者目前所有的狀態, 例如瀏覽器到哪個表的哪個位置等等
這樣伺服器就能計算出目前使用者所需的全部資料
#客戶端與資料相關的 Action 一律透過 WebSocket 傳送由伺服器處理至伺服器處理,
伺服器透過 jsonpatch 和 WebSocket 對本地的資料備份進行更新
這樣一個思路我響了很久, 但沒開始深入, 有沒有同學思考過這樣的方案?
另外注意我考慮的場景是幾十人同時在線上的小應用程式...
滿天的星座2017-05-16 17:08:28
我這個應該不算答案,就當是一起探討一下吧。你描述的一些東西我覺得看不明白,我先來問問好保證我們在同一條線上:
瀏覽器端快取資料時, 有時會遇到外部的資料只能從伺服器抓, 而伺服器並不總是知道瀏覽器端需要什麼資料
等一下,從伺服器上抓資料的時候,不是要聲明請求類型的嗎?為什麼伺服器需要「知道」瀏覽器需要什麼資料?我的意思是,假設你快取的資料缺少(比方說)“作者資訊”,那應該 GET /author/:id
對嗎?這樣怎麼會變成伺服器「不總是知道」瀏覽器需要什麼資料?能否舉個例子說清楚你的意思?
瀏覽器有一份資料備份, 就需要手動維護, 保持跟伺服器更新等等、而類似操作在伺服器推送資料時也會做, 這樣兩邊就有重複程式碼
我覺得「推」表示:瀏覽器其實不知道資料有更新,伺服器知道,所以伺服器推給瀏覽器更新後的資料。而你在瀏覽器手動維護的資料則表示:你知道資料變更了,所以才要手動維護,並且要提交給伺服器以同步資料。
你不覺得這兩者剛好是一條線的兩端,其實不矛盾嗎?為什麼會有重複程式碼?你指的是用來同步資料的程式碼?
所以你所思考的方案:
瀏覽器端進行資料的操作, 全部靠伺服器推送的資料進行更改
意思是客戶端不做資料快取?只要有資料變更操作就從伺服器即時取得完整的資料(或者說,一個使用者做了操作就立刻把資料更新推給其他所有的客戶端)?
……哪個表格的哪個資料
若我沒理解錯,你的意思是假設我是用戶 A,我正在看/author/5
的資料,伺服器上應該有一個遊標機制註明:“用戶 A 正在瀏覽 authors 表 id 為 5 的數據”,是嗎?換句話說,每當 URL 改變的時候就應該發送給伺服器“我目前的位置”,然後伺服器就把相應的資料推送給我,是這個意思?
那…這和我直接 GET /author/5
拿到資料有多大的差別?
你描述的東西,我看得出來有你自己的想法,但是我覺得場景還是太模糊了。更想聽聽具體的東西,以具體場景為例到底解決了哪些問題?
淡淡烟草味2017-05-16 17:08:28
而伺服器並不總是知道瀏覽器端需要什麼資料
伺服器和瀏覽器端的溝通需要依據規範,backend和fontend的溝通在應用程式開發中,本身就很重要
瀏覽器有一份資料備份, 就需要手動維護, 保持跟伺服器更新等等
其實業務資料最後都是要保存到伺服器上,資料庫(mysql等)提供這類服務。而資料在伺服器和客戶端之間交互,準備的講,瀏覽器的資料可以叫做快取。快取範圍很廣,last_modified和etag也是快取之一,還有伺服器應用程式內部的快取
至於重複程式碼,其實很可能由於backend和fontend的分工不明確導致的,技術架構。不過有時候專案為了快速啟動,是允許重複程式碼的。後期可以慢慢重構。前期只能根據目前的技術水平選擇,而不應該陷入技術太深,導致專案無法按期完成
瀏覽器端進行資料的操作, 全部靠伺服器推送的資料進行更改
也就是說伺服器上會有一個使用者需要的完整的資料存在, 瀏覽器端僅僅被動同步
應用程式都是這樣子的,數據最後都是落地在伺服器上。
伺服器上保存每個使用者目前所有的狀態, 例如瀏覽器到哪個表的哪個位置等等
這樣伺服器就能計算出目前使用者所需的全部資料
一般來講,伺服器都是設計成無狀態的,這個以後專案發展壯大時,伺服器擴充的需要。而瀏覽器需要數據時去伺服器獲取數據,伺服器根據瀏覽器的發送的參數和接口協議提供數據,並且瀏覽器很容易知道當前用戶在哪個表哪個位置。例如,新浪微薄網站,快到頁面尾部的時候,就主動去伺服器拉數據,到達一定數量後,採取下一頁的連結去取得下一頁數據。
客戶端與資料相關的 Action 一律透過 WebSocket 向伺服器發送由伺服器處理,
伺服器透過 jsonpatch 和 WebSocket 對本地的資料備份進行更新
這個技術實作主要跟應用場景有關,websocket適合長連線獲取資料。如果僅僅是一般的更新資料用用普通的http協定就夠了。