Single proxy for all APIs

[#1]

Hi,

We have been refactoring, reorganizing our Apigee proxies that we use to expose our backend APIs. There are several steps that are executed in our proxies i.e. spike arrest, logging, authentication, error handling etc.

While organizing we realized that all the proxies are doing the same thing, have the same code except using different target url based on proxy.pathSuffix. Would it be a good idea to put everything in a single proxy and manage the tiny differences via a KVM (proxy.pathuffix => target.url OR proxy.pathSuffix => API_NAME => target.url for a little bit of decoupling and abstraction).

We already extracted all the common flows, default fault rules and even the fault rules (in a single if-then-else'd JS policy) in to shared flows. But still the proxy endpoint, target endpoint and some other policies are pretty much identical between APIS with a slight path related difference.

So in this case what would be a drawback if we simply use the same single proxy for all the APIs. We would trim the base bath to the root prefix (that all APIs shared anyways - i.e. "/services").

@Mohammed Zuber, @Anil Sagar @ Google

Thanks.

[rk-muvva]

@Ali Ozgun: I will wait for the experts answer however to my knowledge it largely depends on how you want to package the proxies into products. If you want to have all of them inside one product it makes sense to have one or few proxies defined based on functional separation. To give an example, Customers can be one proxy where all customer related API's (Get/Put/Delete/Post - Get Customers, Update Customer, Add Customer, Delete Customer) can fit into that. That is more cleaner and manageable from business stand point. However if want to separate access to add/update/delete API's from GET API's , it makes sense to have them separated so that your products can be like GetCustomer and UpdateCustomer (add/update/delete) with corresponding proxies.

[nagashree_b]

@Ali Ozgun

As Ravi pointed out, its not a good design to expose all business services through a single API proxy.

Two reasons:

1. the load on the single API proxy is high, because it needs to cater to all the requests. Imagine a Quota or rate limit ir spike arrest configuration added, the limit will be hit sooner because of the single proxy design.

2. By having a single API proxy you are opening up all the backend business services to all the consumers. For eg: you may have multiple business groups who should be provided access to certain business services only. In that case, the single API proxy design would not work.

The ideal way would be to package multiple API proxies as products based on the business need and allow consumers to subscribe to one or more products as required.

As i understand from your query, your concern is more about the repeated lines of code in each of the API proxy in terms of the proxy endpoint and target endpoints. These are the backbone of the apigee api proxy and you cannot do away with. Instead you could capture the single api proxy bundle as a template and write a utility to include these and the shared flow callouts to just generate the api proxy bundles as required for multiple api proxies