Flow-based programming

Flow-based programming (FBP) is a that models applications as networks of black-box processes exchanging data through predefined connections, using a "data processing factory" metaphor where information packets flow asynchronously between components. Developed by J. Paul Morrison in the late at , FBP was first formally described in a 1971 IBM Technical Disclosure Bulletin as a modular system of tasks communicating via queues under a central scheduler to process data elements efficiently. Key concepts include asynchronous concurrent execution of processes, packets with defined lifetimes that encapsulate , named input and output ports for connections, and bounded buffers to manage flow without tight coupling between components, enabling loose data coupling for easier maintenance and reusability. Unlike the sequential von Neumann model, FBP emphasizes -driven execution, supporting , component reuse, and efficient utilization of multi-core processors by distributing work across independent processes. Morrison detailed the paradigm in his book Flow-Based Programming: A New Approach to Application Development (second edition, 2010), which includes tools like DrawFBP for graphical network design and implementations in languages such as C, Java, and Lua.

Fundamentals

Definition and Principles

Flow-based programming (FBP) is a programming paradigm in which applications are built as networks of independent, black-box processes that exchange data exclusively through asynchronous data flows, treating the overall system as a directed graph of data transformations rather than sequential instructions. This approach, invented by J. Paul Morrison in the late 1960s, shifts the focus from traditional control flow to data-driven execution, where processes operate concurrently without shared memory or direct dependencies. At its core, FBP adheres to principles of through reusable, self-contained components that encapsulate functionality behind well-defined input and output interfaces, promoting ease of composition and in complex systems. It enforces asynchronous data exchange, allowing processes to run independently and interleave based on data availability, which inherently separates from and ensures deterministic behavior as outputs depend solely on inputs received. Coordination among processes is managed externally via predefined network structures, enabling implicit parallelism without explicit mechanisms. The motivation behind FBP lies in its ability to facilitate parallelism and scalability by mapping naturally to distributed or multiprocessor environments, where data streams drive execution and reduce bottlenecks in large-scale applications. By viewing programs as dynamic graphs of interconnected transformations, FBP enhances maintainability, as changes to individual processes do not propagate globally, and supports efficient resource utilization in data-intensive tasks. This paradigm has proven effective in industrial settings, such as long-term deployments in enterprise software, by prioritizing data responsiveness over rigid sequencing.

Key Components

In flow-based programming (FBP), the foundational building blocks are black-box processes, which serve as self-contained, reusable units designed to perform specific transformations on incoming without exposing their internal state or logic to other components. These processes operate asynchronously, receiving input, processing it independently, and producing output, thereby promoting and reusability across different applications. As described by the paradigm's originator, J. Paul Morrison, black-box processes encapsulate long-running functions such as sorting or merging, allowing them to be interconnected without modification to their internals. Each black-box process features input and output ports, which act as standardized, named interfaces for data exchange, enabling selective reception from multiple inputs and dispatch to designated outputs. Input ports allow a process to receive data from one or more upstream connections, often choosing dynamically based on availability, while output ports facilitate the emission of processed data to downstream processes. This port-based design ensures that interactions remain loosely coupled, with ports serving as the sole points of attachment between a process's code and the broader network structure. Connections in FBP represent directed, fixed-capacity links between output ports of one process and input ports of another, defining the pathways for data flow without incorporating buffering mechanisms or explicit . These connections transport discrete units of data, known as Information Packets, in a stream-like manner, with each packet having a defined lifetime owned either by a or during transit. By specifying connections externally—typically in a list interpreted by a scheduler—FBP separates from implementation, enforcing a data-driven execution model where flow is governed by and capacity constraints, such as to prevent overflow. Unlike traditional programming paradigms that rely on shared variables for state management and inter-component communication, FBP emphasizes stateless, event-driven components connected solely through data flows, achieving the loosest form of coupling known as data coupling. This approach eliminates direct variable access across processes, reducing dependencies and enhancing maintainability, as components neither retain nor expose mutable state but instead react to incoming events via asynchronous send and receive operations. In contrast to synchronous method calls in object-oriented programming, where state is often maintained within objects, FBP's design ensures that data propagation occurs independently of process timing, fostering robustness in concurrent environments.

Historical Development

Origins

Flow-based programming (FBP) was invented by J. Paul Morrison in the late during his tenure at in , , where he was engaged in and programming for mainframe environments. Morrison, who had joined in the in 1959 after graduating from , brought experience in early compiler design and from his time at facilities in and the before relocating to in 1968. The paradigm emerged as a response to the constraints of conventional von Neumann architectures and sequential programming languages prevalent in batch-oriented computing systems of the era. The initial development of FBP was heavily influenced by challenges in handling concurrent data streams within environments, particularly the inefficiencies of synchronous, procedural code in managing parallelizable tasks such as data decomposition and recombination. Morrison's early work focused on creating a data-driven approach that emphasized independent processes communicating via information flows, inspired by simulation tools like (General Purpose Simulation System) developed at in the early 1960s and concepts from queue-based data flow explored in a 1967 paper by Morenoff and McLean at the Rome Air Development Center. This motivation stemmed from practical needs in developing robust applications for mainframe systems, where traditional methods led to brittle, hard-to-maintain code amid growing demands for and reusability. The first conceptual foundations of FBP were laid through internal IBM documentation and prototypes around 1967–1970, predating any formal publications. Morrison developed the Advanced Modular Processing System (AMPS), an early implementation in Assembler that used macros to define process networks for batch applications supporting an system at a major Canadian institution. These efforts addressed the limitations of sequential programming by enabling interleaved task execution and dynamic handling, with networks initially sketched manually on paper to visualize asynchronous flows. The inaugural public disclosure came in Morrison's 1971 article in the IBM Technical Disclosure Bulletin, titled "Data Responsive Modular, Interleaved Task Programming System," which outlined the core idea of modular, data-responsive processes.

Key Milestones and Evolution

In the 1970s, J. Paul Morrison advanced flow-based programming through his work at , developing practical prototypes implemented in OS/360 environments for high-volume banking applications at a major Canadian . These early systems demonstrated asynchronous across networked components, with core concepts outlined in Morrison's 1978 publication on linkage mechanisms. During the 1980s, Morrison collaborated with IBM architect Wayne Stevens to refine and promote FBP concepts, integrating them with methods. Stevens highlighted FBP's compatibility in publications, including a 1982 article on data flows in flowcharts. The 1990s marked a formalization of the paradigm with the publication of Morrison's seminal book, Flow-Based Programming: A New Approach to Application Development, in 1994, which provided a comprehensive theoretical framework and practical guidance for application development. This work emphasized the paradigm's advantages in modularity and reusability, influencing subsequent software engineering practices. During the 2000s and 2010s, flow-based programming saw the rise of open-source implementations, including JavaFBP and C#FBP, which enabled broader experimentation and integration with emerging web technologies like JavaScript runtimes. A notable advancement was the launch of NoFlo in 2011, a JavaScript-based framework that extended the paradigm to browser and Node.js environments, fostering reusable component ecosystems. Visual tools such as FlowHub, launched in 2013 as a collaborative development environment for NoFlo, and Slang, a Go-based visual flow system introduced around 2018, further supported automation in distributed systems. In the 2020s, adoption has grown in cloud-native data pipelines and AI workflows, leveraging the paradigm's strengths in scalable, asynchronous processing. Recent applications include bioinformatics pipelines, such as DeBasher in 2025, which applies flow-based principles to modular workflow execution.

Core Concepts

Processes and Black Boxes

In flow-based programming (FBP), processes serve as the fundamental computational units, functioning as independent, concurrent entities that execute autonomously within a network. Each process activates upon the arrival of an information packet at one of its designated input ports, triggering a cycle of data consumption, internal processing, and output generation. This activation mechanism ensures that processes remain dormant until stimulated by incoming data, enabling efficient resource utilization in asynchronous environments. The black-box property is central to FBP processes, encapsulating their internal logic completely while exposing only input and output ports for interaction. This design hides implementation details from other components, allowing processes to be treated as opaque modules whose behavior is verifiable solely through their I/O interfaces. Such encapsulation fosters reusability, as processes can be developed, tested, and deployed independently, and facilitates modular testing by isolating them from the broader network. For instance, a sorting process can be validated using predefined input packets and expected outputs without knowledge of its algorithmic internals. Activation and deactivation cycles in FBP processes emphasize stateless operation between invocations, with no shared state or across executions. Upon , a receives and consumes the triggering input packet—typically it sequentially if multiple inputs are involved—performs its , and dispatches results to connected output ports before deactivating. Non-looping processes handle one packet per cycle and terminate afterward, while looping processes remain active to process streams until an end-of-data signal, such as a closed connection, prompts deactivation. This cycle-based model prevents race conditions and promotes concurrency without requiring explicit synchronization primitives. FBP processes support multiple inputs and outputs through port-based mechanisms, enabling (converging data from several sources to a single process) and (distributing outputs to multiple downstream processes). Input allow selective reception, where a process might wait for data on a specific port before proceeding, while output ports queue packets for transmission without direct invocation of recipient processes. This port-mediated communication enforces , eliminating function calls or shared variables between processes and ensuring in distributed or parallel executions.

Information Packets and Connections

In flow-based programming (FBP), packets (IPs) serve as the fundamental units of exchange between processes, encapsulating both and metadata to ensure self-contained transmission. The consists of the actual content, which can vary in length from zero to approximately two billion bytes, representing entities such as words, transactions, or multi-field objects. Metadata includes elements like type , , and sometimes destination details, often managed through handles or descriptors that allow processes to access and interpret the without exposing its internal . This enables IPs to travel as complete, indivisible entities through the network, maintaining integrity across asynchronous flows. Connections in FBP act as typed, point-to-point channels that link the output ports of upstream processes to the input ports of downstream processes, facilitating the routing of IPs without direct process-to-process . These connections operate asynchronously, allowing processes to execute independently while IPs are buffered in FIFO queues with finite capacity—typically ranging from a single IP to a large number, or effectively unlimited via file-based storage—to prevent unbounded accumulation and manage flow control. Unlike unbounded channels in some paradigms, this bounded queuing ensures deterministic behavior but requires careful capacity tuning to avoid deadlocks or livelocks. Multiple connections can attach to a single port, supporting many-to-one topologies, though one-to-many splitting is handled explicitly by processes rather than the connections themselves. The lifecycle of an IP begins with its creation by an upstream , which allocates the packet and populates its and metadata before transmitting it via an output to a connected channel. Upon arrival at a downstream 's input —triggered by the availability of data—the IP is received, consumed for or transformation, and then disposed of, either by forwarding it to another connection, filing it for persistence, destroying it if no longer needed, or attaching it to a . Error handling occurs through explicit disposal mechanisms, such as discarding unprocessable or undeliverable IPs using commands like "drop" or APIs (e.g., dfsdrop), which prevent resource leaks and allow error via dedicated control packets without halting the network. Type safety is enforced at the connection level by verifying compatibility between the types declared on connected ports during network initialization, preventing runtime mismatches that could corrupt data flows. Metadata descriptors in IPs further support this by defining expected formats and structures, enabling processes to validate and transform data as needed—such as through type-specific handlers—while special IP variants (e.g., control IPs for substreams) maintain consistency across the network. This rigorous , combined with the asynchronous yet bounded nature of connections, underpins FBP's reliability in distributed and concurrent applications.

Networks and Execution

In flow-based programming (FBP), a network is defined as a —potentially acyclic or cyclic—comprising interconnected black-box processes that collectively form a complete, executable application. These processes communicate exclusively through predefined connections that carry information packets (IPs), enabling modular assembly where the is specified separately from the processes themselves. This graph structure supports hierarchical composition via subnets, allowing complex applications to be built from reusable components without tight coupling. Execution in FBP networks is demand-driven, meaning processes activate only when IPs are available on their input connections, facilitating asynchronous and concurrent operation across multiple processors or cores. Scheduling is managed by a runtime scheduler that monitors connection queues and triggers processes based on data availability, incorporating back-pressure mechanisms to suspend upstream processes if downstream queues become full (unless configured otherwise, such as with a "DropOldest" policy). This approach inherently supports parallelism without the need for locks or shared state, as communication occurs via bounded, message-passing connections that prevent race conditions. Network initialization begins with source processes, which generate initial IPs from external inputs or constants, propagating through the graph as downstream processes become ready. Shutdown occurs when processes—those with no output connections or connected to external outputs—complete consumption of all IPs, signaling the closure of connections to upstream processes; closed connections trigger end-of-stream notifications, ensuring orderly termination without dangling data. This lifecycle maintains by suspending inactive processes until data arrives. FBP networks provide determinism in that individual process outputs depend on the content of input IPs and the fixed connection topology, with stateless processes avoiding shared state issues. However, at merge points, the sequence of IPs may vary based on arrival times influenced by concurrent execution and scheduling, potentially leading to non-reproducible results across runs. The loose data coupling still minimizes other nondeterministic side effects from scheduling variations.

Examples and Applications

Classic Problem Solutions

One of the earliest demonstrations of flow-based programming (FBP) principles is the telegram problem, originally posed by in as a text-wrapping task. In this problem, a program reads a width ww, followed by lines of text, and outputs reformatted lines containing as many words as possible without exceeding ww characters, avoiding mid-word splits. The FBP solution transforms this sequential imperative approach into a parallel network by treating individual words as information packets (IPs) that flow through black-box processes. Key components include a pair of complementary processes—one to serialize input text into word IPs and another to deserialize output IPs into lines—connected via initial information packets (IIPs) that carry the width . This setup highlights FBP's ability to decompose linear problems into concurrent, reusable subprocesses, where parsing, validation, and routing occur in a distributed manner without shared state. Another foundational example is the batch update problem, which models the merging of a master file with transaction details to produce an updated master and exception . In FBP, this is achieved through a network where IPs representing records flow from input sources into a central "Collate" component, a reusable that synchronizes multiple using bracket IPs to group related records (e.g., pairing each master record with its corresponding detail transactions). processes then apply idempotent changes—ensuring operations like updates or validations can be retried without side effects—before outputs branch to updated files and sinks. This structure emphasizes FBP's strength in handling deterministic pipelines, where connections enforce order and parallelism emerges naturally from independent subprocess execution. FBP naturally supports through and configurations, as seen in task distribution examples where a single input stream is parallelized across multiple worker instances. A load balancer receives IPs from an upstream source and routes them to several identical black-box workers (e.g., three search components S1, S2, S3), each processing subsets independently on multi-processor hardware. Results then converge via a aggregator, maintaining order if needed through timestamping or queuing. This pattern demonstrates how FBP enables scalable parallelism without explicit threading, leveraging read-only components to avoid overhead and allowing dynamic instance scaling based on load. For interactive applications, a simple network illustrates FBP's handling of request-response loops. User inputs enter as IPs at one end, flowing through processes (e.g., validation or query execution) connected to backend sinks like message queues. Responses route back via cross-connections, using hash tables in subprocesses to correlate replies to original requests, forming a closed I/O cycle without blocking. This design, often visualized with requests entering upper-left and exiting lower-right, underscores FBP's event-driven concurrency, where black-box processes and predefined connections manage state isolation in real-time interactions.

Modern Data Processing Uses

Flow-based programming (FBP) has found significant application in extract-transform-load (ETL) pipelines for systems, where it enables the modular assembly of data ingestion, transformation, and loading processes. , built on FBP principles, automates the flow of data between heterogeneous systems, supporting operations such as , , and guaranteed delivery through its processor-based architecture. This structure allows developers to define ETL workflows as interconnected black boxes that handle diverse data formats and volumes, making it suitable for enterprise-scale integrations without custom scripting for each step. In streaming analytics, FBP facilitates real-time processing networks for (IoT) and event-driven architectures by modeling data as packets flowing through dynamic connections. For instance, NiFi processes sensor data streams by chaining processors that perform filtering, aggregation, and enrichment in near real-time, enabling applications like in industrial IoT setups. Similarly, , a browser-based FBP tool, enables visual wiring of flows for IoT data processing, supporting real-time event handling across devices and services. This approach leverages the network execution model, where components activate based on available input packets, supporting low-latency handling of continuous data flows from devices. FBP supports AI workflow orchestration by chaining preprocessing, model , and post-processing as composable components, particularly in pipelines. Graphical FBP tools have been proposed to abstract ML libraries, allowing non-experts to visually assemble workflows for tasks like and recommendation, with automatic code generation for execution. Empirical evaluations demonstrate FBP's utility in deploying ML models, such as in ride allocation systems where from multiple sources feeds into components, streamlining end-to-end orchestration compared to service-oriented alternatives. The scalability of FBP in environments stems from its inherent support for auto-parallelism and distributed execution, where networks can span without tight coupling. In ML deployments, FBP reduces and maintenance overhead by centralizing data flows, as shown in applications requiring updates across distributed components, achieving up to twice the in dataset management over service-oriented architectures. NiFi exemplifies this in clusters, scaling to up to 256 million events per second across 1,000 nodes (as of April 2020 benchmarks), with features like load balancing and zero-master clustering enabling elastic resource allocation in -based setups.

Implementations and Tools

Programming Languages and Frameworks

Flow-based programming (FBP) has been implemented in various programming languages through dedicated libraries and frameworks that enable the construction of networks of processes exchanging information packets. The original implementations trace back to J. Paul Morrison, the paradigm's inventor, who developed the first FBP system in 1969–1970 using S/360 as (Advanced Modular Processing System). Later textual implementations include C-based prototypes from the for Unix systems, allowing asynchronous communication via and files; these laid the groundwork by providing a runtime for defining black-box processes and connections programmatically. Morrison also authored JavaFBP, a library integrated with the DrawFBP tool, which compiles graphical definitions into executable Java code for building and running FBP networks, emphasizing and reusability in enterprise applications. An upgraded C implementation, CppFBP (using with Boost and Lua scripting for processes), was developed starting in 2013. In the ecosystem, NoFlo emerged in 2011 as a prominent FBP implementation for both server-side applications and browser environments, facilitating the creation of graphs where components information packets in a manner. NoFlo separates from , supporting runtime reconfiguration and integration with extensions like RxJS for handling asynchronous streams and events within FBP networks. This makes it suitable for web-based and real-time processing, with components defined as modules that connect via ports. Other languages have seen FBP-inspired libraries that adapt the for specific use cases, such as streaming and . In Python, Streamz provides a framework for building continuous data pipelines using , where data flows through connected operators in a manner akin to FBP processes, supporting backpressure and integration with libraries like Dask for parallel execution. This enables FBP-like for real-time without explicit threading management. For concurrent pipelines in Go, GoFlow offers a lightweight runtime that models applications as directed graphs of tasks communicating over channels, leveraging Go's goroutines for efficient, non-blocking execution of FBP networks. Integration frameworks like incorporate FBP-like principles through its unified model for bounded dataflows, where pipelines are defined as graphs of transforms processing collections in batch or streaming modes. Beam's SDKs, available in multiple languages including , Python, and Go, enforce deterministic execution and bounded buffering to prevent unbounded memory growth, aligning with FBP's emphasis on controlled information packet exchange. As of 2025, Beam has been updated with releases such as version 2.68.0 (September 2025), enhancing hybrid batch/streaming capabilities for scalable in cloud environments.

Visual Development Environments

Visual development environments for flow-based programming (FBP) enable designers to construct, simulate, and debug networks of processes and connections through graphical interfaces, leveraging the paradigm's inherent visual nature to enhance comprehension and collaboration. These tools typically support drag-and-drop assembly of components, real-time visualization of data flows, and integration with runtime execution, allowing users to complex systems without writing traditional . By representing FBP networks as diagrams, such environments reduce and facilitate iterative development, particularly for distributed or concurrent applications. DrawFBP, developed by J. Paul Morrison, the originator of FBP, is a Java-based diagramming tool that permits users to draw multi-level FBP networks visually, simulate their execution, and export diagrams to executable code in languages like or C++. It emphasizes hierarchical structuring, where subnets can be collapsed or expanded for clarity, and includes features for tracing packet flows during simulation to identify bottlenecks or errors. This tool has been instrumental in demonstrating FBP concepts since its , supporting both educational and practical network design. FlowHub and NoFlo UI represent web-based platforms for collaborative FBP development, with NoFlo UI serving as an open-source, browser-hosted editor and FlowHub providing a managed, multi-user environment as of 2025. Built around the NoFlo FBP runtime, these tools offer drag-and-drop connection of components from extensible libraries, live runtime visualization of packet exchanges, and real-time collaboration for distributed teams. They support by allowing immediate execution and within the browser, making them suitable for web and IoT applications. Other notable tools include Node-RED, which draws influence from FBP principles to provide a browser-based editor for wiring together hardware devices, APIs, and online services in IoT flows, featuring drag-and-drop nodes and live flow tracing. Node-RED is highly customizable for tech-heavy or embedded use cases, excels in IoT and developer workflows with custom JavaScript nodes, and features lighter resource usage due to its lightweight runtime suitable for resource-constrained environments like Raspberry Pi.

Comparisons

With Dataflow and Reactive Paradigms

Flow-based programming (FBP) represents a specialized variant of dataflow programming, where applications are constructed as networks of black box processes connected explicitly via predefined ports for exchanging discrete information packets, rather than relying on implicit data dependencies or fine-grained operators common in general dataflow systems. In contrast to languages like LabVIEW, which employ visual wiring for dataflow execution driven by token availability and supports black box encapsulation through modular components, FBP prioritizes modularity through reusable, self-contained components that maintain internal opacity and support loose data coupling for easier reconfiguration and maintenance. This explicit connection model in FBP fosters higher-level composition over the operator-centric granularity often seen in pure dataflow paradigms, enabling asynchronous concurrency without adhering strictly to traditional dataflow firing rules. Compared to reactive programming, FBP adopts a push-based mechanism for propagating bounded data packets across fixed network topologies, diverging from the observable stream model in libraries like RxJS, where continuous data flows and change propagation rely on subscription-based event handling and operators for transformation. FBP eschews callback-heavy patterns inherent in reactive streams, instead emphasizing discrete, self-contained units of information that traverse composable pipelines, which reduces complexity in managing unbounded or infinite streams. While reactive programming excels in declarative handling of dynamic events and backpressure through protocols like Reactive Streams, FBP's packet-oriented approach provides deterministic flow control via bounded buffers, avoiding the potential for cascading reactions in event-driven scenarios. Both paradigms share foundational traits in supporting asynchronous processing and data-driven execution, allowing for scalable parallelism without explicit thread management; however, FBP centers on static, network-based composition of modular components, whereas focuses on propagating changes through dependencies, often in functional contexts. This overlap in concurrency models has led to synergies, particularly in the , where hybrid approaches integrate FBP's structured workflows with reactive elements for dynamic, pipelines, as seen in frameworks combining modular data flows with just-in-time reactive code generation to enhance adaptability in and task automation.

With Object-Oriented and Actor Models

Flow-based programming (FBP) contrasts with object-oriented programming (OOP) in its emphasis on stateless process networks that exchange data via information packets (IPs), rather than relying on class hierarchies and synchronous method calls. In OOP, programs are structured around objects that encapsulate state and behavior, often using inheritance to create specialized subclasses, such as deriving a "Pontiac" class from a "Vehicle" base class. FBP, however, avoids inheritance altogether, promoting composition through explicit connections between independent, black-box processes that operate on streams of IPs, allowing for greater flexibility and reusability without the rigidity of deep inheritance trees. This approach aligns with design principles where processes are selected based on functionality rather than modeling real-world entities, reducing maintenance issues associated with tightly coupled hierarchies. Compared to the actor model, FBP employs typed, directed IPs flowing through named ports and bounded buffers, ensuring predictable, one-way communication along predefined connections, whereas actors communicate via untyped messages sent to dynamic mailboxes, as seen in systems like Akka or Erlang. In the actor model, each actor maintains its own internal state and processes messages asynchronously from any sender, enabling flexible, non-deterministic concurrency but requiring careful management of state isolation. FBP strictly prohibits shared mutable state among processes—relying instead on read-only global references when needed—thus guaranteeing determinism and simplifying debugging, while actors encapsulate state within individual entities, which can lead to more complex synchronization in distributed scenarios. A key advantage of FBP over both OOP and the is its facilitation of inherent parallelism without the need for explicit synchronization mechanisms, as processes execute independently on data availability, making it well-suited for scalable, distributed applications. However, FBP is less ideal for modeling long-lived, stateful entities, where OOP's encapsulation or ' internal state management provides more natural abstractions for persistent object lifecycles. These distinctions were first articulated by J. Paul Morrison in his 1994 book Flow-Based Programming: A New Approach to Application Development, where he highlighted FBP's modularity as complementary to OOP's strengths in graphical interfaces but superior for asynchronous . In modern contexts, such as architectures, FBP complements OOP by offering a data-flow overlay for orchestrating stateless services, enhancing in distributed systems like the without introducing shared state complexities.

References

  1. https://jpaulm.github.io/fbp/
  2. https://jpaulm.github.io/fbp/0084-Ex%201135%20-%20Morrison.pdf
  3. http://www.jpaulmorrison.com/fbp/book.pdf
  4. https://jpaulm.github.io/fbp/introduction.html
  5. https://jpaulmorrison.com/fbp/oops.shtml
  6. https://jpaulm.github.io/
  7. https://jpaulm.github.io/fbp/history.html
  8. https://www.jpaulmorrison.com/fbp/fbp2.htm
  9. https://jpaulm.github.io/fbp/software.html
  10. https://github.com/noflo/noflo
  11. https://bergie.iki.fi/blog/flowhub/
  12. https://medium.com/@jmatschinske/both-slang-and-node-red-are-dataflow-programming-tools-using-visual-elements-for-easy-and-fast-fc117e333369
  13. https://www.mdpi.com/1999-5903/14/2/58
  14. https://bmcbioinformatics.biomedcentral.com/articles/10.1186/s12859-025-06108-1
  15. https://jpaulmorrison.com/fbp/schedrls.shtml
  16. http://www.amazon.com/Flow-Based-Programming-2nd-Application-Development/dp/1451542321
  17. https://jpaulm.github.io/fbp/examples.html
  18. https://nifi.apache.org/docs/nifi-docs/html/overview.html
  19. https://nodered.org/about/
  20. https://arxiv.org/pdf/2204.12781
  21. https://www.cloudera.com/blog/technical/benchmarking-nifi-performance-and-scalability.html
  22. http://www.jpaulmorrison.com/fbp/fbp2.htm
  23. https://www.jpaulmorrison.com/fbp/software.html
  24. https://github.com/jpaulm/cppfbp
  25. https://noflojs.org/
  26. https://bergie.iki.fi/blog/noflo-two-years/
  27. https://streamz.readthedocs.io/
  28. https://github.com/python-streamz/streamz
  29. https://github.com/trustmaster/goflow
  30. https://groups.google.com/g/golang-nuts/c/bJOf8cwHfy8
  31. https://beam.apache.org/
  32. https://beam.apache.org/blog/beam-2.68.0/
  33. https://github.com/jpaulm/drawfbp
  34. http://www.jpaulmorrison.com/fbp/#DrawFBP
  35. https://github.com/noflo/noflo-ui
  36. https://github.com/Bitspark/slang
  37. https://developer.ibm.com/blogs/top-5-reasons-to-use-node-red-right-now/
  38. https://sites.cs.ucsb.edu/~rich/class/cs293s-iot/lecture-8.pdf
  39. https://www.cs.tufts.edu/comp/150CMP/papers/dataflow-johnston-acm04.pdf
  40. https://arxiv.org/pdf/2108.04105
  41. https://projectreactor.io/docs/core/release/reference/reactiveProgramming.html
  42. https://dl.acm.org/doi/10.1145/2501654.2501666
  43. https://arxiv.org/pdf/2308.00204
  44. http://www.jpaulmorrison.com/fbp/oops.htm
  45. https://jpaulm.github.io/fbp/comparison.html
  46. https://wiki.c2.com/?ActorsAndFlowBasedProgrammingDiscussion
  47. https://ieeexplore.ieee.org/document/9514390/