Antipattern: Invoke a proxy within a proxy using custom code or as a target

You're viewing Apigee Edge documentation.
Go to the Apigee X documentation. info

Edge lets you invoke one API Proxy from another API Proxy. This feature is useful especially if you have an API Proxy that contains reusable code that can be used by other API Proxies.

Antipattern

Invoking one API Proxy from another either using HTTPTargetConnection in the target endpoint or custom JavaScript code results in additional network hop.

Invoke Proxy 2 from Proxy 1 using HTTPTargetConnection

The following code sample invokes Proxy 2 from Proxy 1 using HTTPTargetConnection:

<!-- /antipatterns/examples/2-1.xml -->
<HTTPTargetConnection>
  <URL>http://myorg-test.apigee.net/proxy2</URL>
</HTTPTargetConnection>

Invoke Proxy 2 from Proxy 1 from the JavaScript code

The next code sample invokes Proxy 2 from Proxy 1 using JavaScript:

<!-- /antipatterns/examples/2-2.xml -->
var response = httpClient.send('http://myorg-test.apigee.net/proxy2);
response.waitForComplete();

Code Flow

To understand why this has an inherent disadvantage, we need to understand the route a request takes as illustrated by the diagram below:

Figure 1: Code Flow

As depicted in the diagram, a request traverses multiple distributed components, including the Router and the Message Processor.

In the code samples above, invoking Proxy 2 from Proxy 1 means that the request has to be routed through the traditional route (i.e Router > MP) at runtime. This would be akin to invoking an API from a client thereby making multiple network hops that add to the latency. These hops are unnecessary considering that Proxy 1 request has already "reached" the MP.

Impact

Invoking one API Proxy from another API Proxy incurs unnecessary network hops, that is the request has to be passed on from one Message Processor to another Message Processor.

Best practice

  • Use the proxy chaining feature for invoking one API Proxy from another. Proxy chaining is more efficient as it uses local connection to reference the target endpoint (another API Proxy).

    The code sample shows proxy chaining using LocalTargetConnection in your endpoint definition:

    <!-- /antipatterns/examples/2-3.xml -->
<LocalTargetConnection>
  <APIProxy>proxy2</APIProxy>
  <ProxyEndpoint>default</ProxyEndpoint>
</LocalTargetConnection>

    The invoked API Proxy gets executed within the same Message Processor; as a result, it avoids the network hop as shown in the following figure:

    Figure 2: Code Flow with Proxy Chaining

Further reading