Flow-Based Programming for JavaScript
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 95 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/32317 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
FrOSCon 201730 / 95
4
8
9
15
20
22
23
24
25
27
29
32
36
37
38
39
40
45
46
47
48
49
50
51
53
54
59
63
64
65
74
75
76
79
83
84
86
87
88
89
91
92
93
94
95
00:00
Computer programmingVideo projectorSemiconductor memorySoftware developerDataflowGoodness of fitComputer animationEngineering drawingDiagramLecture/Conference
01:06
Game controllerMereologySoftwareSystem callBuildingPattern languageFunctional (mathematics)Control flowIntegrated development environmentFunctional programmingMultiplication signWeb 2.0Dependent and independent variablesWebsiteBitDatabaseAnalytic continuationServer (computing)CodeParameter (computer programming)Computer animation
02:33
Parameter (computer programming)Functional (mathematics)Projective planeComputer programmingServer (computing)Process (computing)System callNetwork topologyLoop (music)Vertex (graph theory)Instance (computer science)Computer animationLecture/Conference
03:26
Shared memoryBitComplex (psychology)SoftwareMultiplication signTexture mappingSource codeOpen sourceLecture/ConferenceJSONEngineering drawingDiagram
04:30
Primitive (album)Computer programmingDistanceMultiplication signSoftware developerComputing platformInformation technology consultingCAN busModel theory
05:24
DataflowComputer programmingComputer scienceImplementationArrow of timeProcess (computing)CuboidGraphische ProgrammierungRevision controlMeeting/InterviewEngineering drawing
06:11
Punched cardCore dumpConfiguration spaceExecution unitVirtual machineRow (database)Computer programmingMultiplication signRouter (computing)outputFlowchartGraph (mathematics)PlastikkarteFunction (mathematics)Game controllerComponent-based software engineeringLogicSoftwareControl flowEngineering drawingComputer animation
07:31
Formal grammarComputer programmingObject-oriented programmingWeb browserProcess (computing)BuildingLecture/ConferenceComputer animation
08:37
Two-dimensional spaceDataflowString (computer science)Streaming mediaGraphics softwareSoftware frameworkAreaPattern languageProgramming paradigmVideoconferencingFacebookVirtual machineFluxVisual programming languageVisualization (computer graphics)Sound effectComputerSoftwareSoftware developerComputer programmingTensorrechnungProcess (computing)Computer animation
10:36
WordBitCodeComponent-based software engineeringGraph (mathematics)Computer fileScripting languageLibrary (computing)Descriptive statisticsoutputMereologyComputer programmingUser interfaceType theoryInformationRight angleFunction (mathematics)Source code
11:51
outputBuffer solutionProcess (computing)Component-based software engineeringDataflowFunctional (mathematics)Computer programmingMereologyMultiplication signFunction (mathematics)
12:47
Component-based software engineeringElectric generatorParticle systemDifferent (Kate Ryan album)Process (computing)Web 2.0Traffic reportingFigurate numberForm (programming)BitComputer animationSource codeXML
13:32
Connected spaceComponent-based software engineeringParsingServer (computing)Graph (mathematics)DataflowMereologyVertex (graph theory)Right angleComputer animation
14:18
ParsingMobile appConfiguration spaceConnected spaceServer (computing)MereologyService (economics)Default (computer science)CASE <Informatik>Point (geometry)Graph (mathematics)Number
15:02
Electronic mailing listComponent-based software engineeringElectronic data processingTexture mappingServer (computing)Graph (mathematics)Web 2.0Lecture/Conference
15:46
Graph (mathematics)Graphics softwareObject (grammar)ParsingSubject indexingInstance (computer science)Electronic mailing listServer (computing)Uniform resource locatorComputer animation
16:46
Graphics softwareProjective planeWeb applicationComputer programmingSoftwareIntrusion detection systemDataflowNumberComputer animation
17:30
Web applicationRevision controlDataflowWeb 2.0Process (computing)Web browserCodeComputer fileServer (computing)Digital photographyMobile appDifferent (Kate Ryan album)Proper mapFilter <Informatik>Component-based software engineeringGraph (mathematics)Game controllerOpen sourceSource codeCASE <Informatik>Software testingCuboidRight angleSubgraphInstance (computer science)Computer programmingSoftware frameworkScripting languageLibrary (computing)WebcamComputer animationLecture/ConferenceProgram flowchart
19:55
Graph (mathematics)Vertex (graph theory)CuboidComponent-based software engineeringMereologyHierarchySubgraphBitComputer programming
20:47
CodeCollaborationismData storage deviceINTEGRALMathematicsProjective planeRevision controlRight angleWeb 2.0Web browserIntrusion detection systemClient (computing)SoftwareServer (computing)EuropeanaSubject indexingWeb applicationProgram flowchart
21:29
Projective planeGame theoryWeb portalTransformation (genetics)DataflowTableauTexture mappingAreaState of matterRight angleGraph (mathematics)Cartesian coordinate systemComputer animation
22:56
Visualization (computer graphics)SoftwareMicrocontrollerFilter <Informatik>Graph (mathematics)Sound effectAreaVisual programming languageComputer animation
23:48
Integrated development environmentWeb applicationDataflowWeb 2.0Android (robot)Intrusion detection systemGraph (mathematics)Communications protocolDigital electronicsWeb browserDiagramProgram flowchart
24:45
Server (computing)Process (computing)Cartesian coordinate systemDifferent (Kate Ryan album)Transportation theory (mathematics)Web 2.0Peer-to-peerMereologyComputerInstance (computer science)Run time (program lifecycle phase)Goodness of fitAbstractionPattern languageWeb applicationMiddlewareWeb browserComplex systemGraph (mathematics)ChainTracing (software)Computer programmingUnit testingDataflowGraphics softwareProtein foldingDebuggerMessage passingComputer animationLecture/Conference
26:47
Library (computing)Computer programmingWeb 2.0Component-based software engineeringFunction (mathematics)Direction (geometry)AudiovisualisierungChainIntrusion detection systemDataflowWeb applicationProjective planeMiddlewareGroup actionIntegrated development environmentRun time (program lifecycle phase)BitCartesian coordinate systemInternet der DingeTraverse (surveying)Program flowchart
28:27
Video gameAreaSoftware testingComponent-based software engineeringServer (computing)CodeCartesian coordinate systemMathematicsProcess (computing)Instance (computer science)DataflowProjective planeGraph (mathematics)Perfect groupSource codeAsynchronous Transfer ModeOpen source
29:37
Projective planeSharewareWeb 2.0BitServer (computing)Representational state transferGoogolElectronic mailing listPay televisionDatabase
30:24
Instance (computer science)Server (computing)ResultantCASE <Informatik>
31:08
Mobile appWeb 2.0Web browserBitProjective planeDataflowWeb-DesignerPoint (geometry)Server (computing)
31:50
Web 2.0Computer programmingWeb applicationSystem programmingFiber bundleHypermediaVideo gameComputer fileDataflow
32:34
DataflowDigital rights managementFluxGroup actionLoop (music)State of matterPattern languageAnalytic continuationTask (computing)Phase transitionDiagram
33:20
System programmingBitCodeGraph (mathematics)User interfaceExpressionFunctional (mathematics)Server (computing)Web 2.0Projective planeResultantINTEGRALRun time (program lifecycle phase)Hydraulic jumpMobile appDataflowCASE <Informatik>Cartesian coordinate systemComponent-based software engineeringComputer animation
34:40
Graph (mathematics)Library (computing)Operator (mathematics)DataflowIntegrated development environmentBuilding1 (number)Intrusion detection systemImage processingResultantUser interfaceGame theoryRight angleCommunications protocolComputer animation
35:41
DataflowServer (computing)Operator (mathematics)Plug-in (computing)Graph (mathematics)Component-based software engineeringGame theoryState of matterProcess (computing)Single-precision floating-point formatMultiplication signComputerRun time (program lifecycle phase)Square numberIntegrated development environmentField (computer science)Vertex (graph theory)Message passingPhysical systemInternet der DingeComputer animation
36:49
Message passingState of matterLogicComponent-based software engineeringDataflowComputer programmingInformationNeuroinformatikVirtual machineOperator (mathematics)Different (Kate Ryan album)Graph (mathematics)Projective planeQueue (abstract data type)CASE <Informatik>Connected spaceComplex (psychology)Process (computing)CuboidVertex (graph theory)Power setMetric systemOpen setGame controllerTrailBuildingInternet der DingeBit
39:57
MicrocontrollerProjective planeComputer programmingIntrusion detection systemNumberRun time (program lifecycle phase)Term (mathematics)Computer animation
41:09
Electronic mailing listComputer programmingGame controllerSound effectSoftware framework1 (number)Run time (program lifecycle phase)NumberComputer animation
42:01
Immersion (album)Different (Kate Ryan album)DataflowProduct (business)Physical systemState of matterProjective planeUniform resource locatorRevision controlComputer animation
43:25
Physical systemOperator (mathematics)Cartesian coordinate systemIntegrated development environmentDataflowPlanningComplex (psychology)BuildingFunction (mathematics)Set (mathematics)Right angleOverhead (computing)Web browserGame controllerProjective planeComponent-based software engineeringStreaming mediaRun time (program lifecycle phase)outputProgramming languageOperating systemGastropod shellMusical ensembleComputerComputer file10 (number)Scripting language3 (number)AreaReal numberSingle-precision floating-point formatFunctional (mathematics)Content (media)Line (geometry)Different (Kate Ryan album)Replication (computing)LengthRevision controlMicrocontrollerPairwise comparisonWeb 2.0Computer clusterServer (computing)Web applicationComputer programmingLecture/Conference
47:46
Component-based software engineeringServer (computing)WritingComputer programmingWeb browserInstallation artUser interfaceCodeProcess (computing)DataflowGraph (mathematics)Communications protocolComputerRun time (program lifecycle phase)Computer animation
49:05
Library (computing)DataflowSystem callFingerprintCodeComponent-based software engineeringUser interfaceComputer animation
49:46
DataflowStreaming mediaPattern languageOpen sourceBuildingSoftware developerStylus (computing)Projective planeStream cipherCodeMultiplication signSet (mathematics)Computer programmingObject (grammar)Exception handlingSinc functionRoboticsGraph (mathematics)Component-based software engineeringGraphics softwareLecture/Conference
53:28
Computer animation
Transcript: English(auto-generated)
00:07
So, sorry about the technical difficulties. This is always the most difficult thing in technology and especially technology conferences is projectors. I don't know how that is, but it's never really plug and play.
00:23
Anyhow, I'm here to talk about flow-based programming for JavaScript. So first of all, how many of you know anything about flow-based programming or data flow programming? No hands. Toby, you should raise a hand there. Are you alive?
00:43
Yeah. Okay. How many of you are JavaScript developers? That's the next question, then. JavaScript developers. A few hands. Okay. Good. So, yeah. Quick introduction. I'm Henry, originally from Finland, now living in Berlin for past fiveish years.
01:03
I think it's been this is probably my fourth or fifth FrostCon. So always fun being here, having Kelsch. Great. So let's get to the subject. So like in general, like one important part of building software is, of course, the control
01:26
flow. So, if you've done, for example, PHP or Python, where things are usually synchronous, you're probably very familiar with the call and return pattern. So you call some function, you assign its return value to some variable, and then basically
01:44
the execution of your software stops until whatever the function returned. And, yeah. This is, of course, a little bit problematic if, let's say, you just built a web server and you might have more than one person visiting your website at the same time.
02:01
And you know, your code is right there waiting for a database query to return, and hence it can't respond to the other HTTP request. Some environments, like with PHP, usually you work around this by having multiple PHP processes so that there will hopefully be one available when a request comes in.
02:25
In JavaScript land, in a lot of functional programming, we use the continuation passing style. So in this situation, what we do is we call a function, we give it whatever arguments we want, and then we give it another function as an argument saying, hey, when you have
02:42
results, please call me. And with this, for instance, in Node.js, we can serve thousands of users with a single Node.js process because the main loop of the program is not being blocked by waiting for something to happen.
03:00
Instead you're using these callbacks where, you know, let's return back to this execution when that thing happened. So with that, you know, you're never really blocked. The downside, of course, is that you end up with the Christmas tree. At least my first Node.js project always looked like this.
03:23
I'm seeing some nodding, so I guess that's an experience many people in the audience share. And so, I mean, especially when you start getting to a bit more complex piece of software, it would be really nice to have a map.
03:41
Because we humans, we have very good spatial understanding. We've developed it over, you know, a long time, many long years in the savanna throwing rocks at other animals. So we're very good at, like, where things are in spatial relationships. And with the visual map, we can utilize that to understand complex things like software.
04:06
This is actually, like, when you read source code, this is what you do in your brain anyway, right? You have to parse the source code, like, okay, talk to that, talk to that, and you build this kind of map. That's why when you get interrupted, you lose all of that idea, and then you have
04:21
to start building the map again. But yeah, it would be very nice if software would be represented this way right away. So, that's kind of where I come to the picture. I bit over five years ago, I was kind of transitioning from mostly doing PHP programming
04:44
to more JavaScript and Node.js. And I was very kind of frustrated at the primitive tooling and kind of developer support that that platform had. Luckily, I was doing some consulting on the US West Coast, and I had to drive long distances
05:05
between Portland and Southern California in this pretty nice scenery. And that gave me a lot of time to think about things and read some CS papers in motels at night.
05:23
And one of the things I read about and which really clicked for me was the idea of flow-based programming. This is a very cutting-edge new idea in computer science. This gentleman here, Paul Morrison, invented it in late 60s, early 70s at IBM.
05:43
And when he retired in 90s, he wrote the book about it. There's now a second edition that you see there. And he's also written some implementations for Java, for C sharp. I thought, hmm, this kind of boxes and arrows method really fits with how I think
06:03
about software. And so, I went on implementing JavaScript version. But before we get to the nuts and bolts, I think you need to understand the core ideas of where flow-based programming comes from.
06:20
So at IBM, at that time, most of their big stuff was done using these unit record machines, basically big machines that work on punch cards. So you have punch cards that are data. And you have maybe punch cards that are configuration that you feed to the machine.
06:40
And then you have these lovely flow charts that tell the bigger control flow of the software saying, basically, if there's cards coming in this tray, then you, person in white lab coat, will take those cards, take them to the next machine, feed them to slot this, and then the software execution will continue.
07:01
And so flow-based programming is exactly this, except, you know, without the lab coats. So we have components, little pieces of software that have input ports or trays, whatever you want to think about them, and output ports. They execute some logic.
07:21
And then we have a graph that tells how the data flows from one component to another. And that's basically all of what flow-based programming is about. Paul Morrison, of course, wasn't the only one to come up with these kinds of ideas. You may have heard of this gentleman here.
07:42
He formalized these ideas as something called object-oriented programming, which you may have heard of. His original ideas sound a lot more like flow-based programming, but then somehow you get to Java. I don't know how that came to be.
08:03
Another thing where this might sound familiar is if you've ever used a Unix or Linux command line. There's, again, the idea of little programs that do one thing, and then you pipe stuff together to achieve more complex things.
08:23
I mean, seriously, like, this is actually a flow-based program, one that you may have had to write yourself if you had a nasty runaway browser process. And, basically, what we do is if these textual pipelines are usually very one-dimensional.
08:46
So what we do with no flow is we try to make try to bring that to the second dimension. And we lost the stream for some reason. Okay, great. Yeah. So that's what we're doing.
09:00
And, now, since none of you raised a hand yet, I have to pose the question instead. Hasn't this been done before? Like there's been all kinds of promises of visual programming from grails in the 60s onwards. And, yes, a lot of this has been done before.
09:23
And actually, this kind of data flow visual programming has become the dominant paradigm in various narrow industries. In a lot of visual effects industries, you use these nodal editors to build things.
09:44
Same thing with video processing, video streaming. Now we have some new things that follow these concepts like TensorFlow that you may have heard of, this machine learning framework that Google released.
10:00
A lot of the ideas in Facebook's flux pattern for React development comes from programming. So there's a lot of kind of areas where this kind of paradigm has been successful. But it hasn't worked as a general purpose programming paradigm. And that's kind of what we try to do here.
10:21
We try to build tools that would allow you to essentially build any kind of computer software using flow-based programming. So back to NoFlow. Word of warning, there's a little bit of code here. Just to explain the basics of how NoFlow works.
10:43
So as I said, there are these two concepts in flow-based programming. There are components. And then there's the graph that determines how components are connected. And I mean, components, usually you write them in NoFlow, you write them in JavaScript, CoffeeScript, TypeScript, whichever flavor of something that compiles to JavaScript you
11:06
like. And I'm not expecting anybody to memorize this. I just wanted to go through the kind of important parts here. So if you write the component, yeah, you load the NoFlow library. You provide a get component interface in your file where you create, instantiate
11:26
a NoFlow component. Now you have a component, right? Which you eventually will have to return there. Then to provide an interface to that component, what you do is you add some ports. So you can add input ports. You can give them a type if you want.
11:41
You can give also more information like a description so that users using your component will understand how it works. And then you add output ports. And then finally, the important part is you provide a processing function. So this function, this callback here that you gave, will be called every time your component receives a packet.
12:06
And so that's something that comes from the outside. The components don't know anything about the rest of the program they are in. They just know, hey, I got the packet. And here you can make decisions on whether you have enough input to do something or not.
12:23
Once you have enough input, you read the packets from your input buffers that you want to work on. Then you do your work. And then in the end, you send some output packets out. So this is the very basic no-flow component. They are typically asynchronous.
12:41
You can also write synchronous components if you have something where that makes sense. But the important thing is usually you don't have to write components at all. There's hundreds, probably thousands of no-flow components out on NPM for pretty much any particular purpose. So from payment processing to report generation
13:05
to dealing with a lot of different web APIs, there's tons of components out there. And people in the community are writing more. So in a lot of situations, you can just grab a few components, maybe massage them a little bit to fit your purpose, put them to a graph,
13:22
and you're good with it. Then maybe write a couple of specialized components for something that you need. So that's how you have a component. You either install it from NPM, or you write one for yourself
13:41
or get somebody else to write it for you. Then the next big thing is, how do you define a flow? So because some people like text, I start with that. So this is a lovely syntax for defining flow-based graphs that IBM came up with, I think, in the early 80s.
14:05
And it's reasonably straightforward. You can define a connection between. So here we have a node called server. Here we have a node called parse. The server uses a component called this. The parse uses a component called that.
14:20
And here we make a connection between the app port of the server to the app port of the parse. You can also send literals to do configuration when the graph starts. So in this case, for instance, we are sending the number 80 to the port of the server.
14:41
So basically, what we're doing there is we're telling, this is an HTTP server. So we're telling it, hey, when you start, listen to port 80, which is the default port for HTTP. And then we go on to define some stuff. Like here we provide a resource called image. We say, OK, you respond in path image.
15:03
And then it has ports for like create, destroy, list, et cetera. So basically, when you put or post to slash image of that web server or you delete, then the request packet would be sent out to that pipeline. And then you can do whatever data processing that would imply.
15:24
And that's a perfectly fine way of defining no-flow graphs. But to be honest, it can get tricky. Because here, you have to constantly memorize what ports do my components have. And you still don't get the proper visual map
15:42
of how things are. And so we built some tools for that too. Here you can see the exact same graph that was here as text. This is how it looks like in our visual editor. So here you can see we have the HTTP server.
16:02
We give it the port 80. Might be a little tricky to see from behind. And we have a body parser, which just basically parses HTTP requests. So if somebody sends you JSON, for instance, or URL encoded data, then it turns it to a native JavaScript object there.
16:22
And then we send that off to the image resource. And now here, you very conveniently see that even though we just dealt with create and destroy, there's also all these other ports available. So we could easily like, OK, if you want to do index with just listing off the image
16:41
resources you have, then you would just wire something there. The visual editor originally was built only for NoFlow. We financed it with a Kickstarter we did in 2013. Back then, this was the fifth largest software Kickstarter.
17:03
Of course, by now, the sizes of Kickstarter projects have gone through the roof. So I don't think we are anywhere in the top 100 anymore. But back then, this was a big deal. And so with that funding, we were able to build a web-based IDE for NoFlow programming
17:23
for other flow-based programming. It's all MIT licensed out there. But for convenience, my company also provides a hosted and supported version called Flowhub. And generally, because this is a client-side web application,
17:44
using our hosted version is the recommended way. Because anyway, all of the code, all of the stuff lives inside your browser process. There's not much that our servers do for you, except give you the necessary files for the IDE.
18:02
So how does it look like? Again, it's a little too light here to see properly. But you get the nice big canvas for defining your data flow. In this case, this is a photo booth client-side web app.
18:21
So with Flowhub, when you work with client-side web apps that are done in NoFlow, what you get is you get the little iframe here in the corner that's actually rendering the app as it's running. And in this case, yeah, it's a photo booth. So you can start your webcam, and then you can go through different GL filters for the images.
18:44
And then you see right here what's going on. And yeah, on top right, you have the other controls for the execution. You can stop the program, et cetera, et cetera. And on the left, you can add new components and all that stuff.
19:02
In addition, in Flowhub, you can also, or in NoFlow UI, if you use the open source version, you can also write components there. You can see the source code of components you've loaded from libraries. You can write your own. Here's, for instance, a little component done in CoffeeScript
19:21
in this case for parsing markdown. And then there's the tests for that on the right. Another nice thing that you can do, this is something I probably should explain first. So in NoFlow, and generally in FPP, we have two ways to get a box in your graph.
19:43
One is to write the component. This is the typical way for simple things. The other one is to create a subgraph. So that's basically another NoFlow graph where you export some of the ports from your components, and then you can use that graph as a component in another graph.
20:03
And to make things convenient to work with, in our IDE, you can also select a bunch of nodes. When you've built a program and maybe the graph starts being a bit complex, you start to want to impose some hierarchy and maybe reuse some bits there.
20:23
What you can do is you just select a bunch of nodes, and then you right click and you select graph, and then all of those nodes, all that whole part of the graph will become a subgraph. In this graph, it will become one box, and then you can go and edit the insides of that box.
20:48
Another thing we have is, as I said, when you work with the browser-based editing tools, all the code actually lives inside your browser. We don't send it to our server at all.
21:00
It's all in the IndexedDB, which is kind of a persistent storage for HTML client applications. But of course, when you work with real software, that's not quite enough. You usually want to use version control and collaborate with others. And for that, we have GitHub integration.
21:20
So you can push and pull code changes with your GitHub project right from the web IDE. And yeah, that's a pretty convenient way to actually do these things in a bigger project.
21:42
And just to give you an example of, I mean, a lot of the applications that people have built with NoFlow have been more kind of business-oriented, but this is just a little fun project we did at the C-BASE hackerspace in Berlin. How many of you know the game Ingress? A few.
22:00
Pokemon Go? Yeah, okay. Basically the same game, two different phases. It's made by the same company. So at C-BASE, we have a lot of Ingress players who come there to drink beer in the evenings, and we wanted to do something. So we built this little table, kind of a bar table,
22:22
with the map of the area around C-BASE in Berlin, with lights representing the portals, and showing the kind of state of play, so you can sit there and have beer and see how your faction is winning the game. And yeah, all of that was done in NoFlow.
22:42
Here's actually the main data flow graph where we fetch data from the Ingress API, we do some transformations to decide what state the table should be in, and then finally, on the right there, we tell two microcontrollers to do the things with the lights.
23:01
And yeah, that kind of stuff, with visual programming, it's a lot of fun to work with, because generally you get, like with NoFlow, this is something I probably should mention too, is you generally don't have to stop your piece of software to change it. You can actually rewire the graph while the software is running, and that's really great when you're working
23:20
with something like animations. Like, I'm debugging a little animation there, and I'm modifying the software as it's running without having to stop, compile, restart, all that stuff. So I can just tweak the values and add some filters in between, and then hopefully get to the effect I wanted. So when you're doing visual things,
23:40
that's really, really nice capability to have. And yeah, as I mentioned, I should probably tell how this actually works. So when we started working on the web-based tool for editing things in NoFlow,
24:02
our original idea was just to support NoFlow on Node.js, because that was the only flow-based environment we actually had. But then, during the Kickstarter, a lot of people started talking, well, you know, I would like to do this, I would like to do microcontrollers, or Android, or whatever,
24:21
and we realized that imagining that everybody would do everything with Node.js is not quite enough. And so what we did was we abstracted the way we communicate from the browser-based IDE to the thing that actually runs your graphs.
24:42
We abstracted that away in a thing called FVV protocol. We implemented a bunch of different transports. Here's a couple. So WebSocket is typically used for communicating with the server process that, for instance, runs NoFlow. We have WebRTC, which is really cool for peer-to-peer communications.
25:01
You can, for instance, if you have an application on your phone that you're debugging on your computer, you can use WebRTC between those two. We have postMessage for client-side applications, and so forth. And what this kind of abstraction did was it opened kind of doors on two sides.
25:22
So one was, okay, here we have our web-based graph editor, but then it allowed people to build other things too. There's things like fppspec, which is a unit testing tool for flow-based programs. There's flowtrace, which is kind of a retroactive debugging tool,
25:41
so you can log traces of how data flows in your graph, and then you can replay and inspect. This is really nice when you work with complex systems. But on the other side, okay, NoFlow was our primary target, but it allowed people to add compatibility to other runtimes.
26:04
So we made NoFlow run also in the browser. That was one nice thing. But then a lot of other things were also built that our web-based tools can interact with. So one example of this,
26:20
I mentioned running NoFlow in the browser. So this is actually, how many of you know Redux? One, maybe, yeah, good. So Redux is another kind of application pattern for building client-side applications coming from the kind of React JS community.
26:43
And a lot of their stuff is related to these middlewares where you have a chain of middlewares, and actions done by the user traverse through the middleware chain. The middlewares may either pass on the action, I'm not interested in that action, or they might intercept it and produce other actions.
27:03
And this is actually the middleware chain of the Web IDE done in NoFlow. So it's very easy to take, when you have these kind of data flow ideas from other environments, it's pretty easy to take those and bring them to NoFlow land. So basically, the IDE itself
27:21
is behaving exactly like a Redux application would, except that it's not done in Redux, and we get to do these kinds of visualizations. So a little bit about how to get it going. On Node.js, if you want to do backend stuff,
27:40
whether it's some ETL tools, or web application servers, or some IoT thing, it's pretty simple. You create a new folder for your project, you prepare your package JSON with npm init, then you install whatever you need,
28:01
including hopefully NoFlow, maybe some components, maybe some other third-party libraries that you're gonna use. The important thing is to install the NoFlow Node.js runtime, so this is an npm packet that provides you with the command line tool to start your NoFlow program and make it available to the IDE.
28:23
When you start that, it's gonna output a URL, and when you click that URL, what you get is what we call the live mode, so the flow of IDE opens in your browser, and you're going to be watching
28:42
the live running Node.js application you just built. You can click on a wire to see the data passing through live and all that, and if you want to actually start modifying it, then you just click edit as a project, and then you're in project mode in Flow Hub, but you can make changes, write some new components,
29:04
edit component source code, change graphs, push to GitHub, all of that stuff, and all the changes you do there are applied live to your server instance, so if you're running some tests or testing manually, whatever you're doing, every change you do will become live right away.
29:24
There's no need to stop the Node.js process, start it again, and all that stuff, including, yeah, if you change some component code, that will also be applied immediately, and yeah, I showed a little example is this one.
29:41
Here's a little bit more comprehensive example, an RSS reader, no UI, just REST API, but basically if you wanted to do your own Google Reader, this little demo project I prepared would be enough,
30:00
so basically here what we do is we, again, we start a web server, then we provide a resource there. If you register or if you subscribe to a new feed, we validate that your subscription is correctly formatted, like you gave the URL that was expected and all that stuff and we save it to the database.
30:20
If you list your feeds, you get the list of the feeds you have, and when you want the news of a particular feed, you go here, and we actually fork off the request there to go and fetch the RSS feed. This is where you would add caching if you really wanted to,
30:42
and then once we get the results, we just serve them out. And again, in this case, this screenshot is from a running instance of this server, so I've clicked on that wire there. You can see it kind of highlighted, and here you can actually see the data flowing through as people make requests to the server,
31:03
so you can see what's going on. And to go to the browser side, you should have probably asked, how many of you work in client-side web development? Nobody, one, two, yeah, three, four, okay.
31:23
Yeah, so all of this stuff, basically the same ideas apply also for the browser. There's a little bit more work in the sense that you have to use Webpack to build NoFlow for the browser. We have a convenience thing here called NoFlow Browser App. This is basically a template project
31:41
that you can take and modify. So again, you fork this project, you add whatever dependencies you need, you build it, you deploy it to whatever web server. It's just some HTML and JavaScript files, so you can drop it anywhere. And then you get the web app,
32:01
and here the URL will be provided as a little button, so when you build the bundle, you can choose whether it supports debugging or not. If it supports debugging, you get this little button here, you click that, and the live program will be opened in Flow Hub. So that's, again, a pretty quick and easy way
32:23
to get to a system where you can have a web application that you can actually modify while it's running. Yeah, as a little example, here's just a quick to-do manager
32:41
where we're using ReactJS as the rendering layer, and you can see the basic data flow here. This is using the flux pattern where the UI sends actions, they get dispatched to the correct handlers, and then state goes back into the UI. So you have this continuous loop of actions
33:02
turning into state changes, turning into actions, et cetera, et cetera, and you can, again, watch it live, so here you can see, okay, we created a task, there we deleted a task, et cetera, et cetera.
33:21
The third way to use NoFlow is, you know, it might be very nice if you can start the Greenfield project where you can start with NoFlow, build a whole system with NoFlow, but usually that's not realistic. You probably have an existing code base where you have some hairy bits that you probably want to first do in NoFlow
33:45
to get that trouble out of the way, and for that we have, in the latest releases of NoFlow, we have this as callback interface. So what this does is you can give it a graph or a textual component, doesn't matter,
34:01
and it returns you a function that you can call. So in this case, we are in a Express app, so a web server. Whenever somebody posts to this image, we would run this graph with the request, and then you get the results out there. So this is a very easy way
34:21
to kind of integrate NoFlow into an existing code base if you don't want to make the jump to full, like, end-to-end NoFlow application, right, from the get-go. Yeah, so I mentioned other runtimes. I think that would be good to bring up a little.
34:41
So with the FPP protocol, we made it possible for other people to build execution environments that the IDE can work with. One of the first ones was something called image flow. How many of you have used GIMP, the image editor?
35:04
Most, yeah. So inside GIMP, there's a library called GEGL, which is actually the thing that does the image processing. GIMP is the UI on top of that, and GEGL is actually a data flow engine, but they never had a visual interface for that.
35:21
So with image flow, what you can do is you can draw graphs using all these GEGL operations. So you can basically build graphs that can use anything, can do anything that you could do in GIMP with your mouse, right? And you can see the live results there.
35:41
If you click on a wire, you can see how the image would look like with just this operation applied. You can run this on a server if you want, but the other nice thing is you can actually use this graph in GIMP itself. So you can create new GIMP plugins using Flow Hub. So that's pretty nifty. You can actually also,
36:01
this one supports component editing, so you can actually go and write new operations and see if you're so inclined. This question often comes up when I'm talking about no flow. So no flow, like it's nice to have this data flow environment, but no flow actually is something
36:21
that only runs in a single JavaScript process. And when you start talking about bigger systems, you probably won't be able to do everything with a single computer, right? And so for that, we've got another runtime called message flow,
36:40
where this kind of a runtime of runtimes, where each of these nodes, for instance, this is actually the IoT devices graph of the C base hackerspace in Berlin. Little bit old, there's stuff missing. There's a lot more stuff there now. Each of these nodes here with message flow
37:03
is basically its own process, which can be on the same machine. They usually are on different machines. And then the edges here, so the connections between different components are message queues. So with this way, you can build complex clusters
37:22
of information processing things, or you can do IoT or whatever you like between different computers and use message queues, but you can define all of that visually, which is really nice, because you can actually see how the data flows. You get all the same benefits as you get from no flow,
37:42
but you get to use that across computers. That's something we've used at some projects to do millions of very complex computational operations on data, and it's very, very scalable. And yeah, you can do,
38:00
we also have some pretty nifty components, like this one where we connected the NASA Open Mission Control dashboard, and we made it a message flow component. So if you have some, like in this IoT graph there, you might have some metrics that you want to track. The NASA tool just becomes a box,
38:20
and then you can wire whatever data you want into that. It gets logged in InfluxDB, and you get a nice dashboard for that automatically. Yes, so the question was, are these all asynchronous? And yes, it doesn't really matter in this case,
38:40
because the connections between different things are their own message queues. So each of these nodes kind of chooses when it wants to read something and when it wants to transmit something. Yeah, then the next follow-up question was, are they stateless or stateful?
39:02
And the answer is, depends. I mean, ideally, especially like business logic, should be reasonably stateless. Generally, data flow or flow-based programming components should be stateless. But unfortunately, we are dealing with the real world,
39:21
where sometimes you have state, and hence, with most of these tools, we are not banning state. You can make stateful components, but then you have to be very careful about how to set up the state, how to tear down the state, and all of that stuff, because if you have a program that gets changed
39:43
while it's running, then you need to be able to clean up after yourself. Yeah, and another nice one is, how many of you have worked with Arduino, or NodeMCU, or any of these things?
40:02
Pretty much everybody, cool. So yeah, we have Microflow, which, instead of writing C++ in the Arduino IDE, you can plug in your microcontroller and flash it with the Microflow runtime,
40:21
and then it shows up in Flowhub, and you can edit things there. So this is a pretty nice way to do actual visual programming, also on the microcontroller. This project originally started
40:42
when my colleague had a problem. He had a broken fridge, and he needed to fix it, and of course, being an engineer, he decided to fix it with software, so he added a microcontroller to the fridge,
41:03
and with that, he could reprogram, basically build a new thermostat for it, like read the temperature numbers, choose how much to cool now or not, and yeah, as a side effect, he ended up building the Microflow framework,
41:21
so what we got out of this was, now we have Microflow, which allows you to visually program microcontrollers, and he has an internet-connected fridge built in the 70s in East Germany,
41:40
and yeah, there's a bunch of others. If you go to Flowhub, you can see a list of the ones that we know about. We also know that there's a bunch of compatible runtimes that we don't know about. I'm seeing some numbers related to that,
42:00
but yeah, that's basically the introduction to NoFlow. Here's a couple of URLs that will give you a lot more stuff, and before I take questions, the last thing is, what's the state of NoFlow? So we're currently in version 0.8,
42:22
which has been in production systems for almost all of the five years that NoFlow project has been around, so you can consider that reasonably stable. We're gonna do 1.0 probably right after the, I get back from the summer vacation, so September.
42:43
The only difference between 0.8 and 1.0 is that in 0.8, there's a bunch of old NoFlow APIs that give you deprecation warnings, and in 1.0, those things will be gone. So if you want to kind of get used to how the major release of NoFlow works,
43:02
then 0.8 is a good place to start. If you use something that has deprecation warnings, then you know those are things that probably need to be looked at. So, question.
43:22
Mm-hmm. And almost all eight, because I'm using NoWeb, would you compare FlowHub with NoWeb, because it's peeling almost people. Yeah, so the question was about how FlowHub,
43:41
or NoFlow, actually, and Node-RED compare. And yeah, Node-RED is a project from IBM that's now, I think, governed by the JavaScript Foundation, and that's not really a flow-based programming, it's a data flow programming environment.
44:01
There are some subtle differences there. With Node-RED, it's pretty simple to get started. The component API is pretty limited. There's a few things that I find a little problematic. One is that you can't get really built
44:22
like more capable components. You're usually pretty much limited to single input-output kind of things. You don't have the kind of more complex flow control things that we have, like streams, where in NoFlow, you can, like if you have a lot of data,
44:43
like a image file, contents of an image file, or just a big array of stuff, you can actually split it into a stream of data, and then send chunks from that stream to be processed independently. And then components can also say, okay, but I want the full stream, and then they can wait for the whole stream to arrive,
45:02
and then do something with the whole set of data. So you have that kind of operations. So in that sense, I would say, NoFlow is probably more powerful. That, of course, means that there are more foot guns involved. NoFlow also runs in the browser.
45:21
That's one difference. A third environment where NoFlow also runs that might or might not be interesting is GNOME, because with GNOME, they have a JavaScript runtime that GNOME Shell is built with, and you can actually build desktop applications in Flow Hub for GNOME.
45:42
GNOME 3, yes. That's the mainline version of GNOME, so I thought that would be, yeah. Yes?
46:03
So the question was, why JavaScript? Why not a real programming language, right? Yeah. Yeah, and especially regarding performance. So the primary reason why we do it in JavaScript is because JavaScript runs everywhere.
46:21
That's the only universal runtime out there. You can run, you can build NoFlow applications that work in, well, okay, JavaScript doesn't run in really small embedded systems, but you can get pretty small, and then you can go all the way to big server clusters.
46:41
You can do client-side stuff that runs on basically any computer with a web browser, which is basically anything that I would consider a computer. So the primary reason for doing NoFlow in JavaScript was that you can really target pretty much any, like we wanted to do a general purpose programming environment,
47:01
and hence we wanted something that can target pretty much anything. Performance in general is pretty great. NoFlow doesn't really put much overhead on top of a plain Node.js or browser application. There's probably a few more function calls here and there, so it's not really,
47:21
you can easily serve tens of thousands of requests from NoFlow, no problem. So for a lot of things, the performance is fine. For the things where you might not want to use JavaScript, then you have these other runtimes, like microflow is C++,
47:42
so you can first of all target microcontrollers with that, but you could actually write C++ components that you do on the server, too. Yes? Question was whether image flow is available in the browser interface, and the answer is yes and no.
48:02
So image flow itself is a server process that you run on your, let's say, on your desktop computer, whatever that has GEGL installed. And then just like all the other runtimes, it uses this protocol, so you can use the browser-based interface to edit the graphs, you can manipulate,
48:23
see what's going on and all that stuff. So anything of all these flow-based programs happens in the browser, but with some of them, the execution doesn't happen in the browser, it happens somewhere else.
48:55
Yeah, so the first question was how this compares to RxJS, and the second question was do I rather
49:02
click the click my programs or write them in code. So RxJS is a kind of reactive flow library for JavaScript. I haven't used it myself, so I can't really say.
49:20
But I would say generally that kind of things, you can pretty easily wrap that kind of stuff into a no-flow component, or you could use the no-flow callback interface to wrap no-flow code into RxJS. So in that sense, they are probably interoperable, but I haven't used it, so I can't really say.
49:44
And the question of whether I prefer drawing my code or writing my code, I have to say I really like using the visual editor. That's why I'm actually presenting this from an iPad, because I can use the nice stylus
50:01
for drawing the graphs, which feels like a very nice way to program. That said, of course, when working on the no-flow, since it's JavaScript, it doesn't compile, it's not self-hosting, so no-flow itself is written in code, not done visually, and so every now and then,
50:21
when I'm working on no-flow itself, I need to drop back to the comfy embrace of VIM. Okay.
50:43
Yeah, so the question was if there's a project to use no-flow for teaching children to program, and not to my knowledge. I know there's people who have been doing things with these MyRobot drawing robots that kind of travel over on top of some flapboard paper
51:04
and you can draw patterns, and that's a very nice visual way to teach children, but as a kind of a project, not to my knowledge, would probably be a great idea, though. Okay, I think, oh. Maybe you first, I think.
51:27
Streaming support, so the question was streaming support. So in no-flow, each packet is just a JavaScript object that travels through stuff, and then we have special packets
51:42
for kind of determining stream start, stream end, you can have also sub-streams in between, and then we have convenience methods for the components to use, where you can, things like hasFullStream, getFullStream, et cetera.
52:02
And your question? So, yeah, so the question was the licensing.
52:20
So in general, everything we do, and almost everything in the Node.js community in general is MIT licensed, so yeah. Like, pretty much everything here is under MIT license. I think image flow is probably an exception to this because I think that's LGPL.
52:42
Can Toby, huh? Image flow, I think GEGL is LGPL, so image flow is probably also. But don't quote me on that, so. But yeah, generally, if there's no reason for some other license, like building on top of something
53:01
that's licensed differently, then everything we do is MIT, because I think if we want to build developer tools, we should let developers actually use them for whatever they like, right? Okay, yeah, I just got a five minute notice like two minutes ago, so it's probably time to wrap up. Thank you everybody for listening and asking questions.