Hook.io and NoFlo
Henri Bergius
I'm the author of NoFlo, a Flow-Based Programming environment for
Node.js:
https://github.com/bergie/noflo
In nutshell (from Wikipedia):
> In computer science, flow-based programming (FBP) is a programming paradigm that defines applications as networks of "black box" processes, which exchange data across predefined connections by message passing, where the connections are specified externally to the processes. These black box processes can be reconnected endlessly to form different applications without having to be changed internally. FBP is thus naturally component-oriented.
After some look at Hook.io, I think there is quite a good match
between the projects: Hook.io provides an actor model for Node.js
applications, and NoFlo could provide the "coordination language" for
how the different hooks are connected.
What do I mean with coordination language?
Current examples of Hook.io are a bit chaotic: any process can emit
and listen to any messages. In large-scale applications this can
easily lead to a "callback spaghetti" where events cause unwanted side
effects.
Combining Hook.io with NoFlo would provide a solution, as in this
setup hooks would listen and emit events, but the way they would be
routed to other hooks (by namespaces) would be governed by the NoFlo
network. You define a NoFlo graph, add the components (hooks) that you
need, and connect their ports (events) together. After that it would
be normal hook.io operation, except that NoFlo is also capable of
connecting and disconnecting components as needed.
The terminologies would map pretty well:
* Hook.io hook is a NoFlo component
* Hook.io hook listening to an event basically has a NoFlo inPort
* Hook.io hook emitting an event basically has a NoFlo outPort
Current NoFlo components look like this:
https://github.com/bergie/noflo/blob/master/src/components/ReadFile.coffee
which is not very different from a Hook.io hook:
https://github.com/hookio/helloworld/blob/master/lib/helloworld.js
With NoFlo, Hook.io would gain:
* A way to separate hook definitions from the way they are connected
with each other
* Domain-specific language for defining these connections:
https://github.com/bergie/noflo/blob/master/examples/linecount/count.fbp
* Quite a lot of new hooks (we now have about 60 in NoFlo repository)
* Web-based UI for defining and visualizing the connections between
hooks
http://universalruntime.tumblr.com/post/8998693776/node-js-powered-web-server-written-with-the-noflo
NoFlo would gain:
* A reliable crash-only model for the components
* Cross-network (and between server and browser) flows
* Some new very interesting components
* Better-designed event model
If this sounds good, I could start making a proof-of-concept next
week.
/Henri
PS. A reasonably good article on Flow-Based Programming:
http://drdobbs.com/go-parallel/article/231400148?pgno=1
Herman A. Junge
What is your propossal for two or three cases of use, in order to work them?
hermanjunge
Sent from my iPhone
Martin Wawrusch
Henri Bergius
On Tue, Oct 11, 2011 at 12:30 PM, Martin Wawrusch <mar...@wawrusch.com> wrote:
> * The actor layer (hook.io) needs to remain as lightweight as possible.
Certainly. NoFlo should extend how Hook.io works, but Hook.io should
be fully operational without it.
> * I would love to see a standard but optional meta data layer that describes
> a hook (events, directions, types, namespaces) for discovery through tools.
> This should probably be part of the package file.
Agreed. That is basically what a NoFlo component would do, wrap an
existing hook with this metadata.
One idea I've been toying with was being able to declare the event
payload with JSON schema (http://json-schema.org/), so for example the
drawing tool I'm working on could know what can be connected with
what.
> * I do not like that NoFlo combines multiple components in one npm (actually
> the core npm), the hook.io approach with one component per npm will be
> better in the long run.
The current solution is an interim one. I was thinking of having
components grouped by an area of functionality (say, components
related to HTTP serving and request handling) in an NPM package. And
then having a browserify-like additional key in package.json where you
can declare the components a package provides.
This way we can easily know what components/hooks user has installed.
> * I really like how clean the Coffeescript implementation of a component is.
> I am writing my first hooks right now and I am struggling with this a bit in
> hook.io
Thanks! I'm still not 100% happy with the component API, but it is
indeed cleaner than what my first version was.
> * I think NoFlo DSL and routing should sit one layer above core hook.io, as
> a specialized hook
Yep. Hook.io provides the "plumbing", and NoFlo provides a
higher-level way of handling how hooks are connected with each other.
> * I am sure the community here will gladly help in creating hooks from the
> components, if you coordinate it.
That'd be great. I first need to port NoFlo to run on Hook.io, and do
the API design on how the relation between "plain Hook.io hooks", and
"Hook.io hooks that are also NoFlo components" looks like.
Oh, and I hope soon we'll have a nice way of visualizing (and drawing)
how your hooks are connected in the NoFlo graph:
http://www.jointjs.com/demos/run.html?unit=devs
/Henri
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Jabber: henri....@gmail.com
Microblogs: @bergie