[primitivesuave]

I think an interface providing proper abstraction hasn’t been properly built yet. Imagine every API call to Amazon was a block in a flow based system- some of those endpoints have hundreds of options and multiple accepted input formats, so designing an abstraction layer that doesn’t add more complexity than it takes away is a difficult problem to solve.

[loa_in_]

We tend to design API calls over the net as stateless. It's more efficient to implement in a server and prevents abuse (keeping client states on servers for unknown amount of time lead to DoS attacks).

A flow based system would require more flow on the other (server) side. Imagine each sentence to be a request in the following, and how many avenues of potential service abuse it could bring. That's why we avoid designs like this today.

Here lets's begin a new (cloud?) server definition. Inside this server definition let's begin network specification. Inside this network specification let's begin open ports specification. Here, there's a batch of ports we computed we need. Here, there's another batch of ports we need. End network specification. [...] Let's get back to that port spec, because of something emergent. [...]

[primitivesuave]

Thanks for this perspective, I think from my naive standpoint I would build a flow-based system at the application layer and simply code generate/translate to standard networking calls.

However even with such a paradigm I could see plenty of potential for abuse, even unwittingly - while sequential programming forces you to try-catch, flow based programmers may end up connecting the “error flow” back to the original flow that caused the error, creating an infinite loop that would be much harder to debug.