我编写了一个API，用于从MongoDB数据库中检索数据。我还有一个前端应用程序，它使用来自API的数据（如果相关的话，两个应用程序都是使用Koa框架在NodeJS中编写的）
我需要对给定时期内的一大组数字数据进行汇总，这些数据需要计算（平均值、五分位数等），这些数据可以是按月份、按年份或按个人ID分组的所有数据。
我读过一些例子，人们说API应该用作数据库层的包装器，只提供对原始数据的访问，但对我来说，逻辑将存在于数据库中是有意义的（而不是要求前端应用程序对数据进行篡改）。
这是一个常见的问题吗？根据您自己的经验，让API进行聚合更好吗？还是让前端应用程序更好？
示例文档
{
"date": ISODate("2016-07-31T07:34:05+01:00Z"),
"value": 5,
"personID": 123
},
{
"date": ISODate("2016-08-01T12:53:05+01:00Z"),
"value": 3,
"personID": 789
}
有两个角度可以实现这一点：安全性或性能
从安全角度来看，出于安全目的，您放在前端的任何数据都被认为是"脏的"。这意味着，如果你接受任何输入，你就必须放弃任何假设，即输入甚至是远程有效的。特别是对于大型数据集，您需要对每个创建/更新操作进行某种形式的验证。虽然乍一看，你可能认为把东西放在客户端可以减轻服务器的负载，但除非你想到处利用漏洞，否则你仍然在对数据进行某种迭代，哪怕只是为了验证它
从性能的角度来看，将大型数据集移动到客户端是任何一种方式，但相同的大小不需要返回。将操作保留在服务器上意味着更新样式的操作要小得多，因为它们不需要通过连线移动整个数据集，但可以。更进一步，你可以保证至少你可以控制操作的性能，就像你在客户端上卸载一样，你必须在一定程度上支持每个客户端的机器，这是一场噩梦。
tl；dr:安全性&性能在很大程度上有利于服务器端操作，尤其是在大型数据集上。
我从未想过API是关于原始数据的。API是应用程序想要的任何东西，很少是SQL代理。
构建网络应用程序的前端工程师可能希望将离散的业务实体逐个组件地插入到他们的前端应用程序中。但他们可能希望能够进行批处理调用，并完全掩盖后端性能和复杂性。移动开发人员可能希望上述AND获取数据的特殊聚合移动视图。
在最简单的形式中，Aggregator是一个简单的网页，它调用多个服务来实现应用程序所需的功能。由于每个服务（服务A、服务B和服务C）都是使用轻量级REST机制公开的，因此网页可以检索数据并相应地处理/显示它。如果需要某种处理，比如将业务逻辑应用于从单个服务接收的数据，那么您可能有一个CDIBean，它将转换数据，以便它可以在网页上显示。
http://blog.arungupta.me/microservice-design-patterns/
这句话的意思是——你可以通过网页中的小部件访问服务。但是，如果您需要为前端处理数据，请使用后端服务。
我在谷歌上搜索了"前端视图聚合"，没有发现任何值得注意的内容。这对我来说意味着，如果你的数据聚合要像一个客户端平台上的几个小部件一样简单，那么尽可能地保持前端。但一旦应用程序的复杂性增加，你就会遇到只能通过后端解决方案解决的问题，例如：
- 跨客户端平台/视图进行代码重用以进行丰富/转换
- 速率限制
- 性能/缓存
- 安全性
考虑到以上情况，我认为后端视图聚合是一项重要的技术，很少能大规模成功。
好消息是有一个健康的生态系统，例如Strongloop（js）或普通的旧Express（node）。此外，还有大量来自工程英雄的关于如何实现更复杂版本（spotify，）的文献
编辑：Correct Kong目前不支持Api聚合