1.3　同構應用

同構應用或通用應用是指代碼在服務器端和客戶端之間共享并且在兩者中都可以運行的 Web 應用。這種技術在可交互時間、A/B 測試和 SEO 這些方面尤其有效。由于可以在服務器端生成頁面，我們可以專注于項目的關鍵特性來優化代碼。

Web 應用在服務器端和客戶端之間共享代碼，因此，可以由服務器端來渲染瀏覽器請求的頁面。服務器端從數據庫或微服務取回需要展示的數據并進行處理，然后通過使用模板系統進行預渲染來生成視圖。這樣一來，提供給客戶端的頁面不需要往返請求數據就能顯示。

因為頁面已在后端預渲染，并且完成了部分或全部解析，所以頁面的可交互時間會被提前。這避免了前端的大量請求，也就是說，前端不需要加載額外的資源（比如 vendors 包、應用代碼），瀏覽器可以直接解析這個幾乎已經包含了所有資源的靜態頁面。

同構應用還有利于 SEO，因為頁面是在服務器端渲染的，不需要另外請求服務器端。既然同構應用不需要往返請求服務器端就能提供包含所有信息的 HTML 頁面，爬蟲就可以立即為它創建索引。

雖然同構應用在服務器端和客戶端之間共享代碼，但是實際上共享多少代碼取決于對服務器端和客戶端的設計。例如，我們可以混合使用不同技術，在服務器端渲染頁面的一部分以使可交互時間提前，然后懶加載其他的 JavaScript 文件，這樣做結合了同構應用和單頁應用的優勢。在 HTML 頁面中加載的文件會為頁面添加復雜的行為邏輯，從而把頁面轉變為單頁應用。

通過這種方式，我們可以根據項目的需求來決定共享多少代碼。比如，為了有一個可以讓瀏覽器快速加載的 HTML 骨架，服務器端渲染視圖時可以只內聯 CSS 和盡可能少的 JavaScript 代碼。再比如，假設客戶端的頁面沒有太多的復雜交互，就可以把所有的渲染邏輯和數據處理都放在服務器端。我們也可以采用混合的方式，把應用分為多個單頁應用，第一個視圖在服務器端渲染，然后在客戶端再另外下載一些 JavaScript 文件來管理單頁應用內的行為、模型和路由。

路由是同構應用的另一個有趣的部分。我們可以在服務器端管理路由，當用戶在客戶端點擊鏈接時，就提供一個靜態頁面。

我們也可以采用混合的方式，只對第一個視圖使用服務器端渲染，接著加載單頁應用，而服務器會做一個全局路由，服務于多個單頁應用。每個單頁應用都有自己的路由系統，以便在視圖之間導航。如果采用這種方式，我們就可以不受模板庫的限制，使用 React、Preact 等虛擬 DOM（document object model）來實現。許多其他的庫和框架已經開始提供開箱即用的服務器端渲染，比如 Vue（結合 Nuxt.js）、Meteor 和 Angular。

關于同構應用最后要提到的是，我們可以不費吹灰之力就很好地集成 A/B 測試平臺。A/B 測試是用一個頁面的兩個或多個版本同時進行實驗，看哪個版本的效果最好。在過去一年左右的時間里，許多 A/B 測試平臺不得不追趕前端技術，不僅要支持 jQuery 等 UI 庫，還要支持 React 和 Vue 等虛擬 DOM 庫。此外，它們還要支持 Hybrid 應用和原生應用。

這些公司采取的策略是在服務器端管理實驗，以利用代碼在服務器端和客戶端都能運行的同構特性。如果你正在使用同構應用，這顯然是一個很大的優勢，因為你可以在服務器上預渲染你要為特定用戶設計的實驗。為了選擇合適的實驗，這些解決方案還可以通過 API 與客戶端的原生移動應用和單頁應用進行通信。

但是，如果一個采用同構應用的項目相當成功，有數百萬用戶訪問，那么可能會面臨可擴展性問題。因為生成的 HTML 頁面是在服務器上預渲染的，所以需要創建合適的緩存策略以降低對服務器的影響。在這種情況下，如果對用戶請求的緩存做得好，像 Akamai、Fastly 和 Amazon CloudFront 這樣的 CDN 無疑會提高同構應用的可擴展性，因為它們避免了所有請求都發送到源服務器。從組織上看，同構應用和單頁應用存在類似的問題，它們都僅有一個代碼庫，并且可能由多個團隊維護。

如果每個團隊都明確只負責應用的某個部分，而且不和其他團隊有任何重疊，那么就有一些方法可以降低團隊間的溝通成本。在這種情況下，我們可以使用像 BFF（backends for frontends）這樣的架構來解耦 API 的實現，并且讓每個團隊都只維護自己關注的 API 分層。