前言
前陣子寫 Next.js 筆記，私下和朋友們討論 Gatsby.js「The static dynamic site generator for dynamic web developers」部分時提到了 Jamstack，其中一位夥伴說了：
那 Jamstack 跟我們寫框架的 SPA 網站不是一樣嗎？
提問者後續在其他人的解釋下才理解差異。之後想想，我在Next.js 筆記中 Jamstack 也只是草草帶過，確實有必要整理一下我的認知，大家教學相長，若此篇有什麼錯誤也歡迎指證。
什麼是 stack 架構？
有時我們會聽到 ${Something}stack 之類的名詞，開頭的字母即為技術的縮寫組合，例如：
- LAMPstack：
一般稱 LAMP，包含由 L(Linux)、A(Apache)、M(MySQL)、P(PHP/Perl/Python) 的技術組合。 - WAMPstack：
一般稱 LAMP，包含由 W(Windows)、A(Apache)、M(MySQL)、P(PHP/Perl/Python) 的技術組合。 - MEANstack：
一般稱 MEAN，包含由 M(MongoDB)、E(Express.js)、A(Angular)、N(Node.js) 的技術組合。
可以理解 stack 架構是一個開發工具的組合，一個 stack 的出現，可以當成目前技術的成熟或一定程度能解決開發需求的方案。
什麼是 Jamstack 架構？
Jamstack 的概念由 Netlify 雲端公司的 CEO - Mathias Biilmann 在 2016 提出，但他並非發明者，前面也說了 stack 架構是一個開發工具的組合，Mathias Biilmann 便是將這套漸趨熱門的技術整理成一個名詞，只是，Jamstack 也不僅是技術英文縮寫這麼表面的 stack 而已。
JAMstack 的早期定義
誠如前面 LAMP 與 MEAN 概念，「早期」說法多稱 JAMstack 而非 Jamstack，這個 stack 特色 JAM 縮寫來自 J(Javascript)、A(API)、M(Markup) 三者組合。
Javascript
這裡指的是運作在 Client 瀏覽器這端的 Javascript，受益於前端 JS 的發展，越來越多事情可以在
Client 去處理，例如(包含但不限於)三大主流生態圈：React.js、Vue.js、Angular.js，透過 Javascript 提供動態內容與互動，讓 Web 跳脫以往限制，往 Application 靠近。
API
現代網頁技術皆透過 Client 各種接 API 來和後端或第三方進行互動。而在最、最、最理想情況下，這裡的 API 指的是開發者在前端透過 API 來呼叫使用 Serverless 架構下雲端的各種功能，但我認為只要是用 JavaScript call API 獲得資料，即完成 JAMStack 中的 「A」，甚至這個 API 是 restful 或 graphql 都沒關係，重點是透過 API 這個溝通介面互動，達成前後端分離解耦。
Markup
Markup 指的是預建好，包含內容的 HTML，也就是靜態檔案 - static HTML。若少了 Markup，只看上面的 Javascript 加 API，你就會覺得：
「那 JAMstack 跟我們用框架寫的 SPA 網站不是一樣嗎？」
多 Markup 就完全不一樣了，開發者使用如 Next.js、Gatsby.js、Nuxt.js 之類的框架，通過使用構建框架或工具(SSG)在 build time 時預先建構 Markup：包含特定內容的 HTML，而不是依賴 Web Server 在 runtime 動態接收組成 HTML 再吐回去。
static HTMLL 可以被 CDN 快取住，使用者載入的體驗會比較好，若網頁後續有資料的更新，除了重 build 外，還可以透過 Javascript 與 API 來動態處理 Client 資料流與畫面。此外，內容為王，因為有 Markup 先建好 HTML，JAMstack 也不用擔心會有 SPA 架構導致的 SEO 問題。
從 JAMstack 到 Jamstack
「現在」搜尋 Jamstack 的資料，看到的名詞多為 Jamstack 而非 JAMstack，如果 JAMstack 和 Jamstack 一直都是講一樣的東西，那為什麼會發生名詞術語從 JAMstack 淡化並演變到 Jamstack 現象呢？
使用 JAMstack 甚至 JAM 一詞可能會誤導這個架構，如果 J、A、M 三個字母只是表象技術的結合，只看 JAMstack 開頭大寫會單純誤以為其像 LAMP 這樣 A+B+C 的技術組合，例如用了 MEAN 技術工具，它也可以同時是 JAMstack 呀，這麼一來開發者溝通會更加混亂。
在去年 2020 年時社群的討論，將 JAMstack 改為 Jamstack。社群也成立了網站，好讓開發者更快理解這個架構。隨著 JAMstack 統一成 Jamstack，其現在強調以下幾點特色：
Pre-render 預渲染帶來的優勢
對應舊版定義的 Markup。
網頁在 build time 時預先建構好 HTML，由於建好的 static HTML 可以被 CDN 快取，這降低了 server 的負擔與風險。要注意的是，這裡的 Pre-render 預渲染指的不是 SSR，在 Jamstack 架構下，開發者應該要盡可能的 SSG。
若想知道有哪些優秀的 SSG 框架可以帶 Pre-render 的優勢，可以到 jamstack 網站查詢目前有哪些主流 Site Generators 可供開發者選擇。
圖片來源：jamstack.org
Decoupling 解耦化
對應舊版定義的 Javascript 與 API。
前後端的解耦
隨著 Javascript 的強化與發展，越來越多功能可以在 Client 獨立完成，透過 API 與後端溝通。前後端的分離，降低了前後端義大利麵混在一起的複雜性，也改善了彼此邏輯的相依性和維護性。系統間的解耦
並且，先有前後端分離解耦，再仰賴雲端技術的發展，把部分後端 Server 架構丟給雲端去處理，甚至達成所謂 Serverless。解耦對系統的好處就是，隨著雲端技術的發展，若我們有雲端或第三方的服務要更換或獨立升級，開發者修改將變得更加容易，彼此間的相依性會比之前乾淨多。
低依賴或不依賴 Web Server
Jamstack 的其中一個特色是不依賴或低依賴 Web Server，但要怎麼做到這件事呢？依不依賴的差異為何？這個區別還是要回來看 Jamstack 如何運作。
藉由 SSG 靜態檔案的優勢，當 User 發出頁面請求時，Jamstack 不需在 Web Server 動態 SSR 來做頁面運算處理，直接返回 static HTML 即可，此外建構好的靜態網頁還可以被 CDN 快取住，不僅不用 Web Server，更進階一點還可以把其他服務由前面提到的 Serverless 架構來處理。
Serverless 不等於不使用 Server，而是將一些服務交給雲端來處理，諸如身份驗證、提交表格、資料庫查詢等等，可以交由各雲端的 Serverless Functions 來處理，以保持解耦化。所以說，在 Jamstack 架構下，Server 並沒有消失，只是看似隱藏了。
圖片來源：JAMStack vs Wordpress: Which is Better for Your Project
不過，我這裡的解釋不是直接寫死一句不依賴就結束，而是多加上低依賴。
因為 Jamstack 已不是 A+B+C 那種特定技術的組合，而是一種架構模式，這種架構並不是非黑即白的一定要全達成才算是 Jamstack。各位可以想想，使用了 SSG 在 build time 建構 static HTML，那萬一是新聞媒體網站，頁面幾千幾萬頁的，在 Jamstack 架構下要 build 到何時呢？ 以 Next.js 來說可以進行 ISR 來改善，但 ISR 就會需要 Server，前面也說了 Server 並沒有消失，只是看似隱藏了。所以我的解釋是：能不依靠 Server 就不依靠，能夠 SSG 就盡量 SSG，能將服務丟給雲端處理就交給雲端處理，只要有符合廣義的「Serverless」即算達 JAMstack 標準。
Jamstack 的優勢
更好的開發者體驗
透過 SSG，我們不用煩惱 SEO，不用管 Server runtime 怎麼 SSR 的邏輯。此外，Serverless 與不依靠 Web Server 並不是真的沒有 server 在運作，但若能將其交由雲端來處理，意味著我們不用去煩惱維護 server，可以更專注在程式本身的邏輯。佈署更簡單、更便宜
Jamstack 網站需要佈署的檔案，基本上都是靜態檔案而已，而在不同雲端佈署或遷移靜態檔案是相對簡單很多的。此外，架設靜態網站方案通常比較便宜，這應該不用多解釋。效能與速度
Jamstack 網站的載入速度快，透過 SSG 建構 HTML，在部署網頁內容就建立好了，當 user 發出網頁請求來，不用在 Server runtime SSR，架設網站的雲端負擔會減輕很多。並且 static HTML 可以透過 CDN 快取，傳統 Server 構建的網站也可以使用 CDN 快取，但通常是儲存快取住的 static 靜態檔案如：圖片和 CSS 樣式檔..等等。當整個 HTML 頁面都可以通過 CDN 提供時，速度自然快上得多。使用者網頁的載入速度和體驗自然也比較好。
- 相對安全
相對安全，「相對」，畢竟 API 交由雲端或第三方服務來處理，自己設計架構導致的資安漏洞機率也會變小，Server 被攻擊的風險降低許多，當然這不意味著 0 風險，開發者要是前端 JS 寫太爛那 XSS 等風險還是在。
結語
Jamstack 不僅是技術名詞的堆砌而已。
Jamstack 不只是 「JAM」 的組合，它確實對開發者帶來一些優點(尤其是前端背景的 Web 開發者)。雖然現在是 2021年，但我很喜歡 vercel CEO - Guillermo Rauch 在2020年的這篇文章 2019 in Review 提到的：
Static is the new Dynamic
Jamstack 資料流的流動跳脫以往綁定 HTML 的形式，既彌補 SPA 架構下 SEO 的劣勢，也沒有 SSR 給 Web Server 帶來的大負擔。
此外，這句話除了一語道破網頁技術的發展，疫情期間，這一兩年許多人或公司步伐緩了下來，但大家並非真的就是停滯不前，靜態就是新的動態！我自己也在研究 Jamstack 與 Next.js 的過程中，對技術趨勢有更進一步理解。
理解詞彙術語不會帶來什麼技術的強化，但若是個人、公司或新創有什麼小專案要開始起頭，可以一併把這個 Jamstack 放入考慮的選項，還是同樣的話「技術的選擇沒有優劣，只有適合的場域」。若有錯誤的部分，也歡迎指出來，大家教學相長。
參考
Jamstack.org
JAMstack 到底是什麼巫術？
从 IaaS 到 FaaS—— Serverless 架构的前世今生
Deploy a Serverless Frontend with the Serverless Finch Plugin
Serverless & FaaS
使用無伺服器架構建立應用程式2019 in review: static is the new dynamic
What are the differences between JAMstack application and SPA
JAMstack vs. Jamstack
Gatsbyjs glossary: jamstack
JAMStack vs serverless web apps
 - Stylelint_@tempura327_https://static.coderbridge.com/images/covers/default-post-cover-3.jpg)
