作者 | 狼叔

由于BFF升级到SFF，除了享受Serverless基建的好处外，并没有任何业务价值的改变，所以核心只能在提效上发挥。提效第一点是开发者体验，这是Serverless托管前端所有场景的核心提效点。其次是搭建，搭建和Serverless托管、前端工作台集合，可以让SFF提效更容易。中间对流程编排、智能化也有结合，相信大家能够理解它们的价值和应用场景。

搭建、流程编排、智能化组合提效，简化Serverless托管提效，让前端进入轻研发时代，我相信已经不远了。下面分享一下我关于Serverless新托管时代的畅想。

JAMS

从lamp到mean架构升级，之后就没啥新东西了。在Egg稳定之后，也是没有啥新意了，就算Fastify也不够亮眼，实话讲，那点性能优化不过锦上添花，还不一定赶上Node sdk升级的优化呢。

JAMstack算是一个比较新的概念，JAM是JavaScript、API和Markup的简称，前面第一个字母缩写，JAMstack一种基于客户端JavaScript，可重用API和预构建Markup的现代Web开发架构，这个价值在业界已经证明了，那么基于serverless的JAM，应该也是值得想象的。

本节核心内容是把JAM进行延展并推到JAMS的可能性。

什么是 JAMstack

JAMstack是指使用JavaScript、API和Markup构建的技术堆栈，需要符合下面三个标准：

• JavaScript：请求/响应周期中的任何动态编程都由JavaScript处理，完全在客户端上运行。这可以是任何前端框架，库，甚至是轻量JavaScript。
• API：所有服务器端进程或数据库操作都被抽象为可重用的API，使用JavaScript通过HTTPS访问。这些可以是定制的或利用第三方服务。
• Markup：模板化标记应该在部署时预先构建，通常使用内容站点的站点生成器或Web应用程序的构建工具。

当我们谈论“堆栈”时，我们不再谈论操作系统，特定Web服务器，后端编程语言或数据库。JAMstack与特定技术无关。这是一种构建网站和应用程序的新方法，可提供更好的性能，更高的安全性，更低的扩展成本以及更好的开发人员体验。

为何选择JAMstack？

• 更好的性能：为什么要在部署时生成页面时等待页面动态构建？当谈到最小化第一个字节的时间时，没有什么能比通过CDN提供的预构建文件更好。
• 安全性更高：将服务器端进程抽象为微服务API，可以减少攻击的表面区域。您还可以利用专业第三方服务的专业知识。
• 更便宜，更容易扩展：当您的部署相当于可以在任何地方提供服务的一堆文件时，扩展就是在更多地方提供这些文件的问题。CDN是完美的，通常包括扩展他们的所有计划。
• 更好的开发者体验：松散耦合和控制分离允许更有针对性的开发和调试，并且为站点生成器扩展选择CMS选项消除了为内容和营销维护单独堆栈的需要。

redwood.js

Redwood是一个全栈、无服务器的Web应用程序框架，它使您可以轻松地构建和部署JAMstack应用。https://redwoodjs.com/tutorial/redwood-file-structure

很明显，这是一套很潮的技术栈，但问题是组件的ui和逻辑如何抽离？这个问题依然没有解决。

对于GraphQL真是又爱又恨，基于模型（实体）和查询（Query）的方式，很好的做到了解耦，但这东西基于约定写法，必然会像Restfull api一样，都是好东西，但在落地方面不会很理想。

GraphQL如何能够和Formily进行集成，在模型和Schema/Form之间互转，可以想象的空间会尤其大。

重新定义 JAMS

之前JAMStack缺点

• 缺乏对较重和动态功能的良好支持：使用 JAMStack 的主要限制之一是它不能很好地处理电子商务购物和登录等更加动态的功能。这是因为这些功能需要数据库才能管理交易。
• 高度依赖第三方系统：高度依赖第三方系统意味着如果这些系统崩溃，那么 JAMStack 也会崩溃。

如果把CDN换成Serverless呢？将Serverless作为托管环境，API和页面都以函数的粒度放到Serverless上进行托管，是不是很好？

• 动态功能完美解决
• 依赖第三方系统也可以通过baas来解决

