Flow Based Programming With NoFlo

It is amazing that with our lightning-fast technology cycle, a workflow born out of the era of bellbottoms and turntables is making a revival. Back in the 1970s, an ingenious engineer by the name of J. Paul Morrison crafted a banking system that resembled a common flowchart. His software concept was quietly credited for having the ability to stream complex logic visually, in a way that could be grasped by non-technical personnel. Years later, a movement is surging that professionals in the technology industry would be wise to pay attention to. This article explores Flow Based Programming, or FBP.

The Gist

Since the moment when Morrison’s FBP banking system first came to fruition, little has been officially mentioned regarding the disruptive concept. However, FBP had actually been popping up in industries away from the software development epicenter: visual effects, film, artificial intelligence, enthusiast programming, etc.

The need for visually-appealing program flow, and a step away from object-oriented programming seems like steps towards more understandable, flexible code. Why then, has FBP been slow to reach universal acceptance among designers, product managers, and most importantly, developers?

There is growing evidence that this unanswered question may have been successfully dealt with via the advent of the Flowhub network, and specifically NoFlo for Javascript.

NoFlo

Highly-lauded tinkerer Henri Bergius, and Meemoo creator Forrest Oliphant formed two crucial pieces of a Kickstarter that gained tremendous support worldwide. The NoFlo project, while ambitious, had a few traits that set it apart from Yahoo Pipes, Quartz Composer, and other successful but limited FBP-like systems of the past:

• NoFlo’s graphs can be created via JSON.
• While the hosted infrastructure is closed, the underlying programming framework is open source.
• The UI does not generate any of its own code.
• In addition to the NoFlo/JavaScript runtime, similar runtimes are being built for Java, Objective-C, and other languages.
• 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:

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.

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:

Conclusion

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).