进击的JAMStack

最近在研究JAMStack的一些相关内容，发现这的确是个好东西，因此想写一篇文章把这个概念分享给还不了解JAMStack的同窗。本篇文章主要包含如下的内容：

• 什么是JAMStack
• JAMStack有什么优点
• JAMStack适合什么应用
• 个人我的思考

什么是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的世界中是起到什么做用的。

JavaScript

在JAMStack的概念中，JavaScript指的是在客户端（client）实现动态网页效果的JavaScript，它既能够是React和Vue这种Web框架，也能够是原生的JavaScript。它主要负责网页动态的内容。

APIs

这里的API和咱们平时开发调用的API是同样的。JAMStack的Web应用会经过JavaScript给后端API发送AJAX请求或者GraphQL query，后端API会以某种格式（通常是JSON）返回数据给前端来实现一些用户交互。

Markdown

Mardown是一种轻量级的标记语言。在JAMStack的世界中，Markdown类型的文件一般是用来做为生成静态HTML文件的数据源。有用过hexo写博客的同窗对这个概念确定不会陌生，由于hexo的原理就是将咱们编写的Markdown文件根据咱们指定的主题或者模板生成一些静态的HTML而后托管在github pages或者其它相似的静态网站服务器来供别人访问的。

除了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的地位。

我的技术动态

---

文章首发于个人我的博客

欢迎关注公众号进击的大葱一块儿学习成长