JAMStack on Serverless可以是JAMS，核心内容如下

• JavaScript：基于 JavaScript 创建动/静态 Web 应用。
• APIs：所有的数据行为通过可复用的 HTTP 接口（RESTFul 或者 GraphQL）完成。
• Mockup：使用构建工具 prebuilt 前端应用，部署到 Serverless 环境，能够同时支持csr和ssr。
• Serverless：利用Serverless基建优势，提供自动扩缩容零运维的Api和页面托管服务。

Jeff Atwood发表于2007年的这篇博客里，他提出了著名的“Atwood定律”，即”任何能够用JavaScript实现的应用系统，最终都必将用JavaScript实现。

在JAMS世界里，Atwood定律又一次完美的被证明了。

应用场景

JAMS是面向函数的Fullstack架构。它的应用场景包含了前端和sff的所有场景。
1、Zeit应用场景

2、Serverless CMS https://github.com/webiny/webiny-js

Serverless CMS (GraphQL + React + Node.js + AWS Lambda)

More Than “Just” a CMS：Build Websites, Apps and APIs With Webiny

As a Developer You Will Benefit From Several Features

• Comes with an admin theme with over 30 React components
• Built-in server side rendering
• CSS-in-JS via Emotion
• Deployment CLI with support for multiple environments
• Foundation for building dynamic serverless sites and apps
• Designed and optimized to run inside AWS Lambda

总结一下，整体上大家除了对CSR和SSR做同构上，没有做到极致外，这套方案还是非常ok的。接下来，基于Serverless，补足托管能力，JAMS会有更好的发展。

Serverless 新托管时代

类似于surge.shgit pages类似的托管服务很多，那么基于Serverless如何做托管呢？笔者如何定义Serverless新托管时代便是本节要重点聊的内容。

从 BFF 之痛到 SFF 收敛

了解托管之前，我们先看一下架构升级，从BFF到SFF的演进过程。

BFF即 Backend For Frontend（服务于前端的后端），也就是服务器设计 API 时会考虑前端的使用，并在服务端直接进行业务逻辑的处理，又称为用户体验适配器。BFF 只是一种逻辑分层，而非一种技术，虽然 BFF 是一个新名词，但它的理念由来已久。

在Node.js世界里，BFF是最合适的应用场景。常见的API、API proxy、渲染、SSR+API聚合，当然也有人用来做网关。

从Backend For Frontend升级Serverless For Frontend，本质上就是利用Serverless基建，完成之前BFF的工作。那么，差异在哪里呢？

核心是从Node到FaaS，本质上还是Serverless，省的其实只是运维和自动扩缩容的工作，一切看起来都是基建的功劳，但对于前端来说，却是极为重大的痛点解决方案，能够满足所有应用场景，基于函数粒度可以简化开发，乃生死必争之地。

Serverless简单理解是FaaS+BaaS。FaaS是函数即服务，应用层面的对外接口，而BaaS则是后端即服务，更多的是业务系统相关的服务。当下的FaaS还是围绕API相关的工作为主，那么，前端如何和Serverless绑定呢？

Serverless For Frontend（简称SFF）便是这样的概念，基于Serverless架构提供对前端开发提效的方案。

下面看一下SFF分工，这张图我自认为还是非常经典的。首先将Serverless劈成2半，前端和后端，后端的FaaS大家都比较熟悉了，但前端页面和FaaS如何集成还是一片待开发的新领域。

举个例子，常见BFF的例子，hsf调用获得服务端数据，前端通过ctx完成对前端的输出。这时有2种常见应用场景

1. API，同后端FaaS（RPC居多）
2. 页面渲染（http居多）

基于FaaS的页面渲染对前端来说是必须的。从beidou、Next.js、egg-react-ssr到Umi SSR，可以看出服务端渲染是很重要的端侧渲染组成部分。无论如何，React SSR都是依赖Node.js Web应用的。那么，在Serverless时代，基于函数即服务（Functions as a Service，简写为FaaS）做API开发相关是非常简单的，

• 1）无服务，不需要管运维工作
• 2）代码只关系函数粒度，面向API变成，降低构建复杂度
• 3）可扩展

