Flow Based Programming With NoFlo



The Gist






  • NoFlo’s graphs can be created via JSON.
  • The UI does not generate any of its own code.
  • Custom components can be created and tested for any purpose.

Flowhub’s programs arrange logic into “graphs” whose “nodes” serve as program components. Nodes are setup to react to Incoming Information Packets (IIPs), such that a node receives and then outputs actions based on the component type. The majority of the time in OOP, developers are concerned about how components are going to communicate, whereas with FBP, the only concern involves which components to connect. A quote from NoFlo’s original Kickstarter page summed up a version of the Mythical Man Month quite well:

“That’s what building software is; it’s how much scaffolding you can erect before it collapses of its own weight… It doesn’t matter how many people you have working on it… A software development project gets to a certain size where you add one more person, the amount of energy to communicate with that person is actually greater than their net contribution to the project so it slows down.” – Steve Jobs

NoFlo components can react to varying inputs, including HTTP requests and APIs, and can output to different targets, such as databases. You can even integrate a NoFlo graph into an existing JavaScript project by using a Node.js library. This flow challenges the one-step-at-a-time paradigm that governs most programming logic, especially when we consider the vast amount of input/output, and bloated data sources that modern interfaces deal with as they grow larger.

The insecurity that this philosophical shift creates among developers is palpable and understandable. What if the job of the developer were to be eliminated, only to be swallowed up by designers and product managers who could easily understand how to connect pieces of cookie-cutter components that fit every task imaginable? In the end, however, it may be that the flexibility of FBP has benefits that far outweigh any consequences to the software development industry. There are also questions of building custom components, implementing FBP with existing code, and potential user-interface limitations due to the visual nature of this kind of programming.

Case Study

Let’s embark on a quick experiment with NoFlo’s FBP to find out about the interface firsthand. Signup requires a GitHub account, leading to the option of seamless deployment to a repository. Depending on the runtimes that you have available on your plan, the interface may vary:

Flowhub Interface

A handy map gives you bearings when you’ve zoomed to a level where only pieces of your entire network can be seen. This feature and other methods of navigation would be crucial on complex flows that could literally take up buildings of readable space. For this reason, scaling is as easy as a pad swipe or a finger-pinch (touch) away.

Flowhub Layout

Moving the viewable area around takes a click-hold-drag action or similar touch action, and all-in-all, movement across the interface is intuitive. The search bar, when clicked, lists all the ready-made components, spanning from CSS elements and actions, to simple database calls, to common math functions and drawing features.

Currently, you can preview your output in a browser, as well as build and test custom components, through a text-editor interface:

Flowhub Editor


Once I developed a feel for initiating IPs, and laying aside worries about text, the visual approach lent itself to a certain freedom. Had the project had more layers of complexity, I sense there may have been an even greater concept for the physical logic flow in the program. Collaboratively, this visual depiction looks like a sketch, or some graphical pseudo code that some developers use to outline the basic flow of a program before we translate it into a specific language. As seems to increasingly be the case in many disciplines, one can imagine a world with far less text and far more pictures.

Experiment with the project code or in the browser (once signed-in with Github).

Free book: Jump Start HTML5 Basics


  • Test McTest

    Reminds me very much of the common pattern of developing ETL (Extract, Transform, Load) in data warehousing and modelling environments. They’re all connecting the data streams..

    I did chuckle at this comment you make though:


    In my experience that’s really not going to happen. Despite being a diagram, “programming” this still requires logical/analytic thinking and application. Sure these other people might be able to click and drag, but once something of any complexity is in place, one can’t just have a person click and drag a function into place.

    Again, look at ETL and the complexity that the real world throws you and the project failures that also come about.