关于Serverless 未来对前端开发影响的具体看法

本文涉及的产品
函数计算FC,每月15万CU 3个月
Serverless 应用引擎免费试用套餐包,4320000 CU,有效期3个月
简介: 介绍Serverless发展趋势,以及未来对前端开发工程师的影响

早在两三年前Serverless在国内兴起的时候就有人再说 Serverless 对前端开发是个巨大的机遇,主要原因是Serverless 承载了很多专业的后端能力,能够让前端开发的职能向真正的全栈进发不必担心无法应对诸如大规模并发,高可用容灾,安全等复杂的后端问题,另外还有说是在开发效率上会给前端带来巨大的提升,可以把省下来的开发时间多陪陪家人。当然效率这个东西总归是无法太打动我,我是不相信效率提升之后我们的活就会少的,不过对于职能提升这点倒是值得探讨研究一下,另外就是Serverless 可能带来的一些研发模式的改变也是需要每一位从业者注意的。

全栈的趋势

来自 《stackoverflow developer survey 2021》 的一组数据,66848个样本。可以看到全球目前的主流开发者是全栈工程师,占了近乎一半,可以看到一个趋势,工程师的能力更多的在往全栈方向发展,所以如果如果只是做纯前端工程师的话竞争优势是偏弱的。

image.png

从开发语言上全球最多的是javascript, 83052个样本,这个语言虽然广受诟病,但不妨碍他的确是覆盖应用开发面最广的语言,对前端开发而言这是一个优势,另外js在serverless 支持上也是跟python 有着同样优秀冷启动时间的语言。

image.png

这里之所以提全栈这个趋势,其实是想表达一个观点--作为前端工程师想要进阶的话 全栈是一个很好的选择,当然前端本身跨端部分,以及垂直的可视化领域, 工程化开发领域其实也都是不错的选择,只不过从需求侧来说的话全栈的市场机会会更大些。


Serverless 带来的改变

Serverless 目前已经开始已不可阻挡的态势向IT研发领域进击了,目前面向前端群体的改变点主要是在走在技术前沿的大厂,比如阿里,字节,腾讯等公司,他们首先在自己的业务落地,并且取得了不错的成绩。

但更多的普通开发者没有感知到,甚至很多同学觉得Serverless 在前端研发这块已经没落了,当然原因也很简单,最主要的是跟自己业务场景相去甚远,找不到可以结合的点,所以没有兴趣关注。这里面有一个主要的问题,Serverless其实是后端的技术很多研发的精干力量都是专业的后端工程师,解决调度,冷启动,容灾,成本等问题。

跟前端八竿子打不着,他们就相当于造武器的那批人,但真正使用武器的人由于缺少培训,实战场景和操作工具链,导致无法用起来。当然国内大厂其实都已经开始布局工具链和实战培训了不过依然需要一段时间才能在大众形成工时,关于这点我们稍后再说,我们先来看看前沿的Serverless技术在前端领域的应用场景是怎么样的。

端侧开发的改变

如果你是从事 前端页面,移动端 android,ios 以及 hybird应用如flutter,react native  开发的,可以关注这部分的内容。

image.png

这里是当前的端侧/服务侧开发模式, 端侧工程师做UI交互,然后调用服务端开发提供的接口。这种模式大家分工更明确各司其职,对于较大规模的产品而言比较适合,但对初创或者个人创意开发而言成本更高。 引入Serverless的模式后通用BAAS服务的部分工程师通过配置云商的服务自动完成,需要特殊业务处理的话则通过写function 来满足,另外就是端侧的SDK 会内置跟这些业务服务的联通,换句话说就是只需几行客户端代码即可连接到新的和现有云上 资源。


image.png


已知一些产品像 hasura,aws amplify 都在开始做端到云直接关联。进一步简化开发的步骤,降低端侧研发成本。

image.png


所以从开发应用的角度而言,理论上可以由全栈工程师承担所有的开发任务,服务侧通用的能力配置即可生成调用服务,端侧通过SDK集成直接访问服务,如果有特殊业务逻辑就开发FAAS 完成,这种模式对于个人开发者或者初创项目而言有着非常大的成本节省优势。从长远看由于成本优势,效率优势,这种模式最终会成为主流,不管是哪一端的开发,都要做好相应的转型准备。


