Suggestion - avoid making flow too coupled with Fn specifics

[fadams]

Hello. I'm relatively inexperienced with Fn and I haven't done much with Flow, but it seems like an interesting approach.

TBH when one considers Microservices and Serverless a lot of the thinking seems to happen around how to deploy function/service endpoints in a scalable way, but there tends to be very little around how to orchestrate or choreograph non-trivial workflows so it's good to see this being considered.

It does, however, strike me that the problems of hosting services or functions and running business workflows although obviously related are actually somewhat orthogonal.

So what I'd like to suggest is to consider evolving Flow such that it is agnostic as possible as to the endpoints of the functions that it is triggering. I was thinking about this when skimming through this https://github.com/fnproject/flow-lib-go where, in the section "Can I invoke other fn functions?" the suggestion was

flows.CurrentFlow().InvokeFunction("your_function_id", req)

but why constrain it to use a Fn function ID? From what I've seen most serverless frameworks seem to support the notion of triggers and most seem to be handling JSON based arguments so I can't help wondering whether being able to specify a trigger endpoint e.g. http://10.192.0.2:30090/t/goapp/gofn or some config to map function names to trigger endpoints might allow Flow to become a more generic orchestrator. Similarly things like configurable JSONpath manipulation might make any invocation parameters more agnostic of the FaaS/Microservice platform.

I note that Fn has some hooks to the serverless framework so it's clear that the idea of Hybrid/Cloud agnostic deploment has been considered, so this is merely a suggestion that allowing a level of agnosticism over the back-end services for Flow could be useful.