大概三国演义对我来说印象最深的一句话估计就是分久必合，合久必分。本质上sff和bff做的事儿是一样的，如果说非要去掰扯出点东西，我想分久必合也算是一种吧。

通过 Fab 看托管

FABs（Frontend Application Bundles）是一种前端应用的bundle格式。

因为 FABs 包含了 server-side JavaScript 兼容能力，但可以非常简单的同构上传一个zip包文件就完成部署。你可以随意增加server-side 逻辑且不需要关注服务器运维相关的复杂性。它适合如下场景。

• 发布 server-rendered NextJS 应用到Cloudflare workers上
• 给cra创建react项目 增加 redirect 规则 ，不需要eject就能做到
• 使用 Gatsby 来生成logged-in 和 logged-out 主页，并且可以cookie来切换登录状态。
• 保护你的应用，防止未授权用户操作
• 发布每个提交到一个唯一的URL来分享协作进度
• ...等等

它原理很简单。FABs是一个特殊的zip文件，保护了1个组件和一个server-side JavaScript文件，以及静态资源assets目录。

对于纯静态站点，spa，或一个完全的服务器端渲染的js网站，FAB会帮你编译你的应用到这2个文件。

看一下写法

const getProdSettings = () => {
  return {
    // All production settings are bundled into the FAB here,
    // ensuring predictable behaviour regardless of host.
    // These are returned as a separate entry point, however,
    // so that any encrypted variables can be decrypted
    // by the host before being passed through to the render.
  }
}

const render = async (request, settings) => {
  // request: a fetch.Request object
  // settings: your production settings plus any
  //           environment-specific overrides
  const { body, statusCode, headers } = await myApp.render(request, settings)
  // return a fetch.Response object with the full data.
  // Streaming responses not yet supported, but will be in future.
  return new Response(body, { statusCode, headers })
}

module.exports = { render, getProdSettings }

和我们定义的ssr规范的中写法很像，原理上并没有本质区别。

我们再来歪歪一下。一个server.js和assets目录就可以满足所有的前端场景。

• 纯前端assets就够了。
• server.js可以满足所有bff应用场景，无论渲染，还是api proxy。server.js 是一个faas函数，可以随时发布到Serverless环境上。

相当于

• Serverless做了托管环境，几乎不用管运维
• 开发时用法，如now.sh或surge.sh，丝般顺滑
• 把ci/cd也接入进来，那么linc.sh做的就是这个事儿

FAB的核心难点是打包。

FAB可以在任何地方构建，并且产出独立的结果文件，可以有输入集合，fab.zip是一个每个字节都相同的包，无论何时何地都可以使用。这是因为包含了deterministic-zip模块，它从文件中删除修改时间戳，这样fab就会产生一致的结果了。

这意味着，在编译FAB之后，包含内容用于发布的Fab包拥有一样的MD5/SHA 哈希值。不需要引入新的发布，这是因为内容授权是一样的。不需要触发重新发布，当修改README.md 或端到端测试的时候。

这是很hack的技巧，但用起来确实会简单。但还有一个问题没解，就是node_modules是否需要打包的问题。打包到一个文件，会有加载性能问题，不打包就需要放到faas runtime里。各有利弊。

按照fab的玩法，node_modules放到faas runtime里，loader部分解析一下fab.zip执行就好了。这也是一个很好的做法。

抽象一个中间格式，做到部署无关，确实是一个很棒的做法，示例如下图。

我不管你用什么技术栈，一个server.js和assets足够用了，编译你自己做，然后按照我的方式达成fab包。这就是你发布时需要用的。剩下的就是发布到faas环境即可。

我们一直在追求Serverless在提效领域的极致。当所有前端场景都可以做到极简托管，在配套各种基建，轻开发模式，难道不值得当成梦想吗？

来自竞品的压力和启示

腾讯云Serverless的做法，投资serverless.com，笔者以为是挟天子以令诸侯的感觉。站在标准之上，有意思的很。投资coding.net，我理解是对WebIDE等轻量级开发方面做资源整合，也是一步好棋。

这些都不重要，我们要看的是它的托管能力扩展实现。

它的component做法https://serverless.com/components/ 很一般，但很实用。

核心要点：

• 指定website目录
• 提供一个函数

