Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

What are the disadvantages of using shared flows and flow callout policy?

The Shared Flow feature in Apigee is great for reusability, but like any feature, it has its downsides. According to the documentation, there are some utilization implications associated with it. What are these implications, and how does using the Flow Callout policy affect the performance of my API proxy?

Solved Solved
0 2 219
1 ACCEPTED SOLUTION

Hello,

The usage implications deal more so with entitlements as per your underlying Apigee license then anything else - I would recommend reviewing the following documentation: https://cloud.google.com/apigee/docs/api-platform/reference/policies/reference-overview-policy#polic... which talks through what policies can be used under what license structure (mainly surrounding the fact that shared flows are of type 'extensible').

Performance latency should be relatively non-existent by calling into a Shared Flow, given the fact that the Shared Flow operates within the same execution runtime context when compared to the API Proxy (meaning, this call does not go back out to the internet for processing). I would still recommend testing your workflows at load, but the underlying flow call-out to shared flow processing is used successfully by a ton of our customers in production-level environments today.

Thanks!

View solution in original post

2 REPLIES 2

Hello,

The usage implications deal more so with entitlements as per your underlying Apigee license then anything else - I would recommend reviewing the following documentation: https://cloud.google.com/apigee/docs/api-platform/reference/policies/reference-overview-policy#polic... which talks through what policies can be used under what license structure (mainly surrounding the fact that shared flows are of type 'extensible').

Performance latency should be relatively non-existent by calling into a Shared Flow, given the fact that the Shared Flow operates within the same execution runtime context when compared to the API Proxy (meaning, this call does not go back out to the internet for processing). I would still recommend testing your workflows at load, but the underlying flow call-out to shared flow processing is used successfully by a ton of our customers in production-level environments today.

Thanks!

Hey @mohaned739, just checking in! I see @hartmann provided a breakdown of your question—Hope it helps!

Let us know if you have any follow-up questions, and thanks @hartmann for your detailed response 🙂Looking forward to your update!