通常开发套路
通常公司进行app开发,都有会以下2个必要的组件(我是后端):
1、server提供接口
2、根据ui,移动端设计界面并渲染(动态数据由接口请求返回)
这会产生什么问题呢?
由于国内的环境,大家懂得,开发迭代的速度会非常快,通常一个ui上周说是要这样,这周就要另个一个样子了。
但是,由于客户端的发布和打包审核都有一定周期,导致项目无法准确在准确的时间点上线,所以最好是能由服务端来控制,我到底使用哪个UI进行渲染和操作,会大大加快版本迭代,也可使前端开发更专注在ui的适配性上。
文章背景
目前我就职于国内W公司,马上就要进行离职了(回家种地!哈哈哈),所以想把一些已知的东西做些记录。
w公司,嗯,国内也算几个最活跃的app之一了。那W公司是如何快速进行业务开发的呢?
W公司客户端套路
W公司的每个客户端页面都是一个page,然后里面是card。以图来解释吧:
所以,客户端前期的工作就是渲染大量的card。
而到了后期,只用迭代主ui和交互工作的scheme即可。
W公司服务端套路
W公司的业务是繁重的,每个业务之间几乎有天差地别的处理,那对于客户端来说,他不可能去每个业务方单独调用每个接口,因此,要有一个中心,W公司称之为(mapi 微服务的api getway部分)。
然后业务线很多,每个接口参数也不一样,这时候,假如业务方每次更改,都得和mapi同步信息,好像也不好。因此,衍生出一个对象库(object library),按照我的理解,就是每个要渲染的对象都拥有唯一的一个id,每个id在对象库里都存在着相应的业务。
同样,以图说话:
请求过程: client->mapi->objcet->modules->mapi(汇总数据)->client
对于每个业务方: 写接口->注入到object->将oid注入给mapi
这样做还有另外一大好处,就是可以充分的解耦每个业务方(当然也有不好的地方,每个业务方实际都是自己维护自己的数据)。
当然,图中并没有提及W公司的核心业务feed,因为我直接想总结下这个套路。
套路的思想
其实,每个公司都有适合自己公司开发的套路。我在这里总结的W公司的,但是可能并不适合别的公司(我觉得,特别是业务快速迭代的公司不要使用这个套路,前期开发成本太大,当业务定型之后,可以根据这个套路进行更符合自己业务的调整)。
文字不太会总结,所以我通常都喜欢以图说话 emmm.