逻辑接口和配置接口你们会分开还是合并那?

[SethShi]

比如有一个业务逻辑: 新用户弹窗, 弹窗要能配置开关(关所有都不弹, 开则需要判断是否是新老用户)

• 方法 1

1. 配置接口返回开关
2. 用户接口返回新老用户判断
3. 客户端取两个接口判断

• 方法 2

1. 服务端合并接口返回配置和是否新老用

过了一个月, 需要增加一个老用户判断(同样需要配置)

• 方法 1

1. 配置接口返回开关
2. 用户接口返回新老用户判断
3. 客户端取两个接口判断

• 方法 2

1. 服务端合并接口返回配置和是否新老用

过了一个月, 需要增加一个福利弹窗开关 xxxx 类似, 有这样的一个系统, 你更青睐哪种设计或者有更好的方案?

[seanlin5]

逻辑判断放服务端接口，前端无需判断用户权限及逻辑，可以随时调整。比如首页要展示几个弹窗，搞一个数组里面，在前端只需要判断数组长度，有则弹。这样 api 端控制的好处是，随时可以调整规则，无需更新 APP/小程序。

[renmu]

当然是接口了，如果同时有四五个客户端那就更该接口了

[javalaw2010]

根据两者是否是同一领域来决定。

弹窗和用户本身不是同一领域的，不同领域的服务可能不在同一个系统上，比如我司就区分了配置中心和用户中心，各个业务还有自己的业务字段，这里如果合起来依赖关系会很复杂，所以我比较倾向于分开来。

如果现在增加了一个需求：比如老用户可以绑定邮箱和手机号，而新用户只能绑定手机号，这个可以认为属于同一个领域，所以就服务端合并下发配置。

[SethShi]

@seanlin5
@renmu 上面是举例, 现在情况有一个类似这样的逻辑. 部分菜单功能是 A 服务返回, 判断是新用户服务在 B 上, A 服务应该请求 B 服务吗?
类似的点比较多, 首页五个地方都要新用户判断, 是在服务端请求 5 次, 还是客户端初始化请求一次判断, 当前 session 使用

[SethShi]

@javalaw2010 现在情况和你说的领域有点像, 现在是在好几个服务商

[seanlin5]

@seth19960929 那是否需要启动 BFF 去处理呢？我比较倾向界面的显示通过服务返回字段获取，不要在前端执行多个 && 逻辑判断，后期需求更改，修改起码比较麻烦

[SethShi]

@seanlin5 #6 而且这两个接口客户端都在请求, 单独为这个功能加一个 BFF, 请求*2 了