从前端到全栈开发的技术迭代升级,从前端技术演进看前端发展野心、同时满足技术需求和商业需求的前端全栈、打破物理隔离,实现真全栈、小程序云服务的发展优化、 从前端开发到全栈开发等五个方面具体来看看。
从两个维度去分析前端的技术发展,一个维度是前端复杂度,具体来讲就是前端在解决创建应用复杂度方面做的一些事情;另一个是从广度层面看前端做的事情, 这两个维度构成了一个类似于二维平面的时间事件平面。
单看复杂度,前端最开始的阶段只有HTML、JS、CSS,应用虽然是非常简单的,开发起来却是非常复杂的,因此,单单只是DOM操作方面就有大量的DOM操作API。为了降低操作成本,就出现了DOM操作框架,比如jquery。这个阶段类似于从原始的刀耕火种进入石器时代。对dom的操作带来了很大的便利性。尽管如此,真正在构建一个复杂应用的时候,因为业务逻辑和手动操作dom逻辑交织在一起,应用维护变得越来越难。
下一个阶段,引入了MVC分层思想,比如backbone,这能够将逻辑梳理的更加清晰一些。不过,MVC还是需要去关注视图层的。
接着,就出现了mvvm框架,开发者不需要再关注视图层的更新,只需要关注逻辑层、数据层。这一点为构建复杂大型app提供了极大的便利性。mvvm从Angular到现在react、vue的广泛应用,前端在逻辑构建层面发展已经到了一个新的阶段。在构建大型应用的时候,仅有逻辑层是不行的,还缺乏工程性的思想。因此,出现了打包的模式,帮助我们构建更复杂的应用。这样我们所能做的APP复杂度是一个指数型的增长。
为了进一步提高可构建应用的复杂度、增强前端的性能,assembly技术标准出现,提供了前端字节码的标准,为创建更加复杂的应用打好了坚实的基础。
2、 一直在扩展的前端广度
刚开始只能在浏览器上运行,后来有了node代码,可以让我们的代码扩展到服务器端。紧接着PC端有electron。再到移动端有RN框架,支持我们向移动端进展。现在出现了小程序,小程序框架能够让前端继续在移动端轻应用做探索。这里没有讲到的嵌入式开发,这方面也有相应的解决方案。前端不断扩展广度,把前面的边界不断扩大。最终前端想一统天下,把前端全栈化。
二、 同时满足技术需求和商业需求的前端全栈
所有的技术在发展时期都有两条线去支撑着它发展,一条线是技术需求,即技术层面的技术创意和技术诉求;另外一条线是商业需求,即技术要满足对应的商业诉求。
那么,如果仅有商业需求又会出现怎样的情况呢?比如,2000年的时候对AI有商业上的需求,但是技术需求并满足,当时AI就是一个要被搁置的东西。前端全栈,是怎样在满足技术需求的同时满足商业需求的呢?
我们回归到移动端APP的开发实际场景,只有两个层面:一个是UI交互界面的开发,这个是可以被用户感知到的,另外一个是用户感受不到的服务逻辑层面。如果来看现有的开发模式,单单从UI交互界面上来看,就有不同的平台端android、ios、h5,对应的语言有Java、OC、swift、js等几种语言,后端的语言和技术实现是更多的。在现在的模式下,一个小型公司如果需要开发一个完整的APP项目,就需要六种技术!
由此可见,前端全栈既满足技术需求,也满足商业需求的,所以我相信未来前端全栈一定会蓬勃发展。
三、 打破物理隔离,实现真全栈
再回过头看前端散落的各种技术,在这个发展的过程中,有一个很深的隔离,这个隔离本质上就是物理隔离,比如前端和后端,存在手机和服务器之间的物理隔离。
Serverless中的FaaS,函数即服务,我在使用后端服务的时候,不再关心后端的ip地址,后端的域名是什么样的,直接调用函数即可,对前端来说,后端服务是一个函数,函数就是前端的代码的一部分,后端服务和前端完全的融合在一种代码体系里去了,这样后端的服务即是一个函数,至于这个函数是在前端实现,或者是在后端很远的地方实现,开发者都可以不用关心。所以说,severless打破了物理隔离。开发者不再去做任何隔离中间层的事前,我只需要关心函数的实现就可以了,函数也是用我的前端代码来写,所以达到了充分融合的定义。
回过来看具体的实现场景,比如云开发,整个小程序的前后端逻辑都能在一个IDE里面完成,用户其实完全不用担心哪些是服务器的逻辑,他们都去向了哪里,只需要像前端函数一样去理解就可以了。云函数现在也支持了本地调试,就像前端代码一样调试,所以可以做真正的前端全栈技术开发,这对现有的开发模式是一个很大的革新。
四、 小程序云服务的发展优化
那么,在大前端技术发展的这波浪潮里面,小程序云服务又有什么样的发展呢?早在2017年初小程序正式发布的时候,第一代腾讯云小程序云服务就已经诞生了,但随着8月份全面向个人开发者开放,我们发现这套支服务还是有一定门槛的。于是就开始着手去做更深度的云服务整合和优化,才有了后来的wafer2 和现在的云开发。
通过整个优化,可以简略成四步。第一步是通过一键的配置购买就能把云开发产品开通起来,第二步是工程师进行小程序的前后台开发,第三步进行代码的预览上传,测试体验完,最后便是发布。经过我们这一两年的努力,小程序开发的流程已经由十几步简化到四步了。目前如果从市面上来看,我们这个产品在用户体验以及流程简化度上,在行业内是较为领先的。
那么,我们腾讯云团队和微信团队如何一步一步优化我们的产品,将产品的接入门槛降低、流程变简的呢?
剩下还可以优化的就只有 SDK 引入和填写配置的环节了。
SDK 其实可以采用内置的方式,毕竟小程序的前端接口也是直接内置到运行环境的 webview里面的。但是配置这块并不太好做了。因为一直以来,小程序前端和后台的开发都是割裂的,因此整个用户的鉴权机制都是交由小程序开发者自己去处理。但为什么小程序与云服务一定是要割裂的呢,为什么不能整合到一起呢?而 Serverless 这种开发模式是前后端紧密结合的最佳粘合剂。
一般而言,请求从小程序侧发起,到云服务的后台逻辑进行鉴权处理,如果鉴权成功再调用微信公开发 API,然后再把数据返回到小程序。
但我们稍微将整个请求链路改变一下,小程序侧的请求先通过微信的服务,认证并鉴权成功之后,再到腾讯云这边的 Serverless 服务进行逻辑的处理,处理完毕后再返回到小程序侧。这样,我们把整个配置和鉴权服务都帮用户完成了,这又大大减轻了开发者的负担。
通过介绍整个小程序云服务的优化历程,相信大家能感悟到整个产品的理念,就是希望一方面云能力逐步成为小程序开发的基础能力,另一方面也希望尽量减少开发者需要理解的概念。
五、 从前端开发到全栈开发
在云开发模式的推动下,我们开发模式是怎么一步步走到现在的开发模式的?
在Web刚出现的时候,后台开发本就是大包大揽,后台逻辑完成后,再把模板和数据吐出来到浏览器渲染。当时基本上都是做一些比较简单的Web应用。但是当时没有人会吐槽你的后台工程师只有一个人,怎么都把后台和前端服务都干完了,可能当时的业务逻辑并不是很复杂,前端技术也不是那么的规范化,应用场景不是那么多,所以才出现这样的情况。
可是到后来,随着浏览器逐步发展,JS、CSS、HTML有一个规范委员会帮它每年制定一些新的特性。而且随着业务场景越来越复杂,这种情况下开始提出前后端分离,开始要求后台和前端是分开两个人做事情,前后两端是通过API的请求和返回去做一个数据交互。
再到了2008年的时候,乔老爷子凭一己之力开启了移动端的开发生态。到了2017年张小龙大神也跟微信团队推出了小程序且打造了小程序生态。这个时候很多专家提出了“大前端”的概念,希望只写一份代码,就是编译并完成不同客户端的业务,这些端只需要共享一个后台服务就可以了。
这个时代国外出现了一些跨端方案,比如React Native,国内也涌现了 Taro, Omi 等优秀的跨端方案。这几个时期的前端职能是有明显扩张的。
腾讯云目前提供的解决方案就是云开发。
传统开发模式会让前端变成大包大揽地做业务,其实是相当困难的,因为一方面要开发前端和后端的逻辑,还要处理所有的运维的事情,靠一个人是不可能的,所以才有了现在这样的传统分工模式,就是前端、后台、运维。如果把这个业务用上云开发的话,我们主要关心的只有一小部分,主要都是我们的业务逻辑。至少只要这个工程师能够懂Node.js,基本上就可以把服务稳定、性能卓越和有一定安全性的小程序应用独立开发出来。
云开发的开发模式真正可以实现前端工程师全栈开发的理想模式。
来源:腾讯云开发TCB
联系客服