新旧交替，你敢相信？下一个应用程序可能没有后端……

全文共6648字，预计学习时长19分钟

图源：Unsplash

“历史老是惊人的类似，有重演之势。”

一位科技界的大佬和小芯如是说。

我于1999年创建了第一个网站，用了一些可供网站管理员使用的最早进的技术（这种状况确实不能称他们为开发人员）：所见即所得编辑器（WYSIWYG editors）。

对于我（还有不少人！）而言，这最初是指Microsoft FrontPage，而我正面带尴尬的微笑，以一种怀旧又羞愧的心情告诉你这一切。

个人网站是一堆静态的 HTML 页面，这些页面有不少 JavaScript 和精彩的 GIF，它们在20世纪初的互联网时代备受瞩目，而且由静态的托管者提供服务，这些托管者本质上至关于意大利的 GeoCities。

在接下来的几年中，我逐渐作出了更好的选择，例如2002年发布的 Macromedia Dreamweaver MX（也就是如今的Adobe）；其最大优势是生成更加符合标准的代码。

十年后的2009年，我仍在创建网站，但动态是那个时候的关键。全部页面都是使用 PHP 在服务器端生成的。不仅是PHP：开发人员当时也在用.NET，Java，Python，Ruby等构建全栈式网络应用程序。

这些技术并不彻底是新技术：ASP 在1996年先后出现，而 PHP 在1994年首次亮相！可是，20世纪头十年的后半期，正是在这个时候，有了简化网站开发的新框架推进，更多的小型团队和开发人员可使用这些技术。

例如，Django和 Ruby onRails 于2005年问世。此外，在那几年，人们开始注意到动态网站的便宜主机托管选项（Bluehost这类共享主机开发于2003年），所以开发人员没必要管理本身的服务器。

当时，云计算仍是一个相对较新的事物，总之，它基本上都是基础设施即服务。

图源：Unsplash

快进到当今时代。如今是2019年，开发人员如今正在……再次创建静态网站。你可能会称其为网站开发领域的尼采永恒回归的再现。

但这一次，状况有所不一样：得益于更新的 HTML、JavaScript、CSS 标准和 API，网络浏览器的功能远远超过了20年前。

如今，电子表格和3D游戏这样极其复杂的应用程序能够开发出来并在网络浏览器中运行，并且无需外部插件。（大量的GIF也会再次使用，但此次暗含了一些讽刺意味！）

JAMstack 和 Isolated Front End

HTML5 最初发布于2008年，自那时起，浏览器厂商一直在实施新的网络标准并向网站中添加 API。

改变体现于更多的“基本”事物，例如<video>标签在很大程度上推进了Adobe Flash退出历史舞台，对WebAssembly之类的网络构建方式提出了根本性的建议，所以开发人员经常很难掌握最新消息以及可能发生的状况。

可是，最大的进步是网络应用程序新设计范式的推广，这种新范式被称为JAMstack，包括JavaScript、可重用 API 和预渲染（pre-rendered）Markup。

该设想从移动应用程序中得到灵感，即便网络应用程序的前端层与后端层彻底隔离，人们也能够只凭借一组商定的界面用HTTPS进行通讯。

JAMstack 应用程序体系结构的概念概述

JAMstack 的 JavaScript 部分所起的做用应该是不言而喻的：整个应用程序都在客户端（即网络浏览器）中运行，由 JavaScript 支持（你也能够更加归纳地解释此定义，就像解释执行 JavaScript 代码的浏览器中相同的 VM 同样， WebAssembly也是如此）。

“A”绝对是最有趣的部分，它指的是API：API让 JAMstack 应用程序具备交互性，并为终端用户带来非凡的体验。你的静态应用程序能够经过 HTTPS调用的 API 与其余服务进行交互。

最简单的例子是 RESTful API，它们易于构建、方便使用。最近，GraphQL愈来愈流行，它对于能够用图表表示的数据特别有用（其发明于Facebook 并非巧合）。

对于某些状况，例如，那些须要交换大量结构化数据的应用程序还能够选择Protocol Buffer和gRPC，尽管它们目前须要代理才能与网络浏览器一块儿使用。

