欢迎来到酷客淘,为站长提供交易担保服务 访问移动版

世界是平的吗?——从不同角度看前端

日期: 2019-03-31 10:44:54 人气: -

在远古的时候,人们对世界的认知有限,以为天圆地方,世界是平的。后来,随着科技进步,大家都知道了地球的形状,它不但不平,还有山川河流,沙漠海洋。

这很大程度上说明了人所处的环境对认知带来的影响,我们看待一件事物,从不同的视角去看,所得到的结论未必是相同的。


前后端协作的研发模式

上个月有一天很奇妙,早上有个之前部门的同事跟我探讨研发模式,下午有个之前同事跟我吐槽前后端沟通成本高,晚上部门群里又有人提到视图跟服务的关系,这么多巧合,值得在这个事情上写点东西。


回头看看这几年,前端领域在搞的一些东西,除去具体的框架和组件库,大致有这么些:


工程体系:构建、发布、持续集成、容器管理

NodeJS实现的框架、中间件、服务

围绕前后端协作展开的一系列探索:BaaS、BFF、函数计算、GraphQL等

跨端实践

这里面,有很大一部分话题是跟广义的“前后端分离”有关的。站在今天这个时间回头看,看得到每个方向的进展,人们逐步习惯了前端有类型、有构建、有包管理、有测试、有持续集成等等,前端开发逐步成为了相对严谨的软件生产活动。


另外一方面,当我们把目光投向整个系统的时候,我们也可能发现研发流程的一些状况。现在,一个典型的系统,它的开发过程可能是这样的:


前端独立系统

后端独立系统

中间有类似 swagger 的接口约定机制

前端有一套东西,完整的组件化、构建、发布、依赖管理,后端也有一套,但是,两者的结合往往是很松散的,整个链路很长,在流程上会有很不协调的感觉。


形成这个问题的原因是整个研发过程两极分化,断裂得很厉害,前后端的唯一桥梁是接口,并且,一般来说,当一端产生了变更之后,很难有一种自动同步机制去影响另一端,通常只能去扫描发现这些不一致的地方,并且手工做调整。

整个系统的研发流程好比细胞的增殖过程,拉伸成了两块,中间的维系很脆弱。


从架构治理角度看,“两头大”的情况是需要去控制的,只有主从结构的形态,在流程上才是简单的。对这么一个问题,业界存在不同的探索途径:


前端主导的流程

前后端合一的研发模式

后端主导的流程

前端主导的流程

前端主导的流程是怎样的呢?


这个流程的要点是让后端退化为配置,借助 BaaS,FaaS 这样的基础架构,舍弃后端的构建与发布环节,工程上就会成为这样的形态:

这样,后端成为了一种流程无感的环节,前端是整个项目的集成方,后端成为了一种配置化的东西,成为了前端体系下的附属。这种模式是否能行得通,最大的先决条件就是后端接口是否稳定。在互联网企业中,尤其是领域模型关联关系较少的情况下,有不少系统在往这个方向走。


轻量业务:完全 BaaS

较重的业务:通过 Faas 调用微服务

前后端融合的模式

另外,业界也存在一些探索,希望把前后端的开发过程融合。我们所要解决的问题一直都是变更的同步,那么,如果一个项目的前后端都位于一个工程中,天然对同步也是有利的。

这种模式下,实际上是通过两者合一的方式,缩短了前后端研发过程之间的距离和沟通成本,在此基础上,还可以有另外一些手段作优化,比如:


根据后端的服务生成前端的调用接口,并且附带 TypeScript 类型描述

根据后端的单元测试生成前端的 mock 数据

前后端合一的工程中,最大优势就是后端接口的变更一定会自动传导到前端,服务接口字段变更会导致:


前端类型校验出错

前端的单元测试出错

并且,由于二者合并在一个项目中,改了一边忘记改另一边的情况也更不容易发生,两者的发布也是在同一个流程中。


这种模式普适性相对好,但是对人员全栈技能的需求是要稍高的。


后端主导的流程

后端主导的流程又是怎样的呢?


这个流程是反过来,尽可能地把视图弱化,让它成为后端模型的附属物。在很长的时间里,这种形态一直是主流,只是可能具体形式上历经了一些演变。


后端主导的流程推行到极致,工程上就会成为这样的形态: