Sharing common code between three proxies

[#1]

I need to create three API proxies that all do essentially the same thing. There is some (non-trivial) orchestration of calls to our backend services (which will be done using nodejs) and then some translation into an output format. The only difference between the three proxies is that they will return the data in different shapes (not ideal but can't really be helped).

I want one team to own the common code and do the orchestration, and then each client team own the bit that does the translation.

The easiest way seems to be to create 4 proxies, one that does the orchestration and three others that call the first and apply the relevant translation. I know this goes against the current Apigee best practice, is there a better way?

[#2]

@Andrew Braithwaite

If you want the common code at runtime , thats the only way .(#APIchaining)

Pros : No need to redeploy dependent API proxies, if there is any change to the common code. Cons : An extra http call every time you look up the common proxy which can add some latency

Another way of doing this is have the code as separate but merge while deploying the individual API proxies . In this way its just 1 API proxy at the end of the day .

Pros : Write once , reuse and everything in the same Proxy . Cons: Need to redeploy the dependent API proxies when ever there is a change to the common code .

Would like to hear more opinions and observations on this from the community.

[DChiesa]

regarding the downside of an extra http call to invoke the common proxy... this is no longer the case with proxy chaining. Read more about it here , and here.

[#4 · Accepted solution]

A new process that is becoming more and more popular is the use of building common fragments and policies into a common proxy and having the stitched together at build time to your other proxies using a build tool like maven. To make this easier we have a plugin that is available with ample documentation on github.com -- https://github.com/apigee/proxy-dependency-maven-plugin

The core principle is you keep a core set of policies and xml fragments (flows) in a central repository, at build time the plugin looks at the policy definitions in your flows and copies those policies into your bundle while packaging your xml, it also will look for predefined tokens in the xml wrapped in #'s if it finds those tokens it will look for a matching fragment in the common proxy structure and replace the token with the fragment of xml, this gives you the ability to have common workflows in different proxies.

[#5]

I quite like the approach, but I do not want to have three versions of the orchestration code in three seperate places as I will have to deploy three times across multiple teams if anything changes.

[banto_78]

Hi, is this plug-in and practice usable for Edge cloud too?

thanks.

[DChiesa]

Update (2016 July): See the proxy-chaining tag.