最后，实时应用程序可能会利用WebSocket。你能够自由选择你想要的任何 API 格式，只要它知足你的需求便可。

说到 API，一个很是重要的细节是任何人均可以拥有它们。你的应用程序可能正在与你（或后端团队）构建和维护的 API 进行交互。或者，你可能正在使用第三方API，例如 SaaS 应用程序提供的 API。稍后将重点介绍这些内容。

最后，JAMstack 中的“M”表明预渲染的 Markup。网络应用程序是静态 HTML 文件，在“构建时”经过各类打包工具（例如webpack、Parcel或Rollup）对这些文件进行预渲染。

Markdown文件中的内容也能够渲染，就像静态网站生成器同样，例如Hugo、Gatsby以及Jekyll。在部署应用程序以前，全部预处理都在开发人员的计算机或持续集成 (CI) 服务器上完成。

使用 JAMstack 编写的应用程序一旦被“编译”，就变成了一堆 HTML、JavaScript 和 CSS 文件，附带着所有资源（图像、附件等）。服务器端任什么时候候都不会处理。这给 JAMstack 应用程序带来了极大好处。

首先，JAMstack 应用程序极其容易部署、缩放和操做，并且它的性能极好。

你能够从云对象存储服务（例如Azure Blob Storage或AWS S3）交付静态文件，这些服务价格（每GB每个月只需花几便士）很是便宜，并且特别可靠。

使用对象存储服务时，你也不须要管理、修补服务器或框架，所以开销减小了，并且安全性也提升了。

而后，将 CDN（内容分发网络）放在对象存储的前面时，你的网站将由世界各地的多个终端节点直接提供服务和缓存，在全球范围内，你网站的访客将受到最小的延迟影响，此外，可扩展性也会达到极佳水平。

若是你愿意的话，也能够像我同样经过星际文件系统 (IPFS) 提供文件。

其次，JAMstack 的开发人员体验（DX）很容易进行。首先，前端开发人员和后端开发人员能够专心编写本身的代码，只要他们就接口和API达成一致意见，就基本上能够进行自主操做。

带有复杂模板引擎（还记得PHP吗？）的总体式应用程序时代已经一去不复返，这引发了两个团队间的冲突，让你们都很头疼。

前端应用程序在编译后只是一堆静态文件，所以它们也容易自动部署：级别较高时，你能够将新捆绑软件复制到存储区域，而后更新 CDN ，从而指向新资源。

前端应用程序的编译速度每每很是快，无需担忧容器化技术、容器编排以及Kubernetes等问题。

考虑到工具的标准化程度，有了预制模板，创建持续集成和持续交付（CI / CD）管道一般很简单。

最后，前端开发人员能够自由进行实验，在某些状况下，他们甚至能够将开发前端指向生产后端。

一切都与速度有关

图源：Unsplash

对于终端用户而言，真正的获益在于感受到应用程序的快速运行。这不只能够提升用户满意度，还能够提升用户的参与度和保留率。

为何会感受到应用程序的快速运行？本文将从如下三个方面来解答。

首先，应用程序自己异步加载数据，所以用户能够在加载数据时看到界面，并能够与其进行交互。下图是新版Twitter 应用程序加载的动图：

这个新的应用程序当即加载并异步请求数据

该应用程序自己几乎当即加载，而后逐渐开始异步请求数据，并填充整个界面。

第二个缘由是大量缓存应用程序的能力。对于不少的JAMstack 应用而言，JavaScript 和 CSS 文件不会常常更改，因此客户端下载应用后能够长时间缓存。

这样能够节省请求应用程序代码的时间，客户端只须要提取数据便可。此外，若是该网络应用程序是经过 CDN 提供的，那么它会容许用户从靠近他们的终端节点检索你的代码，极大地下降了延迟。

应用程序的代码可能有好几KB，即便如此，从 CDN 下载它的时间延迟下降了，还能够本地缓存文件，这实际上意味着该应用程序的运行速度变快了。

