开发的故事-逻辑切割实践

开发一个app,我了方便用户使用，会选择一部分机能嵌入到app中。
其中想嵌入美团或者其他的一些平台，让客户可以通过该app订餐。
这时候有一个排序的问题？该排序的逻辑是放到服务端还是app端。
在我看来这根本就不是一个问题？
但既然有人提了，我这里就解释一下。
分析1
就举如下一种情景吧：
你想先看看默认排序的结果，翻了几个页后，然后在看看按照举例排序的结果。
这时候这么办，在app端排序。
那么怎么排呢？
那得有数据，服务段全部将数据给你，肯定是不可能的。
那怎么办呢？给你1000数据，你先排序把。
那么怎么给你数呢？
通常由数据库的最后几条给你。
这时候一看，我在长春，给我的数据是北京的。
翻几页看看，有长春的了，我在宽城，竟然是难关的数据。
换一种排序吧，安装距离排序，这下都是长春的数据了。但是由于获取的数据源是基于录入时间的数据源，那么好多有效的数据不在选择范围，所以，用户无论什么排序，也找不到合适的数据。
这时候我们用第二种方案，把全部数据都下载下来？这行吗，当然不性。
这时候用第三种方案，安装地区给数据。安装可选择的坐标提供数据。然后再有客户段提供数据？
但问题是这和服务端排序有啥差别呢？
所以答案是肯定的，app端排序不行。
分析2
刚才不说了吗。这根本就不是一个问题？
你见过在客户端排序的架构吗？
应该几乎是没有的？
那么为什么没有呢？
服务段，干啥的，是为所有的客户段提供服务的，那么排序是什么呢，是访问共有数据还是个别app的数据呢？
是共有数据，共有数据就应该有服务端处理，这是基本的逻辑切割规则。
分析3
再从性能的角度做一下分析吧
如果把排序放在客户端，那么就一定有大数据的传输。
而这些传输的数据很多都是客户不关心的，这是对客户端性能的浪费。
还有这么大的网络传输，客户真的能接受吗？
不说了，在说就变成吐槽了？