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

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

我需要在一个给定的时间内(需要计算的平均值,五分位数等)进行大量数值数据的聚合,这可能是所有数据按月份分组,按年份分组或按personID分组。

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

您可以从两个angular度来看待:安全性或性能

从安全的angular度来看,为了安全起见,您将放在前端的任何数据都是“脏的”。 这意味着如果你接受任何input,你必须抛出任何假设,input甚至是远程有效的。 特别是对于大型数据集,您需要对每个创build/更新操作进行一些forms的validation。 乍一看,你可能会认为把事情放在客户端上会使服务器不堪重负,除非你想在任何地方利用漏洞,否则你仍然对数据进行一些迭代,只是为了validation它。

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

dr:安全性和性能主要倾向于服务器端操作,特别是在大型数据集上。

我从来没有想过一个API是关于原始数据。 API是应用程序需要的任何东西 – 很less是SQL代理。

构buildwebapp的前端工程师可能希望将分立的商业实体插入到他们的前端应用程序中,逐个组件。 但是他们可能希望能够进行批量调用,并且可以完全屏蔽后端的性能和复杂性。 移动开发者可能希望上面的AND获取数据的特殊汇总移动视图。

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

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

这意味着什么 – 你可以通过网页上的小部件访问服务。 但是,如果您需要处理前端的数据,请使用后端服务。

我从“前端视图聚合”search了一下,没有发现任何说明。 这对我来说,如果你的数据聚合要像一个客户端平台上的一些小部件一样简单 – 尽可能保持在前端。 但是,第二个应用程序的复杂性增长,您将遇到的问题只能通过后端解决scheme来解决,例如:

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

考虑到以上情况,我认为后端视图聚合是一个很难达到的规模技术。

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

编辑:此时正确Kong不支持Api聚合