【译】为GatsbyJS选择一个合适的后端

• 原文链接 Picking a back-end for GatsbyJS
• 作者 Ross Whitehouse

不久之前，我又心血来潮想要把我的作品集站点重做一遍（大概六个月就会有这么一次），这回，我打定主意要学着用一用Gatsby。但是事情好像还没这么简单。使用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是我见到次数最多的一个名字。Contentful已经是一家知名的大公司了，有超过13万开发者在使用他们的服务（如果他们的官网所言非虚的话）。我也很喜欢他们的描述。“迅速。灵活。未来的可靠保证。带给你你现在的CMS所没有的一切”。说得更直白一点，就是“我的CMS比你的CMS不知道高到哪里去了。”

然而，和所有这一切宣言相伴而来的，是可想而知的高价。诚然，Contentful也可以免费使用，不过你得接受他们在你的页尾显示他们的logo，最多只能存储1万条记录，并且只支持3个用户——这其实还可以了。对于我的个人站点，我一点儿也不在乎页面最底下有些什么东西。如果你给客户做东西的时候，他们一定要在那儿放上别的logo，那你可以选择half-tier，其他功能都和免费版一致，但可以自定义页尾，价格是每月39刀。

Contentful价格

Contentful更高级别的价格上升得非常陡峭，特别是与一些同类产品相比。虽然这么说，如果你的客户愿意每月付949刀，那么何乐而不为呢？

Content model

注册（免费）之后，你就可以进入仪表盘页面，里面有一些临时内容，以及指向教学视频*的链接。你可以在仪表盘里看到你全部的内容类型。我为我页面上的文字设置了一个“Page”类型。你可以使用“Post”，或者其他任何自定义类型。

*视频里的哥们把Contentful中的“content”发成“开心、满意”那个意思的读音。我以前一直以为Contentful里的“content”会是“内容”的意思，就像CMS中的“content”一样。但我知道什么呢？他可是在那儿工作啊。

编辑类型

接下来你需要设置域（field）。Contentful提供了一个庞大的选项列表。如果你只想要一个简单的标题/正文，那你可以像上面这样设置。你也可以使用时间、日期、图片、JSON对象，以及其他类型。你还可以为域设置地区限制，只让特定国家的IP地址访问这个域；或者把某个域设置为必需项；也可以设置它们在CMS中呈现的方式。举个例子，我没找到怎么创建一个复选框（域类型里面没有checkbox），但是如果你创建一个短文本域，你可以选择只允许特定的一些值。接下来你可以把CMS外观设置为下拉菜单或者单选按钮。我其实是希望可以在添加域的时候就有这样的选项的——就像WordPress里添加自定义域的时候那样——不过只要你知道了应该怎么做，那也就没有什么问题了。

添加一个新的域

Contentful看起来是一个非常棒的服务。它并不完美，但它满足了我的所有要求——你还想要怎样的免费服务呢？（如果你也要做一个CMS的话），它绝对是一个需要打败的对手。

WordPress' REST API

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相仿的文章类型创建器。我可以创建一个编辑器，里面可以放上标题、正文、图片、位置、链接、颜色等各种不同的域。

Prismic.io

Prisimic的收费结构和Contentful相似——但从预算的角度来说，它的选择更多。免费和廉价级别（Free，Starter，Small）的差别其实仅仅在于支持的用户数。在这三个级别之上，还有一些高级版本，可以没有用户上线，还可以增加用户角色和协作这样有意思的功能。对于更大的项目，或者更大的客户，这些都是很有用的。

Prismic价格

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与我联系。在这里可以看到我的其他文章！