虎瀾集: 網頁與資料庫 (2)

October 9th, 2016

前面我們談過，動態資料大多是這樣來的:

Some DB <-> Some middle-ware <-> Web server <---> Web Browser

真實世界裡，資料不是簡單的整批餵過來餵過去的，它牽扯到「查詢」。「查詢」是所有資料操作的基礎，傳統的做法是把所有的查詢全部丟回去 server 端，然後 server 產生過濾後的結果，變成新的網頁再丟回 browser，周而復始的結果就是一個字: 慢。於是乎，聰明的微軟工程師發明了 AJAX，其精髓就在於「只要求 server 產生需要變化的部份」，但說穿了這只是一種最佳化的手段而已，你每次重連都還是要再跟 server 要一次資料的。

換一個角度想，我們可不可以用這樣的架構呢?

Some DB <-> Some middle-ware <-> Web server <--- sync ---> Web Browser

所有 UI/data 先丟到 browser 裡快取起來，接下來只在需要的時候去更新 data 就好，server 專心管 data 把 UI 的部份全部丟回 client 去 render。對於許多應用而言，這樣的架構可以應付更高的 load，那為什麼一開始的時候就沒人動過腦筋把資料放在 browser 端呢? 其實不是沒有，事實上是有很多失敗的嘗試的。要記得在 Chrome 出來強迫大家賽豬公之前，市面上的 browser 們跑 JavaScript 的速度只能以令人髮指來形容，把 UI 丟過去是件很神勇的行為。那個年代也不是沒人搞過 client-side storage (ActiveX 就可以)，只是要嘛是限制多多只能 demo 用，要嘛就是安全漏洞漏的有點大還真是不太好補。但時代在變科技在變，所以大家又動起了這種腦筋，只是這次比較麻煩一點，因為要玩 W3C 規格。

W3C 規格是各 browser 廠商用以製作 browser 的標準，也是網頁得以在各平台通用的基礎。它的運作基本上是這樣，一群熱心人士搞出一個論壇，這論壇上分板 (學術上的名稱是工作群組)，各個鄉民就按自己的興趣去加板，夠活躍的就可以當板主。每個鄉民都可以提規格草稿，如果板上其他的鄉民都很有興趣，就可將規格草稿提交討論，看看做 browser 的大佬們有沒有興趣，若是好幾個大佬都有興趣，而且沒有大佬強力反對的話，這規格草稿就可以變成建議。這時候若是有大佬把它試做出來，而且阿宅們都還用的蠻爽，那就會變成正式規格。因為軍備競賽的關係，除了某 A 家比較傲嬌不一定要鳥你之外，大部份的大佬都會撩下去把規格弄出來。

所以呢，按照政治學原理，某個規格草稿只要有大佬力婊，那保證是黑到不能再黑，死到不能再死，永世不得超生啊 ~~~ 很不幸的，我們很快就會看到在 web data 領域不得超生的典型。欲知後事如何，且聽下回分解 …

Web Development, 技術文章 | Comments