最近在研究JAMStack的一些相關內容，發現這的確是個好東西，因此想寫一篇文章把這個概念分享給還不瞭解JAMStack的同窗。本篇文章主要包含如下的內容：html
什麼是JAMStack前端
JAMStack有什麼優點react
JAMStack適合什麼應用webpack
個人我的思考git
什麼是JAMStack
概念
JAMStack中的JAM實際上是三個詞的縮寫，它們分別是JavaScript, APIs以及Markdown。而Stack用中文的說法就是技術棧（Tech Stack），也就是咱們在構建應用的時候具體使用到的技術的集合。舉個例子，國外如今比較火的一個Stack叫作Mean Stack，它表示使用MongoDB + Express.js + AngularJS + Node.js這些技術來構建一個Web應用。所以用最通俗易懂的話來描述JAMStack就是：使用JavaScript，APIs和Markdown三種技術來構建Web應用。因此JAMStack是一種問題解決方案，而不是一個具體的實現。程序員
接着咱們再具體看一下JavaScript，APIs和Markdown這三種技術在JAMStack的世界中是起到什麼做用的。github
JavaScript
在JAMStack的概念中，JavaScript指的是在客戶端（client）實現動態網頁效果的JavaScript，它既能夠是React和Vue這種Web框架，也能夠是原生的JavaScript。它主要負責網頁動態的內容。web
APIs
這裏的API和咱們平時開發調用的API是同樣的。JAMStack的Web應用會經過JavaScript給後端API發送AJAX請求或者GraphQL query，後端API會以某種格式（通常是JSON）返回數據給前端來實現一些用戶交互。數據庫
Markdown
Mardown是一種輕量級的標記語言。在JAMStack的世界中，Markdown類型的文件一般是用來做爲生成靜態HTML文件的數據源。有用過hexo寫博客的同窗對這個概念確定不會陌生，由於hexo的原理就是將咱們編寫的Markdown文件根據咱們指定的主題或者模板生成一些靜態的HTML而後託管在github pages或者其它相似的靜態網站服務器來供別人訪問的。express
除了Markdown文件以外，JAMStack的靜態數據源還能夠是其它的東西，例如咱們後面說到的Gatsby（JAMStack的一種實現）就容許經過插件的方式使用SQL直接讀取數據庫的內容來生成靜態頁面。
瞭解了這三個概念的具體內容後，咱們再經過一個Gatsby的小demo來體會一下JAMStack的應用是如何工做的。
Gatsby Demo
因爲文章篇幅的限制，我將不在這裏爲你們講述Gatsby的具體用法，不過我後面會寫一系列文章來教你們如何用Gatsby來免費構建一個比較大的內容網站（CMS），你們能夠留意一下。
簡單來講，Gatsby是一個可讓開發者使用React，GraphQL等現代技術快速開發網站的靜態網站生成器（static-site generator）。它是存在於網站構建（build）階段的一個工具。爲了給你們一個直觀點的認識，我使用Gatsby搭建了一個簡單的我的博客網站，網站的源代碼能夠在個人github倉庫找到。
博客網站包含如下的功能：
博客列表頁面：展現我發表的全部博客。（靜態內容）
博客詳情頁面：展現每一篇博客的具體內容。（靜態內容）
博客評論列表：遊客評論博客以及展現遊客對這篇博客的評論列表。（動態內容）
細心的你必定注意到了我在上面每一個功能點的右邊標出了這個功能是靜態的仍是動態的。所謂靜態的內容就是那些不會常常發生變化的內容，這些內容在一段時間內不一樣用戶訪問的時候都會獲得一樣的結果。而動態的內容就是那些頻繁發生變化的內容，例如遊客對個人博客的評論。那麼我爲何要區分開這兩種類型的內容呢？要回答這個問題咱們能夠先看看若是使用服務端渲染（SSR）的方案這個博客應用是如何運行的。首先遊客會向SSR服務器發送一個查看某個博客的請求，SSR服務器收到請求後向後端服務請求這個博客的內容而後渲染出一個HTML頁面而後返回給用戶。這時候若是其餘用戶也向SSR服務器請求了一樣的資源，SSR服務器仍是會作一樣的工做，請求資源 + 渲染頁面。這個時候其實SSR服務器消耗了不少IO和CPU資源來作這些重複性的渲染，並且隨着你的博客訪問量的增大這些無用的資源消耗也會愈來愈多，在不升級服務端資源的前提下用戶體驗也會隨之變差。到這裏你可能會問，既然服務端渲染這麼浪費資源，咱們不進行SSR，直接將webpack打包生成的文件放在一個靜態服務器而後頁面都是在瀏覽器渲染不就好了嗎？從實現博客功能的層面上來講這是沒有問題的，但是這對搜索引擎優化（SEO）很不友好，百度收錄不了你的博客，你的網站火不起來啊！
爲了不重複性的無用渲染並且能對SEO友好，Gatsby採起了區分網站靜態內容和動態內容的技術方案。對於那些不常常變更的並且但願被搜索引擎收錄的靜態內容，Gatsby會在Webpack打包階段就生成，這樣就不須要在用戶訪問該頁面的時候才浪費資源來渲染頁面了，並且這些靜態文件還能夠經過CDN來優化用戶體驗。而對於那些數據常常發生變化的且不須要被搜索引擎收錄的內容，它們會等到瀏覽器實際渲染對應組件的時候才經過APIs動態獲取數據渲染出來。
咱們接着來看一下博客網站的代碼目錄結構：
上面代碼中，server文件夾存放的是一個簡單的管理用戶評論的express應用，src文件夾纔是Gatsby操做的前端資源，它包括如下內容：
blogs：這個文件夾是用來存放博客內容的，每個Markdown文件都會生成一個靜態的HTML文件。
components: 存放React組件用的。
images：存放博客的一些圖片資源。
pages: 網站的路由文件夾，這個文件夾下的每個文件都會被生成一個對應的HTML靜態文件，當請求該路由時會直接返回該靜態文件。例如如今pages底下有兩個路由，404的路由對應着的是沒找到資源的頁面，而index路由則是博客的主頁面。
templates: 網站的模板文件夾，該文件夾底下只有一個叫作blog-post.js的模板文件，在Gatsby構建網站的時候blogs文件夾底下的每個Markdown文件都會經過這個模板文件生成一個對應的HTML文件，這樣當用戶訪問服務器的時候博客的HTML文件就會被直接返回而無需進行服務端渲染了。
接着咱們能夠看一下Gatsby打包會生成哪些文件：
由上圖能夠看出，Gatsby會爲每個pages文件夾底下的文件生成一個對應的html文件，以及爲每個blogs文件夾底下的博客生成一個靜態的HTML文件，同時還有一些在客戶端執行的JS文件。生成的文件能夠直接使用靜態網站服務器來爲用戶提供服務，同時你還能夠把它們放在CDN中來讓用戶訪問起來更快。
最後讓咱們來看一下這個博客網站的運行效果吧：
上圖中我點擊了「如何立刻實現財富自由」這個博客，進入到博客詳情頁時瀏覽器沒有從新向服務端請求博客詳情的HTML文件，而是直接在瀏覽器完成渲染，用戶體驗很是之流暢。這實際上是Gatsby應用的一個很大的亮點，那就是：Gatsby打包的應用在瀏覽器首次請求得到提早生成的靜態HTML文件後，會演變成一個React SPA應用，接下來的用戶交互就和通常的SPA應用沒有任何差異了，換句話來講，Gatsby既保留了SSR方案SEO友好的優勢又保留了SPA應用的流暢用戶體驗，可謂是各取所長，揚長補短了！
其餘例子
其實JAMStack的應用如今已經有不少了，只不過咱們平時沒有留意到而已。舉個例子，React開發者十分熟悉的React官網reactjs.org就是用Gatsby構建。那麼除了這些比較簡單的文檔性和博客網站，JAMStack能夠用來構建複雜的商業應用嗎？答案是確定的，除了一些簡單的CMS平臺，JAMStack還能夠用來搭建諸如braun這類電商平臺，你可能想不到的是著名的程序員學習網站freeCodeCamp也是使用JAMStack技術棧來搭建的，你們能夠去網上（Google）查一下關於freeCodeCamp架構設計的視頻或文章，看完以後我相信你會對JAMStack有更深刻的理解的。
JAMStack的優點
在上面的介紹中我已經大概說了一些JAMStack的優點了，其中包括SEO友好還有流暢的用戶體驗，那麼除了這些，JAMStack還有沒有其它吸引人的地方呢？
高性能
爲何JAMStack是高性能的呢？這是由於JAMStack的應用將網站的靜態部分和動態部分區分開來了，那些不會頻繁發生變化的內容會被提早生成，從而無需使用額外的計算資源來進行服務端渲染。這樣用戶首次訪問某個頁面的時候速度會變得很快，並且這些靜態的資源還能夠被放在CDN來進一步提高用戶體驗。將動態內容和靜態內容區分開來還有另一個好處，就是咱們後端接口的職責更加明確了，API接口的數量會變得更少，性能也會變得更好。
高性價比以及高可擴展性
因爲咱們前端的內容都是一些靜態的文件沒有服務端渲染的要求，而靜態資源服務器對性能的要求並不高，因此咱們在購買服務器方面不須要很大的成本，咱們甚至還可使用一些諸如netlify和Gatsby Cloud等免費資源來託管咱們的文件。對於後端來講因爲咱們已經將先後端完全分離了，因此後端可使用一些廉價的Baas或者Serverless服務，例如可使用Auth0做爲咱們的用戶鑑權服務，使用Firebase做爲咱們的接口服務等等。使用這些Baas和Serverless服務有一個好處就是它們很便宜，並且它們是按照接口使用量來收費的，你的用戶量決定了你的支出，若是你的用戶不多，你甚至不須要花一分錢。
除了極高的性價比，JAMStack還有很好的擴展性。舉個例子，假如你如今的博客網站由於某一篇博客忽然火了，訪問用戶激增。若是你的前端靜態文件使用的是CDN網絡的話，你的網站很容易就能夠擴展了，一切都是自動的，無需你作任何東西，然後端若是你使用了Serverless和Baas的解決方案的話，一切也是自動的，用戶不會感受到有使用體驗的差異，而你只須要給使用到的服務平臺多一點點費用而已。
更好的開發者體驗
拿咱們前面提到的Gatsby來舉例，它就容許咱們使用一些現代的前端技術來進行開發，例如React，Styled-components和GraphQL等，這些都是咱們前端開發者十分熟悉的技術了，沒有很大的學習成本因此開發者體驗會很好。除此以外，因爲Gatsby使用了React，因此它間接上接入了React的生態系統，這樣開發者在開發Gatsby應用時就可使用React生態的各類最佳實踐和庫實現了，這無疑能夠大大提升咱們的開發效率。
更高的安全性
因爲JAMStack是一種先後端分離的技術，沒有了後端渲染因此能夠下降被攻擊的風險。舉個例子採用Gatsby生成的CMS平臺就比傳統的WordPress平臺安全不少：）。
JAMStack適合什麼應用
既然JAMStack有那麼多好處，咱們是否是一把梭在全部的項目中都使用JAMStack呢？答案是否認的，因爲JAMStack須要咱們將網站的靜態部分和動態部分區分開來，靜態部分的內容會在構建的時候就生成而動態的內容會在瀏覽器進行渲染，這個特色就註定了它不適合於構建如下類型的應用：
掘金，知乎這種主要由第三方用戶建立內容的應用。因爲這些應用的內容都是由平臺用戶建立的，並且用戶能夠不斷地修改和刪除已經建立的內容，若是使用JAMStack的話網站的內容就須要被頻繁構建，這顯然是不合理的。
微博，推特這種社交應用。這類應用的內容除了頻繁更新以外，還有就是動態內容多於靜態內容，例如用戶的主頁只會展現他關注的人發表的動態，因此也不適合使用JAMStack。
一些不須要SEO的應用。JAMStack一個很大的優勢就是對SEO友好，若是你的應用沒有被搜索引擎收錄的需求的話，就不必使用JAMStack了。
內容不少的應用。因爲JAMStack須要咱們每次都構建出全部的靜態資源，因此對於那些靜態內容不少的應用（例如頁面數超過50k）的話，每次構建應用都須要大量的時間，所以這種類型的網站也不適合用JAMStack。
相反JAMStack十分適合構建如下類型的應用：
項目文檔之類的網站，例如React的官網等。
企業或者組織的官方網站。
我的管理的博客網站。
中小型規模的CMS平臺。
中小型的電商平臺。
既有須要被SEO的靜態內容又有動態的不須要SEO的內容的混合應用。例如一些To B的平臺，裏面既有用戶的工做臺又有一些操做文檔相關的靜態內容。
固然了我在這裏列出來的不管是適用仍是不適用JAMStack的應用其實都是一些很籠統的分類，咱們在實際開發時還得具體問題具體分析，根據實際狀況來評估咱們的應用是否是適合使用JAMStack來開發。
個人我的思考
在最後我想說一下我本身對JAMStack的一些思考。
首先我我的十分看好這個技術棧，也會在往後的開發中使用這個技術棧。由於它幫我解決了網站SEO的問題。在不瞭解JAMStack以前，若是我想個人網站被搜索引擎收錄要麼就是刀耕火種地硬寫HTML和原生JS，這種方案明顯開發效率十分低下。還有一種方案就是我使用React等現代開發技術，這樣我就得學習next.js等SSR技術來實現SEO，這個方案有一個問題就是學習next.js有必定的學習成本，並且在項目上線後我得維護一個後端服務來進行服務端渲染，因此會有必定的運維成本。但是使用了JAMStack或者說是Gatsby後這些問題就迎刃而解了，由於我能夠繼續使用我熟悉的React技術棧來快速開發Web應用，還無需考慮服務端渲染的問題就能夠達到SEO的效果，這不是美滋滋？
其次我以爲JAMStack這個技術棧十分有利於咱們實踐一些本身想到的不肯定能不能成功的點子（創業想法）。上面在介紹JAMStack優點的時候，我提到了一點就是使用JAMStack其實你能夠免費部署你的應用，由於你能夠將前端的靜態代碼放在一些免費的靜態資源託管服務器，而後後端使用一些免費的Baas API服務，固然了這隻適合於咱們平臺用戶量不大的情景，當用戶量大的時候咱們仍是得付費的。但是咱們網站剛起步的時候用戶量不都是不大的嗎？若是咱們一大早就買好服務器資源和域名，後面卻發現這個想法根本行不通的話，這些錢就算是賠進去了。相反，使用免費服務的話，即便咱們作的東西黃了，咱們也不會有什麼損失。
總的來講我對JAMStack這個技術棧是頗有信心的，特別是在CMS內容管理平臺這方面我相信它必定會逐漸火起來，並且有可能能夠取代WordPress的地位。
順手點「在看」，天天早下班；轉發加關注，共奔小康路~
本文分享自微信公衆號 - 1024譯站（trans1024）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。