共计 3406 个字符，预计需要花费 9 分钟才能阅读完成。
大家好，我是杨胜利。
这是我的 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 拉你入群～
