Serverless 背景下，一部分“前端工程师”会转变为“应用交付工程师”

「2022 年什么会火？什么该学？本文正在参与“聊聊 2022 技术趋势”征文活动 」

大家好，我是杨成功。

这是我的 2022 年第一篇文章。一直在想写些什么比较好，既然是新年，新年新气象，写点技术展望的想法是不是更合适？于是这篇文章的标题，也就是本文的核心思想出来了：

Serverless 背景下，一部分“前端工程师”会转变为“应用交付工程师”

这里有三个名词：

• Serverless
• 前端工程师
• 应用交付工程师

下面就从这三个方面，聊一下我对 2022 前端的展望。

Serverless

什么是 Serverless？

单从意思理解，非常明显，就是很少的服务。

我觉得这个理解就很好。因为现在大家对 Serverless 的翻译是 无服务，真正无服务吗？也不是，我们先来看一下它的具体概念：

【Red Hat】Serverless 是一种云原生开发模型，可使开发人员专注构建和运行应用，而无需管理服务器。

听不懂？大白话翻译一下。就是说以前的服务啊，比如说我们前端要对接的接口应用，它们是要部署在 服务器上 的。后端同学要开发一套接口，首先得申请一台服务器，然后将应用部署到这个服务器上，用域名解析一下，才能给到前端接口 URL 地址，供前端调用。

但是 Serverless 出现以后，即便没有服务器，不懂运维，在线上部署应用也成为了可能。

关键点就在：没有服务器，也能部署应用。

那怎么部署呢？先看一下 Serverless 的两种形式：

• BaaS：全称 Backend as a Service，译为后端即服务。
• FaaS：全称 Function as a Service，译为函数即服务。

BaaS 是指一个服务端应用，也叫云应用。举个例子，我们常用的阿里云的云数据库，对象存储，都属于 BaaS。事实上不管是数据库还是静态资源存储，我们完全可以自己在服务器上搭建。但是因为有了像 云数据库 这类的产品，我们可以绕过服务器，直接使用一个云端的数据库。

这就是 “无服务” 的第一层概念：淡化服务器，直接接触服务端应用。

注意：这里是淡化服务器，并不是真正的没有服务器。只不过是云厂商已经将服务器进行了抽象封装，暴露给开发人员的直接是应用，因此对开发人员来说好像是无服务。

BaaS 最广泛的应用在后端，因为后端好多基础设施（如数据库，日志等）不用手动搭建了，有云厂商标准稳定的支持，可以把精力集中到业务逻辑上。

但是随着前端的快速发展，以及后端的云原生化，有些奇思妙想的大佬就这么想了：“前端调用后端接口，都是在前端的一个函数中发起请求，这样的话就必然需要后端提供一个接口服务。那我们是不是可以这样，直接将这个函数部署在云上，变成云函数，供前端直接用，是不是就不需要后端的接口了？”

大佬一拍大腿，这想法竟然如此绝妙。这么干的话，前端岂不是要翻身农奴把歌唱？于是大佬们将 server 继续 less，于是 FaaS 就出现了。

FaaS 是一种面向函数的构建和部署软件的方式，也就是云函数。FaaS 是对 BaaS 的又一次升级，在淡化服务器的基础上，又淡化了应用，直接向前端暴露函数。以前我们前端的函数都是本地声明，本地调用。现在云函数是单独部署在云上，供我们前端远程调用。

这是 “无服务” 的第二层概念：淡化服务器，淡化应用，直接接触函数。

事实上，Serverless 在发展到 FaaS 阶段，才真正对前端产生了变革式的影响。

前端工程师

什么是前端工程师？

早年的前端工程师更像是“页面工程师”，绝大部分人的工作就是用“三驾马车”将设计图做成一张网页，直到现在还有很多后端开发对前端的印象就是如此。

但是近几年大家发现，前端工程师仿佛一直在“外卷”，不断的拓展边界。虽然还是顶着“前端工程师”的帽子，但是干的事情早已经超出了传统前端范畴。

从”拓展边界“这个事情来说，大致分两个方向：

• 向前：往产品和设计靠
• 向后：往后端和运维靠

向前表现为，一部分前端开始对自己做的东西，会更多的思考“为什么”？

以前是产品确定到设计出图，前端只需要还原设计图就好了。理想如此，但实际情况是有些地方产品和设计考虑不到，等落实到前端这才发现不可行，于是呢就只能“改需求”或“推倒重来”，这是前端最反感的事情。