WebApp开发的改变

如果你是主要从事web应用开发的可以关注这部分,随着Serverless 的发展,传统的网站开发方式也在发生改变,站点的研发向着高质量低成本的方向发展。

jamstack 的架构是比较理想的一个建站模型


image.png

Jamstack (javascript, api,markup)本身的优势已经非常突出,包括更安全,SEO访问更友好,扩展性更强等等,再加上其跟Faas 结合有着天然的优势,更进一步促成了这套技术栈在未来会有着更广阔的前景。如果你还没有彻底清楚Jamstack是什么,跟Serverless 结合点在哪里,不妨可以试着安装阿里云提供 Serverless Devs 开发者工具

npm install -g @serverless-devs/s

并且通过初始化我们的应用模板来获得Jamstack应用,并且深刻体验一下效果

s init docsite-basic

更多介绍jamstack 开发应用的文章请持续关注我们 ServerlessDevs,后续我也会继续给大家做更详细的介绍。

应用架构设计

这个是随着Serverless以及事件驱动研发模式到来衍生出来的一个更加高级的角色,也是前端开发同学可以关注的未来角色之一。

随着云计算市场的不断增加,未来会有越来越多的应用部署到云上,使用云的资源。云资源被标准化定义,相同的云资源可以用固定的方法获取使用,云资源会真正像水电煤一样被使用,正是基于这种畅想 出现了基础设施即代码的一类产品,比如 pulumi,比如 terrform。目的是为了让开发人员更加灵活的用云集成到自己的业务体系。当然本篇章不是为了讲Ias。基础设施即代码更加偏向于底层服务,对于一个要求快速上线的业务而言,代价就比较大了。所以我们站在云产品的维度去看,未来的应用服务将大部分基于云厂商的云产品构建,比如我想做一个Serverless 版的LAMP(linux,apache,mysql,php) 需要用到 CDN,网关, php的函数运行时服务,对象存储服务,数据库服务等等,然后组合起来如下


image.png

我们可以想像自己是在搭积木,每一个需要用到的云资源以及代表这个资源的云产品是一个标准模块,只需要知道这个模块的OpenApi 我们就能够有效的调用并拼接起来,落地到业务场景中去。你也许会问,云商的Api 抽象级别往往比较低,意味着需要大量的开发工作才能满足应用开发的需求。这样低效的方式难以成为主流。为了解决云产品OpenApi抽象过低的问题,我们通过组件化的方式对云产品进行了更高层次的抽象,比如对OTS数据库 的调用我们可以简化到通过几个配置项即可完成,并通过开发者工具进行云资源的配置和调用分发,我们就以 改进传统LAMP架构为例,看一下如何对这类架构进行组件拆分和配置描述

edition: 1.0.0name: jamstack-websiteaccess: defaultvars:
apiSourceCode: apidomain: serverlessdevs.resume.net.cnreleaseCode: website# 最终构建的代码包services:
fc:
component: fcactions:
pre-deploy:
-run: npminstallpath: ./functionsprops:
region: cn-hangzhouruntime: phpserviceName: hanxietest2funName: register2version: LATESTsourceCode: functionsapigateway:
component: apigatewatprops:
groupName: hanxietestapis: 
-basePath: /path: /api1method: getinputParams:
-name: docIdposition: Querytype: stringdefault: sdesc: 
-name: userIdposition: Querytype: stringdefault: sdesc: 
backendServerConfig: ${fc1.output}
backendParams:
-name: idposition: QueryinputName: docIdcdn:
component: jamstackprops:
domain: ${vars.domain}
favicon: falsedefaultApp: frontendapps:
-name: frontendtype: jamstackreleaseCode: ${vars.releaseCode}
paths:
-/indexFile: index.htmlpage404Url: 404.html-name: apistype: backendpaths:
-/~apisproxyUrl: ${apigateway.output.url}

以上是使用ServerlessDevs 的配置做的伪代码展示。借此阐述我们会通过组件的方式 将云资源进行高纬度的抽象,简化对接云资源的落地实施成本。云资源组件化积木化之后更好的进行应用的组合拆分,这时候需要应用架构师的角色,对这套体系了解清楚,构建更加健壮扩展能力更强的应用,并且帮助公司节省更多成本。

