Should an API Gateway aggregate and summarize paginated data?

1

This is more of a best-practices question.
I’ve received a request to create a virtual end-point to support a front-end graph. The request is to summarize data from a single upstream API, loop through all the pages and do some aggregations.

I can see arguments for both doing it in Tyk and requesting it of the API Developers, whom we have a relationship with. On the one hand, the whole reason we’re using an API Gateway is just this kind of use-case. On the other hand, this is a little different than aggregating across multiple end-points with a finite number of calls. This request could result in dozens if not hundreds of calls depending on the data set.

However, I’m pretty sure the data will be limited to one user at a time and so the number of pages should be less than 10 for each one, there’s just no guarantee. And I really don’t want the front-end making the requests themselves. I’d much rather have a consolidated place for it.

Any advice is appreciated.

2

That’s an interesting problem. In this case, I think it could be safe if you introduce caps at the gateway level when doing the aggregate.

I’d suggest that this would be a stopgap, you introduce the feature now as a gateway aggregate, with the aim to have the upstream API developer introduce the same feature over time (in a more effective / efficient language and format maybe).

Wouldn’t say there’s anything wrong with this, but the risk with having it at the gateway end as a VE is that it becomes a “feature” and then “forgotten” and then you’re stuck with it because it became a dependency in the gateway instead of the product - so it should be a short-term stopgap at best :slight_smile:

I could be wrong, but that’s just my opinion…

M.

3

Thanks for the feedback as always.
We’re going to do it in Tyk and monitor it for performance issues.

1 Like