我記得我剛?cè)胄械臅r候，Web 開發(fā)有個叫 MEAN（MongoDB, Express.js, AngularJS, and Node.js）的技術(shù)棧，當(dāng)時還是挺新奇的。時隔多年，MEAN 也沒人在提起，不過 JS 全棧開發(fā)的理念還是被更多人接受了。今年，有一個新的大前端概念——JAMStack——挺火的，今天就隨便聊一聊。
定義
JAM 其實是 Javascript、APIs、Markup 三個術(shù)語的首字母組合。通俗來說，JAMStack 就是使用 SSG（Static Site Generators）技術(shù)，并且不依賴 Web 服務(wù)的前端技術(shù)棧。
"A modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup"
— Mathias Biilmann (CEO & Co-founder of Netlify).
Javascript：網(wǎng)頁渲染工具；JAMStack 并沒有限制使用何種框架或是庫
APIs：一系列服務(wù)端行為的抽象，主要通過 https 與 Javascript 交互?？梢允堑谌教峁┑姆?wù)，也可以是自己搭建的 function
Markup：網(wǎng)站是托管在 CDN 上的靜態(tài)資源，Markup 就是生成這些資源的源文件。剛提出 Markup 概念的時候，大家都看好 Markdown 作為 Markup 語言，但是這些年更常用的是 Vue 或是 JSX 文件
架構(gòu)
OK，僅僅列出 JAM 定義，其實跟沒說一樣，我們還是看看他與傳統(tǒng)網(wǎng)站架構(gòu)的比較：
相比于傳統(tǒng)動態(tài)網(wǎng)站
看架構(gòu)圖就很直觀了，傳統(tǒng)的 web 架構(gòu)會有一個很厚重的后端服務(wù)器；而 JAMStack 更接近純靜態(tài)網(wǎng)站——它甚至通過 SSG 把數(shù)據(jù)和 html 一起托管到 CDN 上。
為什么會有 JAMStack 這么奇怪的架構(gòu)呢？我們還是要看應(yīng)用場景，以及它要解決的問題。對于一些新聞、企業(yè)官網(wǎng)、小型電商，這類 CMS（Content Management System）網(wǎng)站，它的內(nèi)容更新非常緩慢。傳統(tǒng)的網(wǎng)站架構(gòu)無論如何都需要一個實時的在線服務(wù)，它在處理這些不怎么變動的內(nèi)容時，很雞肋：計算量很小，但是依舊需要大量后端和運維人員維護(hù)網(wǎng)站的安全性、穩(wěn)定性、可伸縮性……
JAMStack 在這些場景下給出了新的解決方案：直接使用 CDN 分發(fā)靜態(tài)頁面以及數(shù)據(jù)；這些 CMS 就成了一個純靜態(tài)網(wǎng)站，上述運維難題也自然而然地規(guī)避了。據(jù)說，特朗普政府將白宮官網(wǎng)的 CMS 從 Drupal （PHP架構(gòu)）改成了 WordPress （JAMStack 架構(gòu)），每年能為美國納稅人節(jié)省 300 萬美元。
相比于純靜態(tài)網(wǎng)站
既然是 all in CDN，那為什么不用純靜態(tài)網(wǎng)站呢？我們再分析一下 JAMStack 與純靜態(tài)網(wǎng)站的區(qū)別。純靜態(tài)網(wǎng)站也是把所有內(nèi)容分發(fā)到 CDN 上，但是它對承載動態(tài)內(nèi)容并不是很友好。舉個例子，某公司要想改其靜態(tài)首頁的公告；傳統(tǒng)的做法是：運維人員（非開發(fā)）手動修改頁面，然后更新部署。但是這種解決方案一看就很前現(xiàn)代——編輯頁面就很麻煩的，還要自己操作一系列手動部署流程。
JAMStack 就給出了一個更動態(tài)的方案：事實上，JAMStack 是有后端的——一個叫 Headless CMS（無頭內(nèi)容管理系統(tǒng)）的后臺系統(tǒng)。所謂的“無頭”，就是用戶端的 UI 展現(xiàn)和后臺服務(wù)進(jìn)行解耦，后臺系統(tǒng)不負(fù)責(zé)定制用戶端的 UI——也就是去“頭”——只負(fù)責(zé)數(shù)據(jù)管理。它的大致流程是這樣的：
- 運維人員在無頭 CMS 系統(tǒng)里輸入數(shù)據(jù)
- 無頭 CMS 系統(tǒng)將數(shù)據(jù)寫入 DB，并觸發(fā) SSG 部署流程
- SSG 拉取 git 代碼和 DB 內(nèi)的相關(guān)數(shù)據(jù)，并生成靜態(tài)資源
- SSG 再將靜態(tài)資源部署到 CDN 上，并清理相關(guān)緩存
當(dāng)然，實際項目中大概率還會是操作 admin 頁面，然后調(diào)取無頭 CMS 的 API 的。JAMStack 的整個運行平臺是由服務(wù)商提供，頁面更友好，也更具自動化，從而減少了非技術(shù)人員的出錯的可能。
進(jìn)階版 JAMStack
上面提到的 JAMStack 是五六年前提出這個概念時的理論模型，但是我看了一些號稱 JAMStack 落地的網(wǎng)站，他們的實現(xiàn)其實并沒那么“教條”：
現(xiàn)在的 JAMStack 還是會從客戶端發(fā)送 API 請求數(shù)據(jù)的，只是 API 服務(wù)器很輕量，通常是 Lambda 這類 serverless 方法。有些 CMS 網(wǎng)站還集成了 auth 服務(wù)、搜索服務(wù)、支付服務(wù)等等，但是通常也是在前端直接集成三方服務(wù)的 JS 庫。
優(yōu)缺點
OK，我們簡單介紹了一下 JAMStack 的架構(gòu)，稍微復(fù)盤一下。JAMStack 的優(yōu)點有：
- 高性能：幾乎是純靜態(tài)的網(wǎng)頁，網(wǎng)絡(luò)請求基本流向了 CDN，很少有額外的數(shù)據(jù)請求
- 安全性高：不用太擔(dān)心服務(wù)器和數(shù)據(jù)庫的安全問題
- 成本低：靜態(tài)資源托管的費用非常廉價
- 更好的開發(fā)體驗：前端單獨開發(fā)、單獨部署、單獨測試，完全解耦后端架構(gòu)
當(dāng)然 JAMStack 的缺點也很明顯，業(yè)務(wù)場景非常狹小，只能用于內(nèi)容更新不大頻繁的 CMS 站點。國外也有無頭電商（Headless Commerce）的商業(yè)實踐，但是前景并不明朗。
工具 & 最佳實踐
JAMStack 的工具鏈基本和傳統(tǒng) web app 前端相同，區(qū)別主要是 SSG 方案的選擇：通常來說就是前端三大件（React、Angular、Vue）的 SSR 框架的抉擇——Next、Scully、Nuxt 等等。不過我最近發(fā)現(xiàn)了一些 JAMStack 的全棧解決方案：
- redwood.js：react + graphql + prisma 的 serverless 框架
- blitz.js：Typescript + Next + prisma + Auth 的 Node 框架，開箱即用
- midway.js：React/Vue + egg/midway + typeorm 的 serverless OOP 框架
這些方案本質(zhì)上就是 Node 全棧的 Monorepo 模版，開箱即用，并且高度適配主流的 serverless 服務(wù)。不過，真正用到生成環(huán)境，可能還得再等等。
此外，這些年 JAMStack 也總結(jié)了一套最佳實踐，主要有：
- 原子化部署：每一次部署都應(yīng)該是一個完整的站點 snapshot，不能有臟頁面
- Cache：一旦更新了靜態(tài)資源，就應(yīng)該立馬清楚 CDN 緩存，保證上線的站點資源唯一
- Git：構(gòu)建工作流要強依賴于 Git hook。Markup 的變更要快速響應(yīng)，也要方便地追蹤
- DevOps：能圍繞不同的開發(fā)階段、不同的運維需求快速地部構(gòu)建、部署出一套新的環(huán)境，方便開發(fā)、測試、驗收……
小結(jié)
從技術(shù)上講，JAMStack 本質(zhì)上就是一種增強版的靜態(tài)網(wǎng)站，不算太大的創(chuàng)新，只能算是 serverless 興起后的一種衍生品。不過，傳統(tǒng) Web 開發(fā)那一套“前端-api-后端-DB”的技術(shù)鏈確實過于繁瑣了，JAMStack 是一種改進(jìn)方向，至少在某些場景下是行之有效的方案。
