> For the complete documentation index, see [llms.txt](https://docs.workersforlabview.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.workersforlabview.io/architecture-and-design-philosophy.md). # Architecture and Design Philosophy Workers for LabVIEW was created to help developers build scalable applications without sacrificing the simplicity and productivity that have made LabVIEW successful for decades. As applications grow, developers often encounter the same challenges: increasing complexity, duplicated code, tightly coupled modules, difficult debugging, and architectures that become harder to maintain over time. Workers was designed to address these challenges through a combination of modular architecture, structured communication, development tooling, and familiar LabVIEW design patterns. This page explains the key architectural principles behind the framework and the reasoning behind its design. ### Why Modular Architecture? Large applications are easier to develop and maintain when they are divided into smaller, independent components. Workers encourages applications to be built from reusable modules called Workers, where each Worker is responsible for a specific task or area of functionality. By separating responsibilities into individual modules, applications become easier to understand, test, debug, and reuse across projects. Rather than creating a single large application that attempts to do everything, Workers promotes the idea of composing applications from many smaller modules that work together. ### Why Application Hierarchies? Workers are connected together to form application hierarchies. The hierarchy provides a clear structure for ownership and lifecycle management within an application. Each Worker is responsible for creating and managing its own subWorkers, allowing initialization, shutdown, and error handling to follow predictable paths throughout the system. These relationships are described with three terms. A Worker's Caller is the Worker directly above it, a subWorker is a Worker directly below it, and the Head Worker is the Worker at the top of the tree. The same Worker is a subWorker to the one above it and a Caller to those below. A Worker manages only its direct subWorkers, so responsibility stays local and an application grows by adding Workers rather than by overloading any single Worker. This approach helps applications scale while maintaining a structure that is easy to understand and visualize. As systems grow, developers can quickly identify where functionality belongs and how different parts of the application relate to one another. The hierarchy is not simply an organizational tool; it is one of the primary mechanisms that allows large applications to remain manageable over time. ### Why Structured Communication? As applications grow, communication between modules often becomes one of the largest sources of complexity. Workers addresses this through typed Local and Public APIs. Every Worker exposes a well-defined set of **inputs** (Requests) and **outputs** (Responses), creating a clear API through which the rest of an application can interact with it. By communicating through Requests and Responses, each Worker's API is explicitly defined and easy to understand. Developers can quickly identify what inputs a Worker accepts, what outputs it produces, and how it interacts with the rest of the application. This provides several benefits: * Clearly defined module APIs * Reduced coupling between modules * Easier testing * Greater module reusability The goal is to make message flow through an application easy to follow and understand, even as systems grow to contain many independent asynchronous processes. ### Why Decoupled APIs? One of the core design goals of Workers is to keep modules independent from the applications that use them. Each Worker defines its own Public API through Requests and Responses. The rest of the application interacts with the Worker through these API VIs, rather than depending on the Worker’s internal implementation, private data, or the specific application context in which it is used. This means a Worker does not need compile-time knowledge of its Caller or of the wider application. As long as the application has the Worker's handle, i.e. the reference that identifies a specific Worker instance, it can communicate with the Worker through its Public API. The path back works the same way. A subWorker emits its Responses without knowing which Worker called it, and the Caller receives them by registering, which maps each Response onto a case in the Caller's own Message Handling Loop. A Worker can therefore stay fully decoupled from its Caller while still communicating in both directions. This allows a Worker to be: * Reused across multiple projects * Shared with other developers * Tested independently * Plugged in dynamically at run-time * Replaced by alternative implementations By making the API the point of interaction, Workers reduces compile-time coupling between modules and helps applications remain easier to evolve, extend, and maintain over their lifetime. ### Why NI QMH? The NI Queued Message Handler (QMH) template is one of the most widely understood architectural patterns in the LabVIEW community. Workers intentionally builds upon this familiarity rather than replacing it with an entirely different programming model. Each Worker uses a Message Handling Loop and an optional Event Handling Loop, allowing developers to leverage skills they already possess. This significantly reduces the learning curve and helps developers become productive more quickly. The goal is to extend established LabVIEW practices into a more modular and scalable architecture. ### Why LVOOP? Workers uses LabVIEW Object-Oriented Programming because a Worker is more than just data. Each Worker encapsulates its own state, APIs, execution, and behavior, making a class a natural way to represent an independent application module. By keeping a Worker's data together with the code that operates on that data, modules become easier to understand, maintain, reuse, and extend. This is the foundation that allows Workers to use object-oriented features where they add real architectural value: * **Inheritance** allows common framework functionality to be shared by all Workers, reducing duplicated code and hiding much of the architectural plumbing from developers. * **Encapsulation** means each Worker instance owns its own private data, helping protect internal state and keeping implementation details inside the module. * **Abstraction** allows Public APIs to be defined separately from the Workers that implement them, enabling Hardware Abstraction Layers (HALs) and interchangeable plug-in implementations. * **Dynamic Dispatch** allows behavior to be selected at run-time, making it possible to work through common APIs while loading or substituting different Worker implementations. At the same time, Workers does not require developers to heavily use classes throughout their applications. The framework's use of classes is intentionally minimized and focused on the modules themselves. Message payloads are simply data, and are therefore represented using standard LabVIEW typedefs. ### Why Hardware Abstraction Layers? Many applications need to support multiple hardware devices that provide similar functionality. Workers uses API abstraction and inheritance to allow different hardware implementations to expose a common interface. Applications communicate with the abstract API rather than a specific hardware implementation. This makes it possible to swap hardware implementations, create simulations, develop plug-in architectures, and support multiple devices without changing the application code that uses them. The result is greater flexibility, improved maintainability, and reduced hardware-specific coupling. ### Why Tooling Matters A framework is only useful if developers can use it efficiently. For this reason, Workers includes a large collection of development tools that automate common architectural tasks such as creating Workers, generating APIs, managing inheritance, building application hierarchies, and creating Hardware Abstraction Layers. The tools also manage much of the underlying LVOOP implementation, allowing developers to focus on building application functionality rather than framework infrastructure. This helps developers become productive quickly, even if they have little or no prior experience with object-oriented programming. The goal is to reduce repetitive development work and allow developers to focus on application logic rather than framework implementation details. ### Why Debugging Matters As applications become more modular and distributed, visibility becomes increasingly important. Workers includes the Workers Debug Server to provide transparency into running applications. Developers can inspect application hierarchies, monitor Worker status, view message flow, track errors, and better understand what is happening inside a running system. Good architecture is important, but so is the ability to understand and debug that architecture once it is deployed. ### The Philosophy Behind Workers The central goal of Workers has always been to make scalable software architecture accessible to everyday LabVIEW developers. The framework combines familiar LabVIEW development patterns with modular architecture, structured communication, object-oriented design, development tooling, debugging tools, documentation, training resources, and community support. Rather than focusing solely on architectural theory, Workers aims to provide a practical and approachable path to building applications that remain understandable, maintainable, and scalable as they grow. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.workersforlabview.io/architecture-and-design-philosophy.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.