文末总结

以上是笔者长期从事前端云业务开发得出来的一些趋势判断,未必都准确,但可以作为广大从事前端开发的一些参考。可以肯定的是Serverless 作为未来新的云资源使用范式会不断的成长壮大并影响到每一个从业者。当然必须承认的是国内相关的生态还远未成熟,应用的落地推广依然会有非常大的挑战,但我相信有积极先进意识的同行一定不会错过这个机会,应难而上占得先机。

最后如果你觉得本文有帮助的话,不妨为我们的开源Serverless 开发者工具ServerlessDevs(项目地址https://github.com/Serverless-Devs/Serverless-Devs)去点个star


相关实践学习
【文生图】一键部署Stable Diffusion基于函数计算
本实验教你如何在函数计算FC上从零开始部署Stable Diffusion来进行AI绘画创作,开启AIGC盲盒。函数计算提供一定的免费额度供用户使用。本实验答疑钉钉群:29290019867
建立 Serverless 思维
本课程包括: Serverless 应用引擎的概念, 为开发者带来的实际价值, 以及让您了解常见的 Serverless 架构模式
目录
相关文章
|
2月前
|
缓存 前端开发 JavaScript
前端serverless探索之组件单独部署时,利用rxjs实现业务状态与vue-react-angular等框架的响应式状态映射
本文深入探讨了如何将RxJS与Vue、React、Angular三大前端框架进行集成,通过抽象出辅助方法`useRx`和`pushPipe`,实现跨框架的状态管理。具体介绍了各框架的响应式机制,展示了如何将RxJS的Observable对象转化为框架的响应式数据,并通过示例代码演示了使用方法。此外,还讨论了全局状态源与WebComponent的部署优化,以及一些实践中的改进点。这些方法不仅简化了异步编程,还提升了代码的可读性和可维护性。
|
2月前
|
JavaScript 前端开发 Serverless
前端全栈之路Deno篇:Deno2.0与Bun对比,谁更胜一筹?可能Deno目前更适合serverless业务
在前端全栈开发中,Deno 2.0 和 Bun 作为新兴的 JavaScript 运行时,各自展现了不同的优势。Deno 2.0 重视安全性和多平台兼容性,尤其是对 Windows 的良好支持和原生 TypeScript 支持;而 Bun 则以卓越的性能和简便的开发体验著称,适合快速迭代的小型项目。两者在不同场景下各具特色,Deno 更适合企业级应用和serverless,Bun 则适用于追求速度的项目。
193 1
|
6月前
|
缓存 前端开发 jenkins
Serverless 应用引擎产品使用合集之前端的项目部署在镜像里时,页面总是自动刷新,是什么导致的
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。
|
2月前
|
缓存 前端开发 Serverless
前端技术新趋势:从PWA到Serverless架构
【10月更文挑战第1天】前端技术新趋势:从PWA到Serverless架构
54 3
|
4月前
|
前端开发 安全 Serverless
中后台前端开发问题之云服务商在Serverless与低代码融合如何解决
中后台前端开发问题之云服务商在Serverless与低代码融合如何解决
37 0
|
7月前
|
前端开发 JavaScript 小程序
亚马逊云科技 Build On -Serverless低代码平台初体验-快速完成vue前端订单小程序
亚马逊云科技 Build On -Serverless低代码平台初体验-快速完成vue前端订单小程序
92 0
|
移动开发 缓存 监控
基于 Serverless 的大前端轻研发平台
基于 Serverless 的大前端轻研发平台
249 0
|
前端开发 Serverless
Serverless 服务中的前端解决方案——总结
Serverless 服务中的前端解决方案——总结自制脑图
123 0
Serverless 服务中的前端解决方案——总结
|
前端开发 Serverless
Serverless 服务中的前端解决方案——给函数预热
Serverless 服务中的前端解决方案——给函数预热自制脑图
154 0
Serverless 服务中的前端解决方案——给函数预热
|
前端开发 Serverless
Serverless 服务中的前端解决方案——执行上下文重用
Serverless 服务中的前端解决方案——执行上下文重用自制脑图
99 0
Serverless 服务中的前端解决方案——执行上下文重用

热门文章

最新文章

相关产品

  • 函数计算