转载 从前端到全栈开发的技术迭代升级

　　从前端到全栈开发的技术迭代升级，从前端技术演进看前端发展野心、同时满足技术需求和商业需求的前端全栈、打破物理隔离，实现真全栈、小程序云服务的发展优化、 从前端开发到全栈开发等五个方面具体来看看。

　　一、 从前端技术演进看前端发展野心

　　从两个维度去分析前端的技术发展，一个维度是前端复杂度，具体来讲就是前端在解决创建应用复杂度方面做的一些事情；另一个是从广度层面看前端做的事情， 这两个维度构成了一个类似于二维平面的时间事件平面。

　　1、逐渐降低创建应用复杂度

　　单看复杂度，前端最开始的阶段只有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框架，支持我们向移动端进展。现在出现了小程序，小程序框架能够让前端继续在移动端轻应用做探索。这里没有讲到的嵌入式开发，这方面也有相应的解决方案。前端不断扩展广度，把前面的边界不断扩大。最终前端想一统天下，把前端全栈化。

　　二、 同时满足技术需求和商业需求的前端全栈

　　所有的技术在发展时期都有两条线去支撑着它发展，一条线是技术需求，即技术层面的技术创意和技术诉求；另外一条线是商业需求，即技术要满足对应的商业诉求。

　　一个解决方案只有同时满足商业诉求和技术需求，才能蓬勃的发展。如果偏离这两条线，就很难发展起来。举个例子，比如Symbian，有些人有想尝试这个技术诉求，但是因为它已经脱离商业需求的层面，所以这个技术会慢慢被淘汰掉。

　　那么，如果仅有商业需求又会出现怎样的情况呢？比如，2000年的时候对AI有商业上的需求，但是技术需求并满足，当时AI就是一个要被搁置的东西。前端全栈，是怎样在满足技术需求的同时满足商业需求的呢？

　　我们回归到移动端APP的开发实际场景，只有两个层面：一个是UI交互界面的开发，这个是可以被用户感知到的，另外一个是用户感受不到的服务逻辑层面。如果来看现有的开发模式，单单从UI交互界面上来看，就有不同的平台端android、ios、h5，对应的语言有Java、OC、swift、js等几种语言，后端的语言和技术实现是更多的。在现在的模式下，一个小型公司如果需要开发一个完整的APP项目，就需要六种技术！

　　每一种技术如果需要找一个专门的人来做，这就需要6个人。那么反映到公司企业运营上面，人力成本是比较高的，除了人力成本还有同样非常高的沟通成本。从沟通的角度上来看，全栈式开发模式的出现，能够让一个人负责更多的业务开发，降低沟通成本。

　　由此可见，前端全栈既满足技术需求，也满足商业需求的，所以我相信未来前端全栈一定会蓬勃发展。

　　三、 打破物理隔离，实现真全栈

　　再回过头看前端散落的各种技术，在这个发展的过程中，有一个很深的隔离，这个隔离本质上就是物理隔离，比如前端和后端，存在手机和服务器之间的物理隔离。

　　因为各种端是实体端，每个端之间都存在物理隔离。就比如前端和后端，存在手机和服务器之间的物理隔离。如果能解决这些隔离，就可以把前端的技术做到真正的统一开发模式，才能做到真全栈开发。

　　其实后端的物理隔离，比如每台服务器之间的物理隔离，可以通过云端化，我们把代码上传到云端平台，云端平台会屏蔽机器之间的物理隔离，暴露给开发者的只有一个集群的概念，而不是一台机器一台机器管理部署。云端化之后，后端的物理隔离被消除了。
　　我们现在的前端代码和服务器之间终存在一个物理隔离，目前的解决方案是通过中间的协议打破物理隔离，比如http协议，但http协议毕竟是中间协议。
　　而serverless的理念就能完完全全解决掉这层物理隔离，因为代码即服务，serverless能打破这层隔离实现前端的真全栈。

　　Serverless中的FaaS，函数即服务，我在使用后端服务的时候，不再关心后端的ip地址，后端的域名是什么样的，直接调用函数即可，对前端来说，后端服务是一个函数，函数就是前端的代码的一部分，后端服务和前端完全的融合在一种代码体系里去了，这样后端的服务即是一个函数，至于这个函数是在前端实现，或者是在后端很远的地方实现，开发者都可以不用关心。所以说，severless打破了物理隔离。开发者不再去做任何隔离中间层的事前，我只需要关心函数的实现就可以了，函数也是用我的前端代码来写，所以达到了充分融合的定义。

　　回过来看具体的实现场景，比如云开发，整个小程序的前后端逻辑都能在一个IDE里面完成，用户其实完全不用担心哪些是服务器的逻辑，他们都去向了哪里，只需要像前端函数一样去理解就可以了。云函数现在也支持了本地调试，就像前端代码一样调试，所以可以做真正的前端全栈技术开发，这对现有的开发模式是一个很大的革新。

　　四、 小程序云服务的发展优化

　　那么，在大前端技术发展的这波浪潮里面，小程序云服务又有什么样的发展呢？早在2017年初小程序正式发布的时候，第一代腾讯云小程序云服务就已经诞生了，但随着8月份全面向个人开发者开放，我们发现这套支服务还是有一定门槛的。于是就开始着手去做更深度的云服务整合和优化，才有了后来的wafer2 和现在的云开发。

　　早期第一代产品 Wafer 的整个开发部署流程，统计了一下大概需要十几步，对许多中长尾的客户来说并不是那么友好。于是我们开始着手优化。

　　通过整个优化，可以简略成四步。第一步是通过一键的配置购买就能把云开发产品开通起来，第二步是工程师进行小程序的前后台开发，第三步进行代码的预览上传，测试体验完，最后便是发布。经过我们这一两年的努力，小程序开发的流程已经由十几步简化到四步了。目前如果从市面上来看，我们这个产品在用户体验以及流程简化度上，在行业内是较为领先的。

　　那么，我们腾讯云团队和微信团队如何一步一步优化我们的产品，将产品的接入门槛降低、流程变简的呢？

　　最初我们看到的是可以将 devops 的部份环节给优化一下，包括代码上传部署。这就催生了后来的Wafer 2，亦即第二代的小程序云服务产品。另外开通购买步骤也是比较繁琐的。将腾讯云和小程序的账号打通后，可以做到一键授权并且开通环境与服务，并且我们提供了一个免费的开发环境，这样可以让更多开发者在进来发布小程序之前，可以以更低的成本门槛用上云开发。

　　剩下还可以优化的就只有 SDK 引入和填写配置的环节了。

　　SDK 其实可以采用内置的方式，毕竟小程序的前端接口也是直接内置到运行环境的 webview里面的。但是配置这块并不太好做了。因为一直以来，小程序前端和后台的开发都是割裂的，因此整个用户的鉴权机制都是交由小程序开发者自己去处理。但为什么小程序与云服务一定是要割裂的呢，为什么不能整合到一起呢？而 Serverless 这种开发模式是前后端紧密结合的最佳粘合剂。

　　一般而言，请求从小程序侧发起，到云服务的后台逻辑进行鉴权处理，如果鉴权成功再调用微信公开发 API，然后再把数据返回到小程序。

　　但我们稍微将整个请求链路改变一下，小程序侧的请求先通过微信的服务，认证并鉴权成功之后，再到腾讯云这边的 Serverless 服务进行逻辑的处理，处理完毕后再返回到小程序侧。这样，我们把整个配置和鉴权服务都帮用户完成了，这又大大减轻了开发者的负担。

　　通过介绍整个小程序云服务的优化历程，相信大家能感悟到整个产品的理念，就是希望一方面云能力逐步成为小程序开发的基础能力，另一方面也希望尽量减少开发者需要理解的概念。

　　五、 从前端开发到全栈开发

　　在云开发模式的推动下，我们开发模式是怎么一步步走到现在的开发模式的？

　　在Web刚出现的时候，后台开发本就是大包大揽，后台逻辑完成后，再把模板和数据吐出来到浏览器渲染。当时基本上都是做一些比较简单的Web应用。但是当时没有人会吐槽你的后台工程师只有一个人，怎么都把后台和前端服务都干完了，可能当时的业务逻辑并不是很复杂，前端技术也不是那么的规范化，应用场景不是那么多，所以才出现这样的情况。

　　可是到后来，随着浏览器逐步发展，JS、CSS、HTML有一个规范委员会帮它每年制定一些新的特性。而且随着业务场景越来越复杂，这种情况下开始提出前后端分离，开始要求后台和前端是分开两个人做事情，前后两端是通过API的请求和返回去做一个数据交互。

　　再到了2008年的时候，乔老爷子凭一己之力开启了移动端的开发生态。到了2017年张小龙大神也跟微信团队推出了小程序且打造了小程序生态。这个时候很多专家提出了“大前端”的概念，希望只写一份代码，就是编译并完成不同客户端的业务，这些端只需要共享一个后台服务就可以了。
　　这个时代国外出现了一些跨端方案，比如React Native，国内也涌现了 Taro， Omi 等优秀的跨端方案。这几个时期的前端职能是有明显扩张的。

　　只做了大前端完全满足不了前端的野心，随着Node.js的发展，有一些中台的服务，比如同构渲染和业务接口但逐步转给Node.js 来做。后台的同事开始专注于去写一些后台的调度服务或者优化整个数据的读取性能。这个时期，前端开发者也开始从前端逐步往后台做一个拓展。

　　但大前端的步伐远远不只于此，在很多业务场景里面，前端工程师比较贴近客户，所以他更能够去理解到一些业务逻辑，无论是业务的前台或是后台，交给前端工程师来做是更好的。举个例子，云开发的其中一个客户是唯品会的前端团队。他们其中有个业务需要依靠后台来支持，但他们的后台人力很紧缺没有办法马上投入支持。于是他们的前端就借助云开发，投入1个前端工程师就迅速把这个业务给做完上线了。其实许多公司的业务都有类似的情况，公司业务发展非常快，但有的时候要前端等待后台的人力，这样就影响到整个公司的业务发展。

　　可是前端的全栈开发的模式，从前端到后台，把所有的业务全都写完了，其实你会发现又回到我们最初的一个工程师大包大揽的做事情。可是这个业务是复杂的，如果没有一个工具或者一个云的基建设施去支撑这个梦想的话，其实是完全不能实现的。

　　面对这样的挑战，我们应该怎么答复我们的老板呢？

　　腾讯云目前提供的解决方案就是云开发。

　　传统开发模式会让前端变成大包大揽地做业务，其实是相当困难的，因为一方面要开发前端和后端的逻辑，还要处理所有的运维的事情，靠一个人是不可能的，所以才有了现在这样的传统分工模式，就是前端、后台、运维。如果把这个业务用上云开发的话，我们主要关心的只有一小部分，主要都是我们的业务逻辑。至少只要这个工程师能够懂Node.js，基本上就可以把服务稳定、性能卓越和有一定安全性的小程序应用独立开发出来。

　　云开发的开发模式真正可以实现前端工程师全栈开发的理想模式。

      来源：腾讯云开发TCB