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

全栈的趋势

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

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

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

Serverless 带来的改变

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

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

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

端侧开发的改变

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

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

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

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

WebApp开发的改变

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

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

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的函数运行时服务，对象存储服务，数据库服务等等，然后组合起来如下

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

edition: 1.0.0
name: jamstack-website
access: default
vars:
  apiSourceCode: api
  domain: serverlessdevs.resume.net.cn
  releaseCode: website # 最终构建的代码包
services:
  fc:
    component: fc
    actions:
      pre-deploy:
        - run: npm install
          path: ./functions
    props:
      region: cn-hangzhou
      runtime: php
      serviceName: hanxietest2
      funName: register2
      version: LATEST
      sourceCode: functions
  apigateway:
    component: apigatewat
    props:
      groupName: hanxietest
      apis: 
        - basePath: /
          path: /api1
          method: get
          inputParams:
            - name: docId
              position: Query
              type: string
              default: s
              desc: 
            - name: userId
              position: Query
              type: string
              default: s
              desc: 
          backendServerConfig: ${fc1.output}
          backendParams:
            - name: id
              position: Query
              inputName: docId  
  cdn:
    component: jamstack
    props:
      domain: ${vars.domain}
      favicon: false
      defaultApp: frontend
      apps:
        - name: frontend
          type: jamstack
          releaseCode: ${vars.releaseCode}
          paths:
            - /
          indexFile: index.html
          page404Url: 404.html
        - name: apis  
          type: backend
          paths:
            - /~apis
          proxyUrl: ${apigateway.output.url}

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

文末总结

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

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