淺談 Jamstack
本文解釋本人對 Jamstack 與相關的技術名詞以及與傳統 CMS 架構的異同的理解。
我們從已經為人熟知的 CMS 開始說起。
CMS
CMS（內容管理系統，content management system）就是一般認知的網站系統，所謂的「內容」泛指網頁本身、網頁內的欄位（標題、作者、內文、品名、金額、標籤、時間等等等等等）、網頁的階層關係、網頁的外觀與樣式，CMS 不是只用於描述形像類網站，也包含功能型網站，因為不論何種網站，都只是內容、外觀、業務邏輯上的差異，所以它們的管理系統一概以 CMS 泛稱之。
最知名的 CMS 就是那 WordPress，以數量龐大的外掛與佈景著稱，常用於架設 blog、形像、購物網站。WordPress 通常搭配 MySQL 一起工作，同時 WordPress 也管理了從資料庫、後端管理以及前端網頁的全部工作，而與之對比的就是 headless CMS。
Headless CMS
Jamstack 的 J A M 分別代表 JavaScript、API、Markup，其實可以簡單的理解為前後端分離的架構，在 Jamstack 這種前後端業務分離下的 CMS，只專注於內容的管理，並透過 API 與前端溝通，CMS 並不涉及前端頁面的呈現，這種不管前端外觀的 CMS，我們稱為 headless CMS，就是沒頭沒臉的 CMS，只專注於內容的管理與資料的供應。
用 headless CMS 有幾項好處：
- 減少前後端的耦合程度，降低 CMS 系統的複雜度。
- 可以有多種前端，web、app 都可以，因為前端是透過 API 與 headless CMS 溝通，所以一個 CMS 可以供給多平台前端，滿足現今多元平台的市況。
- 易於橫向擴展，當單台 headless CMS 遇到性能滿載時可搭配雲端平台的機制動態擴展應付突發流量。
也有缺點：
- 開發人員必須熟悉至少兩套框架：headless CMS 與前端框架。
Headless CMS 以整體專案的角度來看系統的複雜度反而是變高的，有可能要分成兩組人作業，並且必須考慮到 API 的 schema 規格，反之在 WordPress 下幾乎完全不用考慮前後端資料拋接的事情（但有客製化外掛的話還是會碰到）。
為何前後端分離？
大前端時代已經是不可擋的趨勢，在前端框架大爆發的時代，幾乎都已經把能搬的業務邏輯都搬到前端去做，後端就專注於管理資料與提供 API 給前端用而已，而再往前追朔其實也就是因應 iPhone 帶起的行動 app 的趨勢，開發者為了能夠有統一的 API 供應多平台使用，傳統的統包型 CMS 逐漸被 Jamstack 風格的 headless CMS 所取代。
再回頭看 WordPress，雖然 WordPress 本身不是 headless CMS，但 WordPress 是有提供 API 的，所以想拿 WordPress 做為純後端其實是可行，但問題是 WordPress 自己的前後端高度耦合，難以拆分，所以喜歡 Jamstack 風格的開發者就不太喜歡拿 WordPress 做為後端系統使用。
相較於 WordPress，另外一套較年輕的 Ghost 也是知名的 CMS，Ghost 最初也是設計成全包型 CMS，在 Jamstack 興起後，或許是歷史包袱不像 WordPress 那麼重的關係，Ghost 逐漸把前後端的耦合度降低，目前 Ghost 也可以是 headless CMS，用戶可以自由選擇要用 Ghost 自己的前端框架或是其它的前端框架。
不論是 WordPres 或是 Ghost，它們都是需要搭配資料庫才能運作的系統，而資料庫系統本身也會佔用主機資源（$$$），所以對於小規模專案的需求又有人發展出不用搭配資料庫的 CMS，這樣的 CMS 被稱為 flat-file CMS。
Flat-file CMS
望文生義，所謂的 flat-file CMS 即用檔案當資料源的 CMS，相較於 WordPress、Ghost 必須搭配資料庫使用，flat-file CMS 的內容都是以檔案的形式存在於主機內，檔案格式通常會是 Markdown 或 JSON 或 HTML，當然這些檔案內的 schema 也是要經過適當定義的才能被 CMS 正確讀取。
其實 flat-file CMS 與 WordPress 相當類似，只有在資料儲存層上有差異。
一些 flat-file CMS 的特點：
- 資料以檔案方式儲存，不以資料庫儲存。
- 通常不會是 headless CMS，而是像 WordPress 那樣是前後端全包型的 CMS，因為檔案作為資料源不比資料庫，難以提供高效能的 API 服務（此點非絕對）。
- 雖然資料源是檔案，但最終前端頁面也是由檔案＋模板動態產生的，所以雖然主機不用跑資料庫，但還是要跑 PHP 或其它語言程式。
Headless CMS & flat-file CMS
綜合前文所述，flat-file CMS 的「flat-file」是對底層資料儲存面的形容；而 Jamstack 風格的 headless CMS 的「headless」是對前端模組的形容，是不同面向的描述，因此兩者之前並不存在比較關係，容易讓人（我）疑惑的原因只是它們都剛好在同個年代興起而已。
Headless CMS 沒有前端模組，它的資料儲存可以是用資料庫或檔案；flat-file CMS 沒有用資料庫，它可以有前端模組或沒有前端模組。
Static site generator
來到最後一關，static site generator，靜態網站產生器，簡稱 SSG。
SSG 更單純，SSG 只負責把模板檔和內容檔（通常是 Markdown 或 HTML）組合起來並輸出成美美的 HTML 檔案，當然還有一些額外的工作，例如幫我們產出 sitemap.xml、依我們設計的目錄結構去產生、圖片縮放、幫我們更新索引清單等周邊工作。
因為 SSG 最後產出的都是靜態的 HTML 檔案，因此只要放到某個最便宜的網頁空間即可讓人訪問。
更複雜一點的 SSG，把前端框架摻進來做 SSG，就幾乎有無限的可能性，即便是靜態檔案，只要透過 JavaScript 與瀏覽器的 Web API 再加上網路上一大堆 API-based 的服務，即可變出各種花式 web app，什麼 blog、形象網站、購物站都沒問題，靜態檔案也可以跑的很動態。
Jamstack
回頭談主題 Jamstack，headless CMS 意味著 Jamstack 前後端分離之後端；SSG、前端框架意味著 Jamstack 前後端分離之前端，而後端其實也不一定要自己架 CMS，拿網路上現成的 API-based 的服務作為後端也是可行的，甚至像 blog 或形像網站，本身並不需要後端的存在。
另外一個個人觀點是，在大前端時代，前後端分離已是常態，Jamstack 這個用於描述這種分離後的架構的詞彙也會隨著成為常態而消失，就像以前電腦剛能播影音的時代，微軟定義了 MPC 的規格，然而隨著多媒體播放成為常態，又有誰會特地說自己的電腦是「多媒體電腦」呢？:p