【译】为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与我联系。在这里能够看到个人其余文章！