[mks]

This

  > NoFlo graphs instead are only the coordination layer 
  that manages the control flow of your software.

reminds me a lot the whole SOA/BPEL/BPMN mess that was hot few years ago in enterpriseland. The surge in visual programming just resulted in developing the same logic with less powerful tools in languages that were not designed for programming (XML and in this case JSON).

These kind of tools focus on the wrong side of the problem. It is not about how to connect the nicely designed services, but how to actually get services to be nicely designed. Once you have service that can be easily connected in the visual tool, it can be trivially used from the conventional programming language as well.

Reasons why services can not be just trivially composed include:

  - every service that is comprehensively mapping real problem is inherently complex 
  (even for seemingly simple things like address geocoding)
  - any two services will have slightly different APIs 
  (consider various signatures of substring method in various languages)
   and oftentimes the backend system details 
  - limitations are leaking over the service API
  (datatypes, formats, paging, ...). 

For these reason there exists the large branch of programming that deals with integrating services (sometimes called Enterprise System Integration) that basically wraps, formats and preprocesses data before shoving them to the target service.

For restricted domains - it could probably work. But for general service integration within larger company, the best approach so far has been a lightweight approach with mixture of Spring Integration and plain old Java.