关于缓存，你还可使用诸如Service Workers之类的更多技术来实现应用程序代码和数据的缓存，进一步加快页面加载速度，甚至提供离线体验。

最后，API 服务器不须要花费时间生成并提供完整的 HTML 页面，它只须要处理原始数据（一般是 JSON payload，在传输过程当中使用 GZIP 压缩），而把构建页面的工做交给客户端完成。

将资源交给对象存储服务时，后端服务器不会收到对静态资源的全部请求，所以它将拥有更多的资源来处理实际的业务逻辑和API。

你可能不须要本身的API

图源：Unsplash

上面曾提到，JAMstack 中的“A”表明 API，并且你可使用任何人构建和操做的任何 API。

你可使用外部身份提供程序对用户进行身份验证。若是你要构建企业应用程序，那么目录可能已经位于Azure AD或G Suite Directory（或与之同步）。

至于消费者应用程序，能够考虑与Apple、Facebook、GitHub这样的社交平台合做。

也有像Auth0和Okta这样的公司，它们能够提供功能强大且可扩展的解决方案，包括账户管理（注册表单、密码重置...）以及与各种外部供应商的集成。

使人欣慰的是，不少其余的 API 至少能够支持来自上述某些供应商的身份验证令牌，所以你能够当即进行集成操做。另外，不管如何，使用外部身份提供程序而不使用本身的身份验证代码都是一个好主意，由于这种作法最安全。

而后，你能够集成大量的 SaaS 服务，这会使你的应用程序得以接触到大量的数据，拥有更多的功能，而你这一端无需付出任何努力。

API 能够应用于天气、交通、显示股票价格、地图、监控航班，甚至还能够用来订比萨。

你可使用 Google Analytics 或 Adobe Analytics 来计算网站的流量。若是要建立博客，那么你可使用Disqus或Commento之类的服务，从而轻松实现用户对帖子的评论功能。

若是你须要内容管理系统来修改网站内容变得轻松愉快，那么“无头内容管理系统”可为你提供多种选择。例如，Strapi和Ghost。甚至随处可见的 WordPress 也能够在无头模式下使用。

企业应用程序与 Microsoft Office 365 和 G Suite 等办公套件集成后，你就能够收发电子邮件、管理日历和联系人、建立文档和电子表格、访问企业目录等。

这些服务还附带 OneDrive 和 Google Drive 中的云存储，所以你能够轻松地使用它们来存储和检索数据。

开发人员还能够依靠外部服务来接受信用卡付款（如 Stripe）、在文件格式之间进行转换、为图像生成缩略图（例如CloudConvert）、处理视频、发送消息（可经过 Slack、Teams、Twilio 等服务）......

API的功能是列不完的。用户能够从前端应用程序直接访问某些数据库服务，例如Firestore。

最后，你还能够将某些“低代码/无代码”服务用于服务器环境必定须要进行的过程，由于它们须要链接客户端没法直接访问的服务（数据库、某些企业应用程序等）。

一种解决方案是Azure Logic Apps，它原本是一个为开发人员和企业而设计的 IFTTT，你能够经过 REST 调用来让它运行。

使用外部服务提供的 API 的好处不容错过。确保它们可用并根据须要进行扩展是其余人员的责任。

你无需修补任何应用程序或框架，更不用说基础架构了，全部这些都会交给一个团队来维护，从而保证其安全性。

关于隐私和合规性，还有一些有意思的好处。

图源：Unsplash

若是你的应用程序仅存在于客户端而未存储任何数据，那么 GDPR 合规性的责任多半将由你依赖的服务供应商承担，就像使用外部服务付款同样（如 Stripe），这让你免于听从PCI-DSS。

固然，若是没有其余选择，也能够构建本身的 API。

借助无服务器平台，例如 AWS Lambda和AzureFunctions，你无需管理和扩展本身的服务器，不过仍有负责的东西。

负责的内容包括修补应用程序，确保其在受支持的运行时上运行（例如：你使用的Node.js达到使用年限时，你要更新版本），能够视须要考虑如何地理复制这些部署和负载均衡。

