Can APIGEE APIs connect to other APIs?

[srikanthpogula]

Hi,

Currently we have services/Service Layer(services.mycompany.com) built on Sprint Boot which connects to PIM database to get product details and send it to be displayed on a web page. We re-implemented these APIs on APIGEE for better security and response caching. Just in case APIGEE APIs are unable to connect to PIM DB, can the logic be implemented at APIGEE layer to invoke existing Service Layer APIs to get data?

If yes, can someone point me to a documentation?

[dchiesa1]

H

---

@srikanthpogula wrote:

Just in case APIGEE APIs are unable to connect to PIM DB, can the logic be implemented at APIGEE layer to invoke existing Service Layer APIs to get data?

---

Hi Srikanth

Can you explain what you mean by that?  Maybe show a diagram , and indicate what failure scenario you're trying to address?  It sounds like Apigee is connecting to a custom service built on Spring Boot, and then that is connecting to some upstream data source. And you want to know if ... in the case that the SpringBoot layer becomes unavailable, can Apigee connect directly?  

If that's the case...

I think architecturally, it's a strange thing to do, to design the API facade layer, to route around an upstream.  Better to either;

• Make sure the middle layer (Spring Boot) is reliable and does not fail.  
• Remove the middle layer completely

[srikanthpogula]

Hi @dchiesa1 ,

Thanks for your inputs, I tried to put it on a flow diagram below.

If APIGEE fails to give response due to issue at APIGEE layer, product detail page is going to invoke Service Layer APIs as a fallback. Service Layer APIs are on Spring Boot. APIGEE layer is just a proxy for Service Layer APIs and also would like to leverage API response caching, These are the two reasons we are planning to implement APIGEE on top of Service Layers APIs. Please suggest if this approach is correct or not.

[dchiesa1 · Accepted solution]

oh I see

To be honest I've never seen a design that included Apigee along with  a plan to "route around" Apigee in the case Apigee becomes unavailable.  Managed Apigee (managed by Google) includes a 99.9 SLA or 99.99 if you opt for multiple regions. It's in the contract. That's pretty good, and probably better than the SLA for most backend systems.  

Rather than design the product detail page to have 2 endpoints to invoke, why not .. use caching at the product detail page?  Or in a CDN,  between Apigee and the product detail page?  But in this case, I am of the opinion that "YAGNI" - you aren't going to need it. Cache if you want better performance, but not to protect against upstream service disruption.  Rather than assume Apigee will fail, and design accordingly, why not assume Apigee will meet its SLA, and design accordingly?  Apigee routinely exceeds the SLA, sometimes by significant amounts.  99.999% is typical.  Some customers consistently see 100%.  That availability is not contractually guaranteed, but it's common. 

If you're managing an Apigee instance on your own, and are concerned about availability, my question is: Why?  Let Google manage it for you and let go of the cost and hassle. 

[srikanthpogula]

Thanks for your inputs @dchiesa1