Serverless Components 是面向资源的设计，可扩展性极强。想AWS Lambda, AWS S3, Azure Functions, Google Big Query, Twilio, Stripe, Algolia, Cloudflare Workers 等都可以使用。大多数 Serverless Components 部署要传统云部署要快上 20倍。他们的意图是设计Serverless Components 来做到最大程度的快速部署，移除本地对模拟网络应用的依赖。

从这点上看，Serverless Components和fab的做法是一致的，都是把Serverless当做托管环境。不同的是fab要更极致一点。

接下来，集团内的Serverless也会围绕托管做，推进的2个核心点。

• http serve实现，基于midway-faas很容易
• serverless-side render实现，基于egg-react-ssr设计，已开源

对于BFF里的API、API Proxy这些都很容易基于FaaS搞定，对于前端关心的点，我的看法

• CSR要支持。把faas当cdn用，虽然Dirty，但对于中后台或外包来说是有积极意义的。
• SSR必要时能支持。把FaaS当Node用。
• 如果能随便切换更好。既要也要还要。

当然，ToC的场景和ToB的场景是有差别的，流量和成本成正比，必然会导致实现上的差别，这点在下一小结会讲。

除此之外，now.sh或surge.sh，linc.sh这些在易用性上做的实践是非常值得借鉴的。

Serverless-side render 会火

裕波曾在2017年问我，为何如此钟爱SSR？我的回答如下。

从前端的角度看，它是一个相对小的领域。PC已经非主流，H5想争王者，却不想被 React-native、Weex 中间截胡。无论怎么看，SSR能做的似乎都有限。但是，用户体验提升是永远的追求，另外Web标准化是正统，在用户体验和Web标准之间，又要和 Node.js 做结合，除了SSR，想不到更好的解法。

贴着C端业务，从后端手里接过来PC、H5，通过 Node.js 构建自己的生存之地是必然的选择。活下来之后，就开始有演进、沉淀，通过C端业务和 egg-react-ssr 开源项目的沉淀，我们成功的打通2点。

1. 写法上的统一：CSR和SSR可以共存，继而实现二种模式的无缝切换
2. 容灾降级方案：从Node SSR无缝切换到Node的CSR，做到第一层降级，从Node CSR还可以继续降到CDN的CSR

2019年，另外一个风口是 Serverless，前端把 Serverless 看成是生死之地，下一代研发模式的前端价值证明。那么，在这个背景下，SSR能做什么呢？基于FaaS的SSR如何做呢？继续推演，支持SSR，也可以支持CSR，也就是说基于FaaS的渲染都可以支持的。于是和风驰商量，做了Serverless端侧渲染方向的规划。

本来SSR是Server-side render，演进为Serverless-side render。元彦给了一个非常好概念命名，Caaf，即Component as a fuction。渲染层围绕在以组件为核心，最终统统简化到函数层面。

在今天看，SSR是成功的，一个曾经比较偏冷的点已经慢慢变得主流。

集团中，基于React/Rax的一体化开发，可以满足前端所有开发场景。优酷侧的活动搭建已经升级到Rax 1.0，对外提供SSR服务。在UC里，已经开始要将 egg-react-ssr 迁移到FaaS上，代码已经完成迁移。

• PC/中后台，使用基于React的CSR和SSR可以满足所有场景。
• 移动端/H5，基于 Rax 的CSR和SSR可以满足所有场景。尤其是Rax SSR给站外H5提供了非常好的首屏渲染时间优化，对C端或活动支持是尤其有用的。

还有一个命题是值得聊聊的，即如何在Faas函数还不能保证4个9的情况下接入？

直接接入FaaS，依赖的Serverless的基建稳定性，目前应该还没人敢保证4个9以上的稳定性。一个比较好的办法是自建网关，好处有2。

• 对于历史遗留问题，域名接入，反向代理等非常方便
• 在FaaS函数挂掉的情况下，可以降级到CDN托管

同一种写法，既可以支持CSR和SSR，同时发布到FaaS和CDN上，在网关上配置化容灾策略，这样做到3个9或4个9是很容易的事儿。

