关于前后端接口的可扩展性思考

Posted zcube

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了关于前后端接口的可扩展性思考相关的知识,希望对你有一定的参考价值。

在写iosandroid客户端程序,尤其是涉及到和后端对接口的时候,大家通常会针对下面三个问题引发一些争论:

  • 不能写死
  • 容错能力
  • 过度设计

之所以会争论,是因为这三点很多时候是对的,但是如果不分情况和场合的应用就会出现一些扩展性的问题。

不能写死

不能写死,比如这个边框颜色写死到客户端还是后台下发。下面这张图红框标注的叫外置筛选项。


在7.6版本的时候这个框和文字都是绿色的,选中态和未选中态的颜色是由后端控制。7.7的时候设计改为了蓝色,而且右下角加了个小对勾。这时候该怎么办,让后台做版本控制只在7.7下发蓝色的UI颜色,但是前端依然需要改变组件,在右下角加小对勾图标。要知道绿色在之前连续3个版本都没有改变过。那后台下发颜色达到灵活控制的意义是什么?不能写死,是真的死吗?这个值得思考下。

做客户端需求时候,由死到活目前有三种方式:写死-》后端控制-》i版Hybrid。当然还有RN动态化之类技术,目前在公司用的不多。往往要不要用i版一经确定,没有什么好争论的。但是要不要写死,却需要理智判断。首先“死”不是真死,因为每个迭代周期都可以赋予它新的生命。所以在决定要不要写死的时候,要从下面两个方面判断:

  • 变化频率:需要问下这个是否根据业务逻辑实时变化,比如上面的按钮就不需要变化。
  • 是否界面:如果是设计的UI界面,通常将切图直接放在客户端。如果需要根据业务逻辑更新界面,比如标签,尽量让后台直接下发切图链接,而不是描述性的界面数据,因为描述性的界面可扩展性不强,例如边框颜色数据可以用背景图片链接。

容错能力

容错能力,客户端同学往往感觉不能相信后端数据,万一不符合预期,客户端也能正常显示。但是也得从易变和不易变区分考虑:

  • 易变:是否为产品需求逻辑,这个是易变的,所以客户端不需要保证。
  • 不易变:接口字段类型,ID类型,这个是不易变的,需要校验。

客户端要保证的是在出错时候不要给用户很不好的体验就好了,比如crash。往往后端数据出错属于线上故障,发现后应该立即修复,互联网公司app大多为展示型app,所以如果后端出问题,客户端是没有可能容错的。如果产品逻辑也容错的话,就会造成扩展性降低。

比如下图产品要求显示3个cell,如果不够3个就不展示,假如后端下发2条或4条,客户端要不要展示呢?


下面的对话是两个客户端同学的对话:

  • A:这块逻辑后端会控制,咱们以有无下发对应模块的数据进行显示判断就好了。
  • B:这样不行吧,那假设后端下个了 1个,你也显示啊。
  • A:如果一个后端就不会下发数据。
  • B:我是考虑如果后端出错,返回不符合逻辑的数据的时候客户端应该如何处理,客户端应该有容错的能力,不能单纯靠后台保证。
  • A:那产品要改为下发 2个 或 4个 呢?
  • B:那就把 bug 果断的转给 PM吧!

B的容错想法非常好,但是如果进行逻辑容错反而会造成扩展性的降低。因为显示3个是产品的决策,客户端没有必要为产品的决策去容错。因为人的决策往往不一定是对的,而且常常会进行调整。在开发展示型客户端时候,大规模依赖后端数据进行展示,要做到的容错也仅仅是不crash就好。至于数据的对错,交给后端同学进行逻辑判断和过滤。

过度设计

过度设计,客户端同学和产品同学,往往考虑的情况会太多,陷入细节不可自拔。比如之前需求讨论过一个定位刷新问题:如果用户打开app,走了一段距离位置变了,我们应该怎么处理;如果用户没杀掉app从海淀到了朝阳,位置变了又打开应用应该怎么处理。其实有很多场景是概率极低的,即使有这种情况,其实也可以忽略。

怎样避免过度设计和过犹不及的情况,可以从以下两个方面考虑:

  • 是否必须:如果不特殊处理会不会对用户造成损失和非常不好的体验。

  • 场景概率:这种概率有多大,是不是会经常出现。

过度设计这个很难界定,一般当写代码时候需要很奇怪的各种判断时候,就需要考虑考虑是不是存在过度设计情况了。因为过度设计添加的各种判断,往往会增加代码的复杂度和降低代码的可扩展性。

一般符合好的设计,程序实现也比较容易,不好的设计,程序设计需要很多奇怪判断。所以RD也要多思考简单优雅的逻辑供产品同学参考,而不是两耳不闻产品事,一心只写我代码。

以上是关于关于前后端接口的可扩展性思考的主要内容,如果未能解决你的问题,请参考以下文章

关于前后端接口的异常的处理

前端提供给后端一个接口是啥意思

关于前后端分层测试的思考

如何设计拖拽排序的后端接口

sqlserver后端接口最好的语言

第二十次ScrumMeeting会议