这种情况一多，就会倒逼前端们不得不思考：这个页面设计合不合理？交互方面有没有问题？ 如果有问题，那这个需求我们就不接，产品先回去捋清楚了再说。这样大大减少了前端的无用功，提升了开发效率，也渐渐培养了前端的产品思维。

除了产品思维，前端也在思考，如何在设计层面让“图”变成“代码”更容易。于是近年来出现了很多设计图转代码的方案，比如蓝湖，还有阿里的 imgcook。这些实践方案让一个应用从设计之初，就有了前端的影子。

而向后发展的表现，典型是 Node.js 出现以后，以 Express 为代表的超轻量框架，因为相对简单又是 JS 语言，因此在前端圈掀起了一股 “全栈开发” 的热潮。这不是没有原因的，有些小应用就是适合用 Node.js 写，速度快效率高用过都说好。

但是在一些大型生产应用上，前端就够不着了。特别是云原生出现以后，后端的门槛蹭蹭的上来了。我相信有很多优秀的前端工程师，用 Node.js 接个数据库，写一些业务逻辑的接口，完全没有问题。但是如果让你搞一些后端的高级玩法，做一些服务器运维的事情，你可能就整不来了。

哪些算高级？之前在网上看到对后端大佬的描述挺有意思，是这么说的：左手高并发，右手高可用，头顶中间件，脚踩微服务，怀抱云原生，这就是大佬的全套战甲。

所以你看看，后端围墙高筑，把妄图横插一脚的前端挡在了门外。至此后端深耕，前端也在不断的尝试中找到了自己的方向，大家各自干各自领域的事情，互不纠缠。

但是 Serverless 特别是 FaaS 出现以后，这个平衡开始出现了微妙的变化。

应用交付工程师

什么是“应用交付工程师”？

首先声明一点，这个不是官方概念，是我在思考前端向后发展时萌生的。

我们上面说了，传统前端工程师的职责，就是把设计图做成网页，但随着 Node.js 出现，前端开始有更多的机会接触到后端。对于某些小应用，一部分优秀的前端可以靠自己完成前端和接口，然后上线，不需要后端参与。

这部分人我们可以称作是“全栈工程师”。所谓的全栈要么是一端深一端浅，要么是两端都浅（当然超级大牛忽略），所以开发小应用可以，大型生产应用就没全栈什么事了。

而现在随着 Serverless 云函数横空出世，屏蔽了服务器和后端应用的部分，使后端开发门槛大幅降低。前端仿佛又看到了希望，我们可以不用写接口，只需要编写云函数，也能实现生产应用的后端开发。

以前有高墙，前端卷不进来。现在墙拆了，你说我们进不进？

典型的例子是微信小程序云开发。前端在微信开发者工具上编写云函数，一键上传与部署。然后在小程序代码中获取并调用这个远程函数，相当于整个流程前后端都是自己实现自己调试，直到应用开发完成。这就是一个典型的“前端工程师”转变“应用交付工程师”的例子。

使用 Serverless 云函数不光能轻松实现后端的业务功能，而且监控，并发，负载这些由云厂商统一实现，一应俱全。因此在稳定性可靠性上也非常有保障。

还有一点，目前可能是大家的观念问题，认为单独的云函数服务需要自己付费，还不如自己直接在云服务器上部署应用。事实上函数计算是按照调用次数，访问流量计费的，比云服务器要更节约资源更省钱。

这个观念我认为 2022 年会在大厂推动下逐步放开，越来越多的 web 应用也会接入 serverless，因此更多的前端开发工程师会转变为应用交付工程师。

以前前端要实现一些自己的想法，必须要有后端的接口配合，而且还需要后端或运维帮忙在线上部署。但是现在不用了，我们有机会自己搞定这一切。我觉得这对前端来说是巨大的机会，一个可以将产品和自己的想法，直接产出一个应用的好机会。

除此之外，前端的协作模式可能也会发生变化。以前的一个大应用，前端组是分模块开发。但是现在有了 serverless，再加上去年已经逐步成熟的微前端，前端协作模式很可能由 “一个模块一个模块开发” 变成 “一个应用一个应用开发”，这是一件非常酷的事情。

还有向前拓展时培养的产品思维，前端未来可能是最了解整个应用的人，所以前景不必多说。

加油吧，前端人们！2022 祝大家升职加薪，再攀高峰！

我想学更多

为了更好的保护原创，本文会首发微信公众号 前端砍柴人。这个公众号只做原创，每周至少一篇高质量文章，方向是前端工程与架构等实践与思考。

除此之外，我还建了一个微信群，专门提供对这个方向感兴趣的同学交流与学习。如果你也感兴趣，欢迎加我微信 ruidoc 拉你入群～