上图右侧是我们实现的新的基于ssr-spec和midway-faas的faas ssr实现 https://github.com/ykfe/ssr 。核心在Web目录，同时支持多个页面，且可以做到SPA和MPA在构建层做不同定制。目前Umi SSR、Ice SSR、Egg-react-ssr都是基于这套机制构建的，整体上看，这个方案是得到大家一致认可的。在FaaS SSR里，会有更加极简的用法，在降低开发难度上会进一步压榨，期望能够达到落地成本减半的目标。

在2020年，基于FaaS之上的渲染已经获得大家的认可。另外大量的Node.js的BFF（Backend for frontend）应用已经到了需要治理的时候，BFF感觉和当年的微服务一样，太多了之后就会牵扯到管理成本，这种情况下Serverless是个中台内敛的极好解决方案。对前端来说，SSR让开发变得简单，基于FaaS又能很好的收敛和治理BFF应用，结合WebIDE，一种极其轻量级基于Serverless的前端研发时代已经来临了。省了流程，少了运维，以后可以招人能降低，甚至外包，如果想做，后端的事儿也是能够完成的，可以消掉前后端开发的开发分工。

自建 SFF 管理后台会流行

针对于FaaS，前端能有的玩法。

• 函数管理，为ginkgo自带功能，可以略微扩展，比如自定义网关集成中的path，url rewrite。
• 通用模板支持，由于场景不一样，所以会提供serve，rpc/http，ssr，mock等多种类型的模板，对于开发者更加友好。
• 对外服务注册。主要是来自服务市场的概念，很多函数如果想对外提供通用服务，通过设置，可以变为对外公共服务，可以变成其他函数的依赖，并在layer中可以按需注入。
• 快速场景定制，让开发者感觉不到函数的存在，比如mock个json，那就直接输入json和想访问的地址，然后自动创建函数，发布，访问就好。
• 业务支持，基于以上4种细化的方案，做业务相关的开发。

当然，模式上也要考虑，比如c端和b端是不一样的，主要差别在流量上（基建还不够智能导致的）。一个典型的场景，在对内的bff里，10个函数部署在一台机器上会更划算，这时候除了樵枫大大的 EaaS（egg as a service：一个是机器成本的考虑，另一个是存量的大量Egg应用更平滑迁移到Serverless体系）这种Layer层面的定制外，能够在平台侧提供聚合并发布的能力也是非常务实的功能。

讲完FaaS玩法，你会发现所有的功能需要定制的还是非常多的，此时自建SFF管理后台是非常必要的。

• 定制性更好，各个BU业务和研发习惯模式等都有不同
• 基于集团的Serverless基建，不需要考虑运维问题，有问题还是可以提需求
• 便于创新，目前基建已经提供了足够的支持，让开发更专注于开发

Serverless是风口，提效是有的，但业务价值没有根本改变，所以围绕开发者提效和创新才是核心。各个BU不去定制才是奇怪的事儿。

接下来大家发力的点，可能是下面这些。

• 围绕网关做好稳定性，平台基石

• 将Serverless做成托管容器，让页面托管/api托管更容易，目前看全场景落地没问题的

  • 内部bff应用，需要考虑流量问题，多函数一台机器是强诉求，樵枫那边的eaas，另外多函数如何compose成一个，类似于koa-compose这种，也是一个方向
  • ssr和csr现有方案足够，ice和umi都采用是这套
  • 对于c端页面，自建网关，在Faas函数挂掉的情况下，可以降级到CDN托管
  • 关于函数的ctx，早晚还是要回归到koa上，需求都上来，还是要通用，不然无法满足，所有bff场景出现的问题都一定会在faas上出现。插件化也是faas的强诉求。
• 服务市场，现在实际已经成熟了。服务和路由要分开处理，让沉淀服务变得更容易。
• 让前端感知不到函数的存在，ui化，可视化，集成现在有的前端方案，做好生态

前端工作台

前面讲了，now.sh或surge.sh，linc.sh这些在易用性上做的实践是非常值得借鉴的。这些所谓的易用性上的实践集合在一起，你需要的其实就是前端工作台。

Backstage is an open platform for building developer portals

https://github.com/spotify/backstage

理想么？developer portals，不是frontend developer portals。这才是最重要的。

Backstagez已经在Spotify创建4年了。开源版本3个阶段：
We created Backstage about 4 years ago. While our internal version of Backstage has had the benefit of time to mature and evolve, the first iteration of our open source version is still nascent. We are envisioning three phases of the project and we have already begun work on various aspects of these phases:

• 阶段1: 扩展前端平台 (正在做) - 让你能够简单的为你的内部基建或工具创建一个一个单一的持久化UI层。可复用的UX模式和组件集有助于在工具之间保证一致的体验。
• 阶段2: 员工管理 (next 2-3 months) - Manage anything from microservices to software components to infrastructure and your service catalog. Regardless of whether you want to create a new library, view service deployment status in Kubernetes, or check the test coverage for a website -- Backstage will provide all of those tools - and many more - in a single developer portal.
• 阶段3: 生态 (later) - Everyone's infrastructure stack is different. By fostering a vibrant community of contributors we hope to provide an ecosystem of Open

https://github.com/spotify/backstage/blob/master/docs/getting-started/create-an-app.md

app
├── README.md
├── lerna.json
├── package.json
├── prettier.config.js
├── tsconfig.json
├── packages
│   └── app
│       ├── package.json
│       ├── tsconfig.json
│       ├── public
│       │   └──  ...
│       └── src
│           ├── App.test.tsx
│           ├── App.tsx
│           ├── index.tsx
│           ├── plugins.ts
│           └── setupTests.ts
└── plugins
    └── welcome
        ├── README.md
        ├── package.json
        ├── tsconfig.json
        └── src
            ├── index.ts
            ├── plugin.test.ts
            ├── plugin.ts
            ├── setupTests.ts
            └── components
                ├── Timer
                │   └──  ...
                └── WelcomePage
                    └──  ...

目前能看到的是大型应用插件化，具体和portal做的集成度有多高，还没有简单。

前端工作台：集前端现有功能，构建好用的前端门户。核心技术应该是：微前端 + JAMS + 搭建。

• JAMS：基建，当下最潮的解决方案
• 微前端：在工作台构建上拥有绝对重要性。Web 技术发展到今天，已经有大量存在时间数年乃至十年以上的巨石应用出现，技术的迭代往往导致技术债过高，拖累研发效率，贸然追进最新技术栈又会导致技术税的缴纳。微前端的出现给了这些项目一个进化和保持不进化的可能性。在 SPA 这一政治正确的技术方案外打开了一个新领域，也在这个领域相应开源了 qiankun 和 icestark 等项目。
• 搭建：最容易落地的提效手段
• 智能化：imgcook从d2c，到数据绑定，到p2c，能做的事儿其实也是为搭建服务的。未来可以想象的空间很大，是创新，结合搭建最容易落地，但不是必选项。

总结

FaaS场景下的SSR框架已经添加到阿里云云开发平台的默认解决方案当中。结合阿里云的CloudIDE功能，我们可以所有的开发，发布操作都在云上完成无需本地配置开发环境，使用起来十分的方便。

我姑且说之，你姑且听之。如果说某些观点能够有点启发，一起交流。对于未知的探索，需要有更多人一起来。

最后，分享一首我非常喜欢的舒婷《献给我的同代人》，共勉。

他们在天上
愿为一颗星
他们在地上
愿为一盏灯
不怕显得多么渺小
只要尽其可能
唯因不被承认
才格外勇敢真诚
即使像眼泪一样跌碎
敏感的大地
处处仍有
持久而悠远的回声
为开拓心灵的处女地
走入禁区，也许——
就在那里牺牲
留下歪歪斜斜的脚印
给后来者
签署通行证
1980.4

文末福利

玩转云端开发 7 天训练营

提前享受云时代的原生开发环境，Serverless 研发从入门到精通，连续 7 天，每天一个直播，阿里专家手把手教你利用阿里云云开发平台 get 云端开发新技能。0 门槛打开浏览器就可以开发，最快 1 分钟搭建个人网站，免费开发还送代金券、天猫精灵等多重好礼！

识别下方二维码马上入群学习，或点击链接马上参加：

等等，福利还没停！关注下方公众号转发文章即参与抽取天猫精灵！

关注「Alibaba F2E」
把握阿里巴巴前端新动向