Single Vs multiple apigee proxies for multiple target backends

[aramkrishna6]

Do we have any guideline based on given use case to understand & best practices.

To create composite apigee proxy for given Mutiple target end points.

Or

Create separate proxy for every target end points. 

Did not find in antipatterns on same topic or in another link detailing about same. 

Don't have requirement of proxy chaining or let's not comment on proxy limits/env.

If Business doesn't define number of proxies for different endpoints, what is good solution & most of time each endpoint is for required requirement..

Don't have any product or monetization requirements and each of target endpoints filtered based on REST verbs and path suffix routing condition.

Any docs or reference on such best practices . Single Vs Multiple proxies for number of target end points ?

@dino  

@ganadurai 

@adevegowda 

@anilsr 

[dchiesa1]

The configuration model in Apigee allows a many-to-many relationship between ProxyEndpoints and TargetEndpoints in a single API Proxy. Allows, but does not require. The Proxy in Apigee is a unit of abstraction that allows you to connect to multiple distinct, even disparate, upstream target endpoints. The RouteRules in the proxyendpoint are designed to support that. 

When would you use multiple targetendpoints in a single API Proxy? One clear case is to produce a single facade API that groups together operations from multiple distinct systems, in a way that makes sense for an API Program manager, and for a consuming developer. For example, you might have an off-the-shelf CRM along with a custom bespoke order processing system. Producing a single API that wraps both of them might be a good case to use a single API proxy with multiple targetendpoints. On the other hand, in an environment where systems are newer and all built in the same era- where there is effective homogeneity in the upstream - you wouldn't need disparate targetendpoints because all the targets would be reachable from the same endpoint.

Even if you have a homogeneous backend , in which all exposed APIs are available from a single (maybe virtualized) endpoint, you STILL may want to allow for multiple targetendpoints if your expectation is that homogeneity in the upstream will not persist, either because of mergers/acquisition, or acquisition and use of new tools or off-the-shelf systems. Some companies might want to build everything, others might want to assemble tools and custom-built things into a cohesive unit.

In general, the best practice is to use the power of that configuration model in such a way as it is maintainable and operable by the API program team, or the API publisher, given the environment you are operating in.

There are of course other related issues to consider - will you expose a single API proxy as an API product? In Apigee, again there is a many-to-many relationship possible between proxy and product. But in many cases, API program managers don't need that generality and exploiting it might lead to more complexity. So they adopt a convention in which each API proxy is exposed as a single API product.

There is also a many-to-many relationship possible between app credential and API product. So even if an App requires multiple related APIs you could issue one set of credentials that are usable across all of them.

In short, do what makes sense for your organization and what you believe will be the most maintainable over the long term. Avoid complexity, eg routerules and multiple targets, until it makes less sense to do so.

[aramkrishna6]

Thanks for detailed notes and inputs  @dino   

Few other points to consider single proxy for multiple target endpoints, let me know your view.

1.Using Single proxy, with conditional statements, we can control the target endpoint invoked by proxy endpoint configuration. A route rule forwards a request to a particular target endpoint. When more than one target endpoint is available, the route rule is evaluated for its condition and, if true, the request is forwarded to the named target endpoint.

This way we can create multiple target endpoints within single proxy & use route rules to route traffic as needed then we get the benefits of the TargetEndpoint, with the flexibility of dynamic URLs to target, which makes simpler and easier to maintain proxies.

To my understanding, above may not be considered complex to separate proxy based on target endpoints (Single Vs Multiple), because this is how apigee target endpoint routes.

1. Single proxy: Say for example given target endpoint with GET, POST and other REST verbs will be abstract (cohesive) using same  authx mechanism for desperate target endpoints/backend applications.
2. My understanding, you also referred talking to business owners/product owners, to get the 'outside in view' than separating the proxies based on complexity, which just may be 'inside out view'

[aramkrishna6]

@dchiesa1  @dino  @ganadurai  @adevegowda @anilsr 

Per Apigee antipattern Antipattern: Define multiple ProxyEndpoints in an API proxy  |  Apigee Edge  |  Apigee Docs

List anti-patterns only with respect to proxy end point (and this does not relates to proxy with multiple target endpoint ). Listing following, per proxy endpoint details.. as below

Using one ProxyEndpoint per API proxy leads to:

1. Simpler, easier to maintain proxies
2. Better information in Analytics, such as proxy performance and target response time, will be reported separately instead of rolled up for all ProxyEndpoints
3. Faster troubleshooting and issue resolution

But question is of having single proxy for multiple target end point ? (If thats the best practice and antipattern on that ?)

If that the case above listed information will not be applicable as antipattern for single proxy with Mutiple target endpoints...

I mean creating 5 apigee proxies for 5 Target endpoints --> Here maintenance of 5 Apigee proxies for 5 different target endpoints, but the logic does not require routing or condition and simpler 

Another adv in this approach is analytics is per apigee proxy not per target endpoint, hence this should be preferred ? 

or

Creating one Apigee proxy for 5 target endpoints 

Maintenance of one apigee proxy is simpler but having a logic of routing and conditional logics but Analytics is per Apigee proxy only, in this case we cannot get analytics per target endpoint ... 

Let us know, views if overlooked .. 

[aramkrishna6]

Overall context is apigee antipattern does not list antipattern with respect to proxy with single or multiple target end point, but do only list with respect to proxy with single or multiple proxy endpoint.

1. When it comes to analytics, if we have one composite proxy with multiple target end points, will requires creation of custom analytics (If we need analytics per target end point). We know, Its not possible to know, composite proxy having multiple target end points, with default Apigee analytics view hence will require creation of custom analytics.

 2. When it comes to creation of product even Composite proxy (with multiple target end points can create API product) and even when one proxy created with one target end point in that case multiple proxies can map to one API product.

Do we see any comments ..

@dchiesa1