【譯】爲GatsbyJS選擇一個合適的後端

• 原文連接 Picking a back-end for GatsbyJS
• 做者 Ross Whitehouse

不久以前，我又心血來潮想要把個人做品集站點重作一遍（大概六個月就會有這麼一次），這回，我打定主意要學着用一用Gatsby。可是事情好像還沒這麼簡單。使用Gatsby完成前端部分後，你打算怎麼處理後端呢？看看這篇文章吧，如今咱們有很是多的選擇！

背景：爲何要用Gatsby？

要說還有什麼東西的選擇是比無頭內容管理系統（Headless Content Management System, Headless CMS）的可選項更多的，那就只有靜態站點生成器（Static Site Generator, SSG）了。咱們能夠用Hugo（基於Golang），Jekyll（基於Ruby），甚至是Nuxt（基於VueJS）。在茫茫的SSG中，我爲何選中了Gatsby？緣由不少，但最主要仍是由於我是一個職業的React.js開發者，因此使用一個基於React的SSG真的很爽。

Gatsby把本身形容爲一個「超級迅捷的React靜態站點生成器」（Blazing-fast static site generator for React）。因此，我能夠在建站的同時，用上一些React的技能，聽起來很不錯？與此同時，我也一直在尋找業餘項目和幫別人建站的活，因此若是我能夠用一套JAM技術棧（JAMstack）更快、更容易地解決原來用Wordpress技術棧作的工做，那是否是徹底沒法拒絕了？那麼就這樣向前吧！但在此以前，我得先拿我本身的站點來練練手。

什麼棧？JAM指的是JavaScript，API以及Markup（文本標記）。JAM有不少優點，但其中我最感興趣的是CMS與站點的分離。不再須要爲了一個小小的博客動用WordPress的全家桶了。若是想要對JAM棧有更多瞭解，能夠看這裏。

我以爲發現Gatsby真是撿到寶了。他們的網站上有不少安裝配置的教程，你能夠本身看看代碼，真的很簡單！我我的推薦Scott Tolinski的教學視頻。Gatsby以一個優雅的目錄結構，把React，React Router，webkit，ES6，Sass支持都囊括其中，以及，最爲關鍵的：GraphQL。

什麼QL？GraphQL是針對API的查詢語言。在WordPress時代，我想要顯示文章標題，必須得把整篇文章都抓取下來，可是用上GraphQL，我能夠告訴API：我只是想要文章的標題。能夠看看GraphQL的官網，很方便的。

學習以後，我很是快地搭起了整個站點。數不清的教程和指導資料都觸手可及。你能夠用上不少React的奇技淫巧（若是你願意），也能夠幾乎徹底避開與React的正面接觸（若是你想要）。還有多如牛毛的各類插件。而且，它們的數量只會與日俱增！

無論你是有React的使用經驗，仍是剛剛上路，Gatsby都是你的絕佳選擇。Gatsby不會告訴你你的代碼必須長成什麼樣。事實上，Gatsby讓你能夠用Markdown文件來寫你的頁面。比你想象的更加簡單！不過我對此並不在乎，也沒有使用。出於類似的理由，若是我之後給別人作網站，我也不會用這個功能。我可不想花上幾個月來教他們如何使用Markdown，克隆Git倉庫，把新的文章加入倉庫。因此，個人選擇是Headless CMS。

你建好了你的站點。你寫好了你的Sass。你搞定了你的Markdown文件（或者像我同樣沒用他們）。但如今你的站點仍是一片空白！該怎麼辦？如何填充內容呢？

下一步：後端

如今咱們須要尋找一個內容管理和發佈系統。它要有一套漂亮的API（否則怎麼配得上GraphQL呢）。這時候你會發現已經有一打這樣的工具了。還好Gatsby已經幫咱們作好了準備工做，你能夠找到一系列針對不一樣Headless CMS的插件，其中包括WordPress API，Contentful，Prismic和NetlifyCMS——事實上，Gatsby還爲使用NetlifyCMS寫了一份指南。接下來，我會帶着你們瀏覽一下其中的一些，讓咱們一塊兒來看看到底哪個最適合於這個小項目，而後開始使用它。

在寫了這篇文章後，我據說GraphCMS最近勢頭不錯。它生來就是爲GraphQL服務的，而且開發者提供了一個Gatsby腳手架，值得一試。

在開始以前，首先想一下爲何咱們但願在這個項目中使用JAMstack和Headless CMS。有一些是大衆化的緣由，而還有一些則是我的喜愛：

1. 上手簡單！
2. **不須要寫後端代碼。**我是一個前端開發者，老實說我不想花上幾個小時去寫"討厭"的PHP。拜託，饒了我吧。
3. **不須要服務器。**使用雲CMS意味着我不須要再花錢去配置一個SQL數據庫。
4. **編輯方便。**若是我須要很緊急地編輯某個站點的內容，或者個人一個客戶有這樣的需求，他們徹底不須要改動任何代碼。你可不想爲了改動一個拼寫錯誤專門啓動家裏的工做站吧！他們能夠從任何地方進行改動。

Contentful

在個人調研過程當中，Contentful是我見到次數最多的一個名字。Contentful已是一家知名的大公司了，有超過13萬開發者在使用他們的服務（若是他們的官網所言非虛的話）。我也很喜歡他們的描述。「迅速。靈活。將來的可靠保證。帶給你你如今的CMS所沒有的一切」。說得更直白一點，就是「個人CMS比你的CMS不知道高到哪裏去了。」

然而，和全部這一切宣言相伴而來的，是可想而知的高價。誠然，Contentful也能夠無償使用，不過你得接受他們在你的頁尾顯示他們的logo，最多隻能存儲1萬條記錄，而且只支持3個用戶——這其實還能夠了。對於個人我的站點，我一點兒也不在意頁面最底下有些什麼東西。若是你給客戶作東西的時候，他們必定要在那兒放上別的logo，那你能夠選擇half-tier，其餘功能都和免費版一致，但能夠自定義頁尾，價格是每個月39刀。

Contentful更高級別的價格上升得很是陡峭，特別是與一些同類產品相比。雖然這麼說，若是你的客戶願意每個月付949刀，那麼何樂而不爲呢？

註冊（免費）以後，你就能夠進入儀表盤頁面，裏面有一些臨時內容，以及指向教學視頻*的連接。你能夠在儀表盤裏看到你所有的內容類型。我爲我頁面上的文字設置了一個「Page」類型。你可使用「Post」，或者其餘任何自定義類型。

*視頻裏的哥們把Contentful中的「content」發成「開心、滿意」那個意思的讀音。我之前一直覺得Contentful裏的「content」會是「內容」的意思，就像CMS中的「content」同樣。但我知道什麼呢？他但是在那兒工做啊。

接下來你須要設置域（field）。Contentful提供了一個龐大的選項列表。若是你只想要一個簡單的標題/正文，那你能夠像上面這樣設置。你也可使用時間、日期、圖片、JSON對象，以及其餘類型。你還能夠爲域設置地區限制，只讓特定國家的IP地址訪問這個域；或者把某個域設置爲必需項；也能夠設置它們在CMS中呈現的方式。舉個例子，我沒找到怎麼建立一個複選框（域類型裏面沒有checkbox），可是若是你建立一個短文本域，你能夠選擇只容許特定的一些值。接下來你能夠把CMS外觀設置爲下拉菜單或者單選按鈕。我實際上是但願能夠在添加域的時候就有這樣的選項的——就像WordPress裏添加自定義域的時候那樣——不過只要你知道了應該怎麼作，那也就沒有什麼問題了。

Contentful看起來是一個很是棒的服務。它並不完美，但它知足了個人全部要求——你還想要怎樣的免費服務呢？（若是你也要作一個CMS的話），它絕對是一個須要戰勝的對手。

WordPress' REST API

自打我開始敲代碼，我就一直把WordPress用做一個傳統的CMS。我很熟悉它的工做方式，對相關的術語和文檔瞭如指掌。它的API包括了加強自定義域（Advanced Custom Fields, ACF）——這個插件，幾乎每個WordPress開發者和主題編輯者應該都很清楚——它使得文章能夠向千差萬別的自定義域徹底敞開。事實上，我本身使用Contentful過程當中的問題之一，就是我用了過久的ACF+WP的組合了。

關於WordPress的好處，我相信不用費什麼口舌。服務棒極了，界面棒極了，擴展性也很棒。事實上WordPress揚言29%的互聯網網站使用了他們的服務。這可真不是個小數目。談到插件，那更是數以百萬計，應用僅有：從搜索引擎優化（SEO）到電子商務，自定義文章類型，自定義域，以及更多。

那麼，要如何把它跟咱們的Gatsby項目結合起來呢？若是你用的是WordPress.com——WordPress的免費博客平臺——你就能夠免費地自動實現這一需求。若是你用的是WordPress.org——WordPress.com的大哥，容許二次開發——那你就須要本身來處理（多是免費的，但若是你的流量很大，那估計就不得不付費了）。對於我來講，WP API的問題在於，我想要擺脫慣常的服務器—數據庫配置，可是若是我用的是WordPress.org的CMS，那我就必須作這件事——即使是在容量和性能已經解耦的情形之下。我真正想要的就是像Contentful這樣的一站式雲CMS服務。

WordPress.com是一個值得考慮的選項。他們有一篇開發者博客介紹如何上手，與之關聯的是一個很是炫酷的API控制檯，你能夠在那裏試驗各類不一樣類型的請求。事實上，經過提供gatsby-source-wordpress這一插件，Gatsby已經讓這件事變得更加簡單化了。在你的Gatsby配置文件裏，你須要設置好你的WP URL，而後在你的WordPress站點，配置一個新應用，而後你的數據就能夠被GraphQL查詢獲取到了。

我這裏寫的不少內容都基於Jeremey Duvall精彩的教程。他的教程涵蓋了Gatsby，WordPress.com配置，以及如何用GraphQL將兩者聯結起來。都在那兒了。

WordPress.com只有一個問題，那就是它限制了文章和頁面的域：你只能選擇標題/圖片/正文。若是你想用ACF或者其餘插件，那就須要使用WP的付費版本。那麼這就跟WordPress.org沒什麼差異了：我必須付錢才能用。

NetlifyCMS

在個人另外一篇文章裏介紹了更多關於Netlify的內容——他們最初的產品是一個全站CDN——可是如今咱們主要關注他們的CMS。首先，由於它是基於React開發的，因此咱們有理由猜想它能跟Gatsby默契配合（更不用說以前提到的Gatsby插件了）。

NetlifyCMS的一大特色在於它的內容其實是保存在你的Git倉庫裏的。因此代碼和內容被打包在一塊兒版本化了。只要你還保留了這個倉庫，你就不可能丟失內容。而且你能夠一鍵查看歷史記錄——就像你看歷史代碼那樣簡單。

Gatsby爲NetlifyCMS提供了一篇貼心的[教程](Gatsby has a handy tutorial for NetlifyCMS )，但他們也說明了一點：若是你但願把內容和代碼保存到GitHub這樣的平臺，你須要用一個本身的服務器：

想要把你的內容保存在Git倉庫裏，這個倉庫須要是創建在GitHub這樣的平臺上。你須要設法進行權限認證，這樣Netlify CMS才能經過這一服務（如GitHub）的API來進行修改。對於包括GitHub在內的大多數服務而言，權限認證這一步驟須要藉助服務器才能實現。

不過，他們也提到，若是你把NetlifyCMS和Netlify結合起來，就能夠很方便地完成認證這一步驟。Netlify會監測（watch）你Git倉庫的變化，並自動更新。這一點很值得思考：這兩個服務就是被設計成協同使用的。因此若是你用了其中之一，那麼再用上另外一個，能讓你受益很多。這並不是絕對，但你徹底進入Netlify的生態系統以後，就能明白爲何它倆在一塊兒可以讓你事半功倍。

關於如何使用Gatsby+Netlify+NetlifyCMS，Pedro Duarte寫了一篇很好的文章。

其餘選擇中的佼佼者——Prismic.io和Cockpit

Prismic跟Contentful很像，基本上是同樣的，只有少量差異。我很高興看到跟Contentful相仿的文章類型建立器。我能夠建立一個編輯器，裏面能夠放上標題、正文、圖片、位置、連接、顏色等各類不一樣的域。

Prisimic的收費結構和Contentful類似——但從預算的角度來講，它的選擇更多。免費和廉價級別（Free，Starter，Small）的差異其實僅僅在於支持的用戶數。在這三個級別之上，還有一些高級版本，能夠沒有用戶上線，還能夠增長用戶角色和協做這樣有意思的功能。對於更大的項目，或者更大的客戶，這些都是頗有用的。

Cockpit也很相似，但有兩個主要區別：

• 它是一個開源項目——全部人均可如下載，全部人均可以貢獻，這就意味着它是徹底免費的，而且將一直可使用（無論是以如今的面貌，仍是新的形式）。Contentful的一個潛在問題就在於他們的服務是有可能終止的。他們在AWS上進行了備份，對於高級版原本說還有天天的備份，但實際的界面有可能再也找不回來（若是服務終止的話）。Cockpit做爲一個開源項目，他們的商業服務可能會終止，也可能服務器宕機一天或者完全崩潰，但Git倉庫會一直在那裏。
• 你須要本身託管——這與上一點緊密關聯。就算Cockpit徹底中止運營了，只要你本身的站點沒出問題，你的CMS就沒有問題。這對於技術狂來講是件好事。

結論——咱們應該選擇什麼後端？

寫這篇文章，至少讓我對於我須要的CMS有了一個特性清單。其餘的CMS或許也有很好的功能，可是對我來講，有那麼一些特性是更加劇要的。

無償使用

這是首要的。若是我把整個系統搞砸了，我不但願本身在抽身時那麼掙扎。若是我是在作一個更大的項目，在服務一個真正付錢的客戶，那麼我會從新考慮這一點的。同時，就目前而言我但願這個服務是能夠伸縮的。若是我幫一個朋友用Gatsby作了一個小站點，而後不久以後他的公司就飛黃騰達了，那我但願能夠相應地升級這個CMS以支持更多的用戶或者文章。

使用方便

從這個角度講，雲託管或基於Git倉庫的CMS是最好的。我不須要自建服務器，而且我能夠一站式管理整個系統。用戶界面要足夠簡單，以便非開發者使用。若是整個系統還有完善的客戶服務那就更好了，這樣我就能夠在遇到問題時尋求幫助。

最後，要說選擇哪個CMS，我得說上面提到的這些都有很不錯的功能，對於不一樣的項目，可能會有不一樣的最佳選擇。考慮到個人需求——小型業餘項目和我的站點——Contentful和Prismic看起來是最好的。他們都是雲服務，使用起來很輕便，提供了一套API，我能夠在任何須要的地方進行調用。他們的免費版本都提供了很全面的功能，而且升級起來也很簡單。這樣，我就能夠根據項目的實際狀況，來選擇一個最爲適合的版本。

這篇文章對你有幫助嗎？你用過這裏面提到的CMS嗎？或者你用過別的什麼CMS？請告訴我，我很高興聽你談談你的使用經歷。我計劃將來寫一寫託管方面的事情。上面我提到NetlifyCMS和Netlify配套使用效果很好，但其實還有別的選擇！我會考察一下GitHub Pages，Heroku，以及更多其餘選項！

你能夠經過Twitter或者Instagram與我聯繫。在這裏能夠看到個人其餘文章！