There's an opportunity to improve the performance of the getAllTransactionsForAccount method. Pluggy defaults to 20 items per pageSize. Looking at the implementation, it seems the SDK recursively calls fetchTransactions until there are no more pages.
The issue with the existing implementation is that it's not updating the pageSize. By keeping the default of 20 items, we incur extra latency costs for each request. If we updated to use the maximum of 500, there would be fewer requests to Pluggy's back-end.
It's worth saying the bandwidth costs would increase, given the payload would grow from 20 transactions to up to 500. However, given the implementation requires requests to execute serially, I believe optimizing to fewer and larger responses would improve response time.
There's an opportunity to improve the performance of the
getAllTransactionsForAccount
method. Pluggy defaults to20
items perpageSize
. Looking at the implementation, it seems the SDK recursively callsfetchTransactions
until there are no more pages.The issue with the existing implementation is that it's not updating the
pageSize
. By keeping the default of 20 items, we incur extra latency costs for each request. If we updated to use the maximum of500
, there would be fewer requests to Pluggy's back-end.It's worth saying the bandwidth costs would increase, given the payload would grow from 20 transactions to up to 500. However, given the implementation requires requests to execute serially, I believe optimizing to fewer and larger responses would improve response time.