收益 or 挑战？Serverless 究竟给前端带来了什么

如果后端搭建一个特有的 Serverless BaaS 服务，那么就可以像前端组件一样进行线上 Coding、调试，甚至灰度发布进行预发测试。现在前端云端开发已经有了不少成熟的探索，Serverless 可以统一前后端代码在云端开发的体验，而不需要关心环境。

Serverless 应用架构设计

看了一些 Serverless 应用架构图，发现大部分业务都可以套用这样一张架构图：

将业务函数抽象成一个个 FaaS 函数，将数据库、缓存、加速等服务抽象成 BaaS 服务;

上层提供 Restful 或事件触发机制调用，对应到不同的端(PC、移动端);

想要拓展平台能力，只要在端上做开放(组件接入)与 FaaS 服务做开放(后端接入)即可。

收益与挑战

Serverless 带来的收益与挑战并存，本文站在前端角度聊一聊。

收益一：前端更 Focus 在前端体验技术，而不需要具备太多应用管理知识。

最近看了很多前端前辈写的总结文，最大的体会就是回忆 “前端在这几年到底起到了什么作用”。我们往往会夸大自己的存在感，其实前端存在的意义就是解决人机交互问题，大部分场景下，都是一种锦上添花的作用，而不是必须。

回忆你最自豪的工作经历，可能是掌握了 Node 应用的运维知识、前端工程体系建设、研发效能优化、标准规范制定等，但真正对业务起效的部分，恰恰是你觉得写得最不值得一提的业务代码。前端花了太多的时间在周边技术上，而减少了很多对业务、交互的思考。

即便是大公司，也难以招到既熟练使用 Nodejs，又具备丰富运维知识的人，同时还要求他前端技术精湛，对业务理解深刻，鱼和熊掌几乎不可兼得。

Serverless 可以有效解决这个问题，前端同学只需要会写 JS 代码而无需掌握任何运维知识，就可以快速实现自己的整套想法。

诚然，了解服务端知识是有必要的，但站在合理分工的角度，前端就应该 focus 在前端技术上。前端的核心竞争力或者带来的业务价值，并不会随着了解多一些运维知识而得到补充，相反，这会吞噬掉我们本可以带来更多业务价值的时间。

语言的进化、浏览器的进化、服务器的进化，都是从复杂到简单，底层到封装的过程，而 Serverless 是后端 + 运维作为一个整体的进一步封装的过程。

收益二：逻辑编排带来的代码高度复用、可维护，拓展 云+端 的能力。

云+端 是前端开发的下个形态，提供强大的云编码能力，或者通过插件将端打造为类似云的开发环境。其最大好处就是屏蔽前端开发环境细节，理念与 Serverless 类似。

之前有不少团队尝试过利用 GraphQL 让接口 “更有弹性”，而 Serverless 则是更彻底的方案。

我自己的团队就尝试过 GraphQL 方案，但由于业务非常复杂，难以用标准的模型描述所有场景的需求，因此不适合使用 GraphQL。恰恰是一套基于 Blockly 的可视化后端开发平台坚持了下来，而且取得了惊人的开发提效。这套 Blockly 通用化抽象后几乎可以由 Serverless 来代替。所以 Serverless 可以解决复杂场景下后端研发提效的问题。

Serverless 在融合了云端开发后，就可以通过逻辑编排进一步可视化调整函数执行顺序、依赖关系。

（编辑：宁德站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!