Hi @kdanekind1
I am currently working on a project that has a requirement similar to that you describe.
We have two situations where we needed to loop calls to the back-end:
- The responses are paged but the client requires a single response (the first response is the first page but also provides the maximum number of pages)
- Cache prepopulation - looping across a range of parameters (in our case sales territories) including some that are paged as per 1. above and making cache entries with the responses including combined paged responses
The implementation we chose was to perform this in a nodejs target deployed to Edge.
From a development and testing perspective, we were able to work locally and being nodejs it can be run standalone and verified before being deployed to Edge.
Why did we choose node.js?
Mainly because we couldn’t see how to make it work with policies alone and our Java skills are lacking (some might say that about my node.js also!)
We didn’t consider doing this at the back-end mainly because of time to develop the solution.
I think @Mukundha Madhavan makes a good point about choosing the back-end/ESB where the orchestration across services is driven by business logic vs apigee where it’s about mashing responses together. In our case the looping and orchestration is about combining responses so that fits in with this view.
A word of caution on node.js with apigee
The back-end services we have are SOAP services and for this project they are serving up data from our SAP BI database.
We reached a point where some of our responses were timing out. This caught us by surprise because testing locally with node.js they were acceptable (to us) at the 10-12 second mark.
Deployed to apigee they were taking 60-70 seconds and in some cases longer than that such that there was never a response.
After some apigee support tickets this was narrowed down to the performance of the XML parsing in node.js when running with trireme on Edge. It’s possible to run locally with trireme - I recommend that if you’re intending to deploy the node.js to Edge so that you are aware of possible performance problems ahead of time.
The other things to consider when looping with node.js:
Do you wish to respond to the request immediately and let node run as a background task or do you need to wait until all the responses are received before responding?
We ended up with both - the prepopulation of the cache became a “background” task but the client got an instant response to indicate that the request was received and prepopulation was in progress. The “regular” calls wait for the combined response.
If you end up with a “background” task that’s a long running task (i.e. longer than your client is prepared to wait) then how do you keep tabs on what node is doing?
We opted to write some things out to the node.js logs in apigee but also to loggly. Using an external logger like loggly just makes it much easier to see what’s going on and to be able to search/filter the log.
Wait a minute! No solution to the performance problems?
We resolved the node.js performance problems with the help of apigee. @Sean Davis, @ncardace, and Deepak Sharma have provided great assistance (Thanks!).
For the calls that performed poorly, we now have a solution that uses Javascript policies to make the calls to the back-end.
For cache prepopulation, two js policies handle the looping across pages with a node.js target solely to put the responses in the cache.
For “regular” calls we had to redesign a little so that we cache by response page and the client handles the mashup. This deviates from what you require I think, and it did for us too, but the performance gains from using Edge policies have been worth it.
So, we have a node.js solution and an Edge policy solution side-by-side achieving the same result of looping calls to the back-end services.
I haven’t quite answered your question directly but hope that the brief description of what we have done and experienced helps in the decision making.
