API - 应该在前端应用程序还是后端应用程序中进行聚合?

时间:2016-08-01 13:03:24

标签: node.js mongodb aggregation-framework

我编写了一个从MongoDB数据库中检索数据的API。 我还有一个使用API​​数据的前端应用程序(如果相关的话,这两个应用程序都是使用Koa框架在Node JS中编写的)

我需要在一定时间内对大量数值数据进行汇总,这需要计算(平均值,五分位数等),这可能是按月分组的所有数据,按年份或按人员ID分组。 / p>

我已经阅读了一些例子,其中人们说应该将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
}

2 个答案:

答案 0 :(得分:1)

您可以通过以下两种方式来解决这个问题:安全性或性能

从安全角度来看,出于安全考虑,您在前端放置的所有数据都被视为“脏”"。这意味着如果您接受任何输入,则必须抛弃输入甚至远程有效的任何假设。特别是对于大型数据集,您需要对每个创建/更新操作进行某种形式的验证。乍一看,您可能会认为在客户端放置内容可以减轻服务器的负担,除非您希望在任何地方使用漏洞,您仍然会对数据进行某种迭代,如果只是为了验证它。

从性能角度来看,将大型数据集移动到客户端将以任何一种方式发生,但相同的大小并不需要返回。保持服务器上的操作意味着您的更新样式操作要小得多,因为他们不需要通过网络移动整个数据集,但他们可以。为了更进一步,您可以保证至少您可以控制操作的性能,就像您在客户端卸载它一样,您将不得不支持每一个客户的机器在某种程度上,这是一场噩梦。

tl; dr:安全&性能决定了服务器端操作,特别是在大型数据集上。

答案 1 :(得分:1)

我从未想过API是关于原始数据的。 API是应用程序想要的 - 而且很少是SQL代理。

构建webapp的前端工程师可能希望逐个组件地将离散的业务实体插入到他们的前端应用程序中。但他们可能希望能够进行批量调用,并且后端性能和复杂性完全被掩盖。移动开发人员可能希望上面的AND获取数据的特殊聚合移动视图。

  

最简单的形式是,Aggregator是一个简单的网页,它调用多个服务来实现应用程序所需的功能。由于使用轻量级REST机制公开了每个服务(服务A,服务B和服务C),因此网页可以检索数据并相应地处理/显示它。如果需要某种处理,比如将业务逻辑应用于从各个服务接收的数据,那么您可能有一个CDI bean可以转换数据,以便网页显示它。

http://blog.arungupta.me/microservice-design-patterns/

要解释的是 - 您只需通过网页中的小部件访问服务即可。但是,如果您需要处理前端数据,请使用后端服务。

我用"前端视图聚合"并没有发现什么。这对我来说意味着,如果您的数据聚合在单个客户端平台上保持像几个小部件一样简单 - 尽可能保留在前端。但是,随着应用程序复杂性的增加,您将遇到只能通过后端解决方案解决的问题,例如:

  • 代码重用,用于跨客户端平台/视图进行丰富/转换
  • 限速
  • 性能/缓存
  • 安全

考虑到上述情况,我认为后端视图聚合是一项重要的技术,很少能够大规模逃脱。

好消息是有一个健康的生态系统,例如Strongloop(js)或普通的Express(节点)仅举几例。此外,还有大量关于如何实现更复杂版本的工程英雄的文献(spotify

编辑:Correct Kong此时不支持Api aggregation