了解客户端架构

Abstract:在PM逻辑层里,对客户端架构的理解属于基础产品逻辑。客户端<——>API<——>服务端<——>数据层。

APP客户端架构解释

客户端架构

客户端页面:最好只负责展现信息(即API给的数据),不要太多多余的逻辑处理。客户端页面被访问的时候,一些非固定的元素,需要去请求API。

只展示API给的数据的优点:扩展性高,即当界面展示信息的需求需要调整时,可以只改API,而不用改客户端。如果把界面信息展示的逻辑写死在客户端上,则需要发新版本才能修改。

API:客户端的数据可能来自各个业务线,API请求各个业务线的接口,各个业务线的服务端需要将数据组织成APP需要的格式返回给API。

业务线的服务端:数据来自于基础数据库,需要根据基础数据库的变化进行更新。

举例:个人知乎专栏首页信息架构分析

知乎专栏截图

最顶部:返回按钮,分享按钮;专栏信息(名称,Logo,关注量,简介)

卡片流:头像,昵称,文章图片,文章标题,文章导语,文章赞同数,文章评论数,文章发布时间。

由客户端展示的信息分析,可能请求了2个API接口:

  • 1.专栏基本信息接口;
  • 2.卡片流接口;

API为了能够返回如上信息,会去请求对应的服务接口(可能是通用接口,有专栏的所有基础信息,超出需要展示的信息的范畴,则API需要根据客户端的应用场景进行处理);然后服务端会去向数据层请求基础数据,把基础数据返回给API,API再对信息进行处理(数据格式+数据数量)

服务端的数据在基础数据有更新的时候会根据一定规则进行更新.

为什么要了解客户端架构

  • 前瞻性地预测功能的后续发展方向,避免实现方式过于死板,导致突发的运营功能扩展需要发版解决
  • 需求最重要:懂技术知识来被避免被骂SB的作用有限,毕竟程序员骂PM的大多数情况是“这个傻逼又改需求”,而不是“这个傻逼一点技术都不懂”

Reference

产品架构基础知识

拿钱去买猫粮和狗粮嗷 ~