How to check for shared flow dependency deployment prior to proxy deployment?

[kristianjaeger]

Hello,

How to check for shared flow dependency deployment prior to proxy deployment? It would be great if this could be added as an Apigee platform feature to check before deploying a proxy that has a dependent shared flow. Thank you.

FYI, a fellow Google employee wrote about this subject, at a high level, recently - https://research.swtch.com/deps . The 'simple' solution at a high level is to "Automate, automate, automate" 🙂

[dchiesa1]

Ahh yes, I see what you mean.

I can imagine enhancing the validity check for apiproxies, so that at deployment time it would verify that, for any apiproxy with a FlowCallout, the referent SharedFlow is available and deployed in the environment.

But, that check is valid only at that moment. At any point after deployment of the apiproxy, it will be possible for an operator to undeploy one or more of the referent sharedflows. Which means the apiproxy will no longer "work" at runtime.

A possible helpful analogy is the HTTP Target Endpoint. Most proxies specify one or more targets with an HTTP Target Endpoint. Upon deployment of the aPI proxy, Apigee Edge does not check the reachability of that (upstream) target. At best such a check would have momentary value. It would not provide any worthwhile guarantee.

A check of the availability of the sharedflow is similar in my mind. It's different of course because any sharedflow is actually under the control of Apigee Edge itself. So the "check for deployment" is actually possible in the moment. But still, it would provide only a momentary view as the the availability of the system.

Beyond checking that the SF is deployed, to be sure the proxy will "work", we would need also to check availability of targets of ServiceCallouts, availability of chained proxies, availability of keys in KeyValueMaps... In other words there is an entire domain of runtime dependencies.

So I think while the check would provide some immediate feedback, it's not high value, and it's not a true "answer" to the question, "Will my proxy successfully handle inbound requests?"

To get an answer to that, each person needs to build proxy-specific healthchecks.

[kristianjaeger]

Yeah, I can see what you're saying. However, in most programming languages, C#, Java, C++, nodejs, etc... one gets early feedback if a dependency is missing. If Apigee does not want to build that feature that means that the customers need to do so. That's fine it just takes time... Cheers.

[rgonzalez-1]

Here's the approach that I've implemented before in a CICD pipeline:

1. List the API proxies (multiple or a single environment)
2. List the Revisions for each proxy
3. Flatmap results (you'll end with a collection of revisions).
4. List Policies per revision.
5. Flatmap again (you'll get a collection of policies)
6. Look for a naming pattern on the policies (shared flow prefix) and return the mapped proxy names. This can very easily be done within a node.js app in Edge or a Javascript callout.

[kristianjaeger]

Thanks for the tip! Cheers.