Should I use Service Callout or javascript to do a conditional mashup

[#1]

I have a mashup use case where I'm calling n-number backend Apis based on query parameter value

For instance, if the request comes to https://my-api?include=service1,service2, service3 I would then need to call all three backend Apis. However, if they only included service1,service3 I would only call two APIs.

For a usecase like this, which of these is recommended and what drives the recommendation

1. Service Callouts with Regex condition
2. Javascript
3. Node.js

[DChiesa]

This is a judgment call. In my opinion, the tool you use for the job depends on your coding skills and aptitude, and what you are comfortable with.

I'm personally comfortable coding in Javascript, and I find the HTTP client that Edge provides is easy enough to use. There are good examples, I can easily see how to use it, and asynchrony works. I can make 3 parallel outbound calls and then later handle the responses.

Nodejs is also good for this, and of course can take advantage of more "standard" http clients, like the npm "request" module. And can also use "async" or "q" for asynchrony. But today, using nodejs within Edge requires that your "target" be a ScriptTarget. This affects how analytics are collected and displayed, and may not be satisfactory for all people.

Using ServiceCallouts with conditions on the Steps will work, but it may be more XML wrangling than people want to do. As things get complicated, extracting data and calling the next service might require lots and lots of XML configuration code, and that might better be done in a standard language like Javascript.

So that's my opinion.

[ozanseymen]

My vote goes to node because of its async nature - we can connect n services all at the same time. We can also do this with JS but having node.js in the target (rather than as a step within a flow) renders very naturally to Apigee request/response concepts.

Otherwise you will be reading combined target output from a step in a default proxy with a null target which doesn't seem to be a good design.

[sarthak]

I typically consider 1 and 3 as two practical options.

Option 1 I consider only when I am doing mashup of 2 APIs and not a lot of conditions. More like a dumb mashup.

If I have a more complex mashup like multiple APIs and have conditions under which I may call API 1 vs API 3 etc. I will typically use node.js. It just makes building the mashup a whole lot easier.

Does that make sense ?

[adas]

@Sandeep Murusupalli Your choice really. But one advantage that you would get with javascript is that, you could do this asynchronously, which means even if one of your backend takes longer to respond you are not waiting for the response to come back before you call the next one.

Here's a very simple example of mashup with asynch javascript. [attachment]apigee-trial-rev1-2015-05-28.zip

[#6]

Thanks @arghya das for the example. I always wonder how calling waitForComplete(10000) will impact if there are n requests, which may take longer than 10 seconds. Will it drop the ones that didn't complete within 10 seconds?

[#7]

There are few determining factors i would take into consideration, or a choose your own adventure model of determination.

A: Number of calls - Is there a top end to the number of service callouts you could possibly generate. (if the top-end is over three or not defined you can rule out service callouts.)

B: Async - Does the Service callouts need to be run asyc (if yes then rule out service callouts)

C: Performance requirements - If performance is a key factor, meaning you expect this to be a high volume, low latency call you should evaluate in this order depending on what the answer to a and is. (Service Callout, js, node)

😧 Ease of development - If ease of development and future readability are key and A and B and C don't apply you could re-order the suggestion to be (node, servicecallouts, js)

Note: Depending on protocol you could have some determining factors, like json is really easy to work with in node and js but xml can be a pain and is easier to work with in xslt etc.

Good Luck and Happy Hunting

[adas]

@dzuluaga I think it would result in a javascript ScriptExecutionFailed exception. You can quickly test that out by reducing the WaitForComplete to maybe 5 seconds and changing the delay in the target. Maybe from the proxy developers perspective it would be good to be able to specify, whether he wants to drop that exchange object and proceed or throw an error. The runtime error doesn't make a lot of sense, as far as I am concerned.