- 主题:app、小程序、pc web端三端共用的后端，宁可四个来回，不愿意两
按照他的逻辑是：我发username、pwd给他，他返回200给我，我再发useid、cid给他，他再发true给我，我再跳转。
我建议两个来回解决：我发username、pwd、cid给他，他判断完后，返回给我，我再跳转。这样的好处是，减少一个来回，提高我写的app的响应速度。他只要把原来的接口复制一份出来，稍微改动一下就可以了。他给出的理由是：三端共用一个后台，万一哪天“三端修改，他只要修改一处代码就行了”，这个理由合适吗？
--
FROM 120.242.252.*
你是对的，性能提高的代价很小，值得做。他只要修改一处的幻想没有实际意义，再说他的劳动并不值钱，产品性能提升和网络流量和服务器开销的节省都是真金白银。
--
FROM 223.72.43.*
如果一个来回就能解决问题
可以考虑让其他两端也一起改
当初设计这种两个来回是基于什么考虑的？
【 在 feng321 (sfdf) 的大作中提到: 】
: 按照他的逻辑是：我发username、pwd给他，他返回200给我，我再发useid、cid给他，他再发true给我，我再跳转。
: 我建议两个来回解决：我发username、pwd、cid给他，他判断完后，返回给我，我再跳转。这样的好处是，减少一个来回，提高我写的app的响应速度。他只要把原来的接口复制一份出来，稍微改动一下就可以了。他给出的理由是：三端共用一个后台，万一哪天“三端修改，他只要修
--
FROM 180.167.95.*
有个东西叫bff
【 在 feng321 的大作中提到: 】
: 按照他的逻辑是：我发username、pwd给他，他返回200给我，我再发useid、cid给他，他再发true给我，我再跳转。
: 我建议两个来回解决：我发username、pwd、cid给他，他判断完后，返回给我，我再跳转。这样的好处是，减少一个来回，提高我写的app的响应速度。他只要把原来的接口复制一份出来，稍微改动一下就可以了。他给出的理由是：三端共用一个后台，万一哪天“三端修改，他只要修改一处代码就行了”，这个理由合适吗？
--
FROM 117.136.8.*
学习了
【 在 Xjt 的大作中提到: 】
: 有个东西叫bff
: 【 在 feng321 的大作中提到: 】
: : 按照他的逻辑是：我发username、pwd给他，他返回200给我，我再发useid、cid给他，他再发true给我，我再跳转。
: ...................
--来自微水木3.5.5
--
FROM 117.100.253.*