构建本身的 API 一般也须要管理数据存储，这些数据存储须要通过复制、备份和缩放。

接下来是什么？JEMstack

依靠本身的 API 和/或第三方 API 来使用 JAMstack 构建网络应用程序，是当今网络开发过程当中最早进的设计模式之一。

数十年来，人们一直在将应用程序完整地移动到服务器上，并尽量地将大部分工做从客户端上移走，而后又将更多的任务放到浏览器上。

不管是你本身仍是其余人，还须要服务器的只剩下一个地方，那就是 API。那么按照逻辑，下一个问题是：“咱们如何才能彻底摆脱服务器？”

答案是：最终可能经过使用区块链实现，特别是以太坊(Ethereum)。

我建议称其为“JEMstack”，是 JavaScript、Ethereum 和预渲染 Markup 的首字母缩写。

该堆栈将是“ Web 3.0”或分布式 Web 的一部分。“JEMstack”分布式应用程序（或 dapps）将接受IPFS提供的服务，其数据将做为分布式总帐存储在区块链中。

其中的一些好处包括将数据的控制权交还给用户，并且不管怎样，开发人员都没必要为基础架构担忧。

以上这些还远远没有实现。你彻底可使用区块链（尤为是以太坊）构建 dapp，事实上，这样的应用已经有不少了：App.co上有一个不错的精选列表。可是，要使此类技术成为主流，仍须要解决许多问题。

实际上，构建以以太坊为基础的应用程序的开发人员经验 (DX) 确实很棒。

应用程序能够经过简单无缝地调用智能合约来轻松访问和更改存储在区块链上的数据。此类智能合约由一些代码组成，它们为了以太坊区块链（从技术层面来讲是以太坊虚拟机）而被编译，以后在上面运行。

智能合约能够存储数据并在上面进行计算，它一般由名为Solidity的语言编写，这种语言与C语言相似。

可是，我在写本文时发现，终端用户体验 (UX) 仍有很大的提高空间，这是普遍应用 dapp 的最大障碍，该障碍可能还会持续更长时间。

首先，大多数用户将须要安装浏览器扩展来与以太坊进行交互，例如 Firefox 和 Chrome 的Metamask和 Safari 的Tokenary。只有不那么流行的浏览器（如 Brave 和 Opera）才提供对以太坊钱包的内置支持。

Mobile 是另外一个雷区，用户须要在其中下载特定应用程序（例如 Coinbase Wallet 或 Opera Mobile）才能与区块链进行交互。

而后，用户必须处理以太坊钱包。虽然从以太坊读取数据既免费又便于操做（而且不须要用户交互），可是在区块链上写入任何东西都须要获得用户的手动批准，并且至少要支付“油费”。

用户须要支付一小部分以太坊代币，才能执行改变区块链状态的代码，并且不管智能合约功能自己是否可支付，这都是必需的（例如：它将资金（以太币）转移给其余人）。

用户体验并不让人满意，由于它要求用户显式单击弹出窗口，而后等待几秒钟到几分钟，以便以太坊区块链能确认交易。

固然，用户须要先购买以太坊令牌，这并不像看起来那样简单，尤为是在世界上某些国家或地区。

最后，若是用户放错了钱包的私钥或还原了单词，或不够谨慎，都会留下安全隐患。

确认弹出窗口是 Metamask UX的常见部分

目前有一个庞大的团体正在致力于改善区块链应用的用户体验，使其更容易添加身份，构建更透明的流程，使交易更快，甚至能瞬间完成。

每种技术仍处于不稳定状态，并且如今存在着各类各样彼此竞争的区块链技术。这与平台和框架的状况很类似。

真心但愿在接下来的几个月和几年中，会看到更多的融合和标准化，而最终写在“JEMstack”上的 dapp 可能会成为新的规范。

小芯相信，有生之年，必定能看到的！

留言 点赞 关注

咱们一块儿分享AI学习与发展的干货
欢迎关注全平台AI垂类自媒体 “读芯术”

（添加小编微信：dxsxbb，加入读者圈，一块儿讨论最新鲜的人工智能科技哦～）