Web后端工程师应该拥抱前端了

前言

大数据部发展到一定的阶段，无论是内部体系的完善，还是服务能力对外的暴露，对web端交互能力都有极大的需求，所以对web研发的诉求其实也是非常大的。

现在不少web后端工程师还是基于传统的开发模式，通过服务端渲染，把服务端的代码散布在每个div块里，但最终又不可避免的还是需要引入js进行交互，但采用的却是最传统的刀耕火种方式通过 引入js，导致js的开发难度也非常大，没有包管理，没有版本管理，组件化，还处于十年前前端阶段，更别说给js做单元测试，end2end测试了。所以其实效率是极低的。

前后端分离方式

我们在追求前后端分离的时候，一般而言有三种模式：

1. 前端需要用一些前端框架如vue,react以及服务框架（nodejs），然后后端提供一个或者多个API服务。
2. 把前端框架直接发布到静态服务器上，然后前端直接和一个或者多个后端API服务交互。
3. 把前端框架直接发布到对应的服务上，成为对应服务的一部分。

对于一个小而不精的团队，第一种模式会极大的加大协作成本，以及重复开发成本。有的时候这就好比以前后端强硬分层，Service层和DAO层其实完全一样的的代码。第二种模式则需要涉及到跨域或者需要后端再提供一个Proxy服务（网关)。第三种则完全通过一个web工程师就可以cover住，目前看来应该是人效比比较高的一种模式。

为什么Web后端工程师要拥抱前端

为了更好的感受前端的技术，我开发了一个示例项目，从而让自己更真实的感受第三种模式的优点和缺点。

前面我们提到，采用传统web开发的模式，其实是一种刀耕火种方式，并且难以规避对js的使用，很多情况下js的使用会非常的重。RubyOnRails早年对此也做了很多工作，使得其成为一个很成功的纯后端框架,但后端终究是难以取代前端的。

采用传统web开发的模式最大的问题是：

1. 没有很好的依赖管理工具。JavaScript世界有海量的库，没有很好的引入和管理，这就导致很难从中收益。
2. 代码是不好管理的，和后端完全耦合在一起。
3. 测试是困难的，因为div里内嵌了大量服务端代码，需要服务端支持。
4. 后端是不清晰的，如果纯粹API会更好的被组织和管理。
5. 最最主要的是，前端框架使得我们只要专心操作数据，而不是如何操作dom结构。纯前端的开发模式可以让这个优势更加明显。

事实上，经过我实践，把自己的一个web项目拆分成一个前端，一个后端API,然后单独完成，既没有协作成本，也能让自己充分享受两边的技术红利。当然，唯一的缺点是，Web后端工程师又要多学点东西了。