We've discovered that the following fields have huge negative impact on the endpoint's performance while requesting the data.
"begBalance": 0, "endingBalance": 0, "currBegBalance": 0 "currEndingBalance": 0,
Since we have another endpoint where General Ledger Balances can be fetched via (api/v2/generalledgerbalance), we're planning to remove those "Balance" fields from the "GL Transactions Endpoint" to eliminate unnecessary "Joins" which is affecting the query performance in the application level.
Please rest assured that there will be no removal before we confirm that those fields are irrelevant and has no value for the integrations those are calling the GL Transactions Endpoint.
Your feedback would be very helpful for us, thanks in advance.
It might not be super relevant in this case, but in general you might consider implementing variants of the endpoint for different use cases with and addition in url. Some times one use case' need for info can kill performance for other use cases.
So instead of giving only once end point api/v2/generalledgerbalance as one-size-fits-all, you could generalize in
and then create special versions in
api/v2/generalledgerbalance/financial for users with financial users
api/v2/generalledgerbalance/logistics for use cases from logistics view
api/v2/generalledgerbalance/auditor if this could be another use case
I think focus on which use case the end point is going to serve will give a better result than new parameteres introduced as-you-go to fix issues that appears...
Results from some of our internal testing,
1) GL Transactions Endpoint Performance Comparison
2) GL Transactions - Current Version / 6.96 MB took 5.06s
3) New implementation, not using the new Parameters / Flags ( 6.96 MB took 3.68s )
4) New implementation, using the new Parameters / Flags ( 5.5 MB took 1717 MS )
Copyright © 2019 Visma.com. All rights reserved.