General Model of the Library
Postboy is built around a simple idea: application communication should be explicit, typed, and easy to reason about.
Instead of letting modules talk to each other through direct and tightly coupled dependencies, Postboy introduces a structured message-based model. This makes communication more predictable and gives the application a clearer event-driven shape.
Architectural idea
The architecture is based on a few core principles:
messages describe communication
subscriptions react to messages
executors handle controlled actions
middleware manages cross-cutting concerns
namespaces help organize the system
the public API stays framework-agnostic and TypeScript-first
This creates a middle layer between application parts, so the flow of data and control is easier to maintain as the codebase grows.
How event-driven thinking works in Postboy
In Postboy, an event is not just a loose notification. It is a typed message that belongs to a defined communication flow.
A typical flow looks like this:
a message is published
one or more subscriptions react to it
a callback or executor performs the required work
middleware can inspect, transform, or influence the process
the result is returned or passed further through the system
This model is useful when you want application behavior to stay modular, reactive, and explicit.
What is the core of the system?
The core of Postboy is the message-driven bus and everything built around it:
Message — the basic communication unit
CallbackMessage — a message that expects a response
Executor — a controlled execution mechanism
Middleware — a processing layer for shared concerns
Namespace — a way to isolate and structure flows
Together, these parts form a flexible event-driven system that can be used in Angular, React, Node.js, NestJS, or plain TypeScript applications.
In short: Postboy gives you a typed event-driven backbone for application communication.