sharedFlow vs ProxyChain - - which one to choose

[debapriyalaha]

I have a situation where in the proxy need to call 2/3 microservice endpoints and then collate the information to send back to the caller. It's an api orchestration process that I am intended to do in Apigee Edge.

Situation:

Say for example I have microservices A, B & C deployed in AWS EAST and WEST region. AWS EAST is active region while WEST is fallback region.

Created 3 proxies for the above 3 mentioned java services using weighted <LoadBalancer> and <HealthMonitor> tags in order to switch between two AWS Region.

Created 1 proxy with no target having 3 service callout <LocalTargetConnection>, along with some fault rules and basic auth, which is working fine, but having some doubts.

I have following questions:

a. Do proxy chaining making Apigee environment slower / clogging / potential thread level issues?

b. If #a is YES for some reason, what would be best practices for this kind of scenarios? using shared Flow?

c. what would be difference between shared flows and proxy chaining in this context?

d. what's the best practices to be followed for multiple service calls?

[deboraelkin]

Proxy chaining is a way to make inter proxy calls more efficient by avoiding a network hop, as long as you don't recursively proxy chain a proxy back to itself, there shouldn't be thread or clogging issues. The normal protection mechanisms (timeouts, etc) still apply.

Shared flows are meant to promote logic reuse across different proxies, which doesn't seem to be the case here, as you're concerned on to how to efficiently call other proxies, not having logic reused across proxies.

I'd say you've taken the right approach for your orchestration use case.