大前端架构思考与选择

时间:2019-07-10

  www.9769.com,这样做是可以的,然而一旦遇到修改,那么要同时修改几个端的代码,很麻烦,不是很完美。

  比如,时间显示,PC端可能要求“2018-6-11”的格式,而APP端可能要求“2018/6/11”的格式,接口怎么给?

  再比如,相同功能的一个接口,PC Web端需要20个字段,已经做好了。现在APP端因为屏幕小,只要10个字段就够了,是复用老的API,让APP忍受垃圾信息,还是为APP额外新增一个接口?

  前端和服务端人员可能会有不同意见,这就带来了冲突。大家都有一定的道理,怎么协调?

  从现状来看,前后端分离之后,服务端直接给各种端提供服务是很自然能够想到的一种方式。这种方式的优点是简单直接,缺点是不够灵活。因此,考虑在前端和后端之间插入一个中间层,作为前后端之间的桥梁,增加灵活性。

  对于这个中间层的称呼,一种是“网关层或者接入层”,这个可能会和后台现有的网关和接入层造成混淆。另一种叫法叫做BFF(Backend for Frontends,为前端而存在的后端),这种称呼相对比较准确,不会带来混淆。

  具体做法是,对于新业务,将Mock数据生成在BFF层,对于各种端来说,相当于后端服务已经好了,可以直接进行联调,不需要等待。这样就把前端对后端的数据依赖去除了,更加灵活。

  人员还是按照专业分工的角度去找,按照每个角色最少2人,防止单点风险的思路,

  “大前端”是按照职能分的,跟后端相对应,是技术部下面的一个子部门,按照职能管理方式进行统一管理。

  职能型组织,采用瀑布模型的开发流程是合适的。产品部,技术部,测试部一般跟产品开发相关度比较大,按照瀑布模型联系起来。这里考虑前后端分离的开发模式,“大前端”可以独立完成开发闭环,虽然BFF层的数据是Mock的。

  另外,大前端版本的开发要求领先后端一个版本以上,这样也方便对于后端服务的测试。简单讲,就是将通常的“后端功能推动型”改为“大前端产品拉动型”

  产品,测试,大前端可以考虑合作,按照敏捷模型进行开发。目的是打破部门墙,加强沟通;以业务开发为共同目标,形成合力。

  漫极客 CTO 李焱:大前端之路 - 如何用Web技术一统三端(Web、Desktop、Mobile)开发返回搜狐,查看更多


友情链接:
Copyright 2018-2021 主页 版权所有,未经授权,禁止转载。