In the previous articles, we explored two pillars of event‑driven communication:

• Fire‑and‑forget events – broadcasting that something happened.
• Callback messages – asynchronous requests that return a result via an observable.

These two patterns cover the vast majority of use cases. But there is a third, often overlooked category: synchronous operations – those that must return a value immediately, without waiting for a promise or a stream.

In many frontend applications, synchronous calls are everywhere:

• “Is this user allowed to edit this document?” – a permission check.
• “Give me the current theme preference.” – reading from a local store.
• “Validate this form.” – applying business rules on the client side.

Developers typically implement such operations with direct service injection:

const canSave = this.permissionService.canEdit(docId);
if (canSave) { /* show save button */ }

This works perfectly. But it creates a hard dependency: the component knows exactly which service provides the answer. We have spent the last three articles arguing that this kind of coupling makes code rigid and difficult to test. So why should we accept it for synchronous operations?

The answer is: we don’t have to. An event bus can be extended to support synchronous operations as well – and when it does, it becomes a truly universal communication layer for your frontend. This extension is often called an executor (or command handler, or synchronous message).

The Missing Piece: Synchronous Message Passing

The idea is simple: instead of calling a service method directly, you send a synchronous message through the bus. The bus finds the registered handler, executes it, and returns the result immediately – no observables, no promises.

From the caller’s perspective, it looks like a normal function call:

const config = bus.exec(new GetUserPreferences());
// config is available right now

The caller does not know which service or function handles the request – it only knows the message class. The handler is registered elsewhere, often in a feature module or a dedicated registry.

This retains all the benefits of the event bus:

• Decoupling – the caller depends only on the message type.
• Swappable implementations – change the handler without touching callers.
• Middleware – intercept every synchronous call for logging, metrics, or auditing.
• Testability – mock the bus’s exec method instead of mocking a whole service graph.

But unlike asynchronous messages, the result is delivered synchronously, making it perfect for UI decisions (conditional rendering, validation results, local data reads).

Why This Is Often Overlooked

When developers adopt event‑driven architecture, they tend to focus on asynchronicity. Events are naturally asynchronous – you fire them and move on. Requests for data are often network‑bound, so they become asynchronous callbacks. It feels natural to treat everything as streams.

But not everything is async. Reading from localStorage, checking a permission flag in memory, or computing a derived value – these operations complete in microseconds. Forcing them into an async model (with observables and subscriptions) adds unnecessary complexity and noise.

The elegance of executors is that they don’t fight this reality. They embrace synchronous execution while still operating through the same bus that handles all other messages. The bus becomes the single entry point for any interaction – whether it returns immediately or later.

A Concrete Example: Reading and Writing User Preferences

Let’s look at a common scenario: storing user preferences (e.g., theme, language, notification settings) in the browser’s localStorage.

Traditional approach (direct service):

@Injectable({providedIn: 'root'})
export class PreferencesService {
  private readonly PREFIX = 'app_pref_';

  get(key: string): string | null {
    return localStorage.getItem(this.PREFIX + key);
  }
  set(key: string, value: string): void {
    localStorage.setItem(this.PREFIX + key, value);
  }
}

// In a component
const theme = this.preferencesService.get('theme');

This is simple, but the component is now coupled to PreferencesService. If later we decide to store preferences in a cookie or an indexedDB, we have to change every component that uses this service.

With an executor:

Define two executor messages:

class GetPreferenceExecutor extends PostboyExecutor<string | null> {
  constructor(public key: string) { super(); }
}

class SetPreferenceExecutor extends PostboyExecutor<void> {
  constructor(public key: string, public value: string) { super(); }
}

Register handlers that interact with localStorage:

bus.exec(new ConnectExecutor(GetPreferenceExecutor, (exec) => {
  return localStorage.getItem('app_pref_' + exec.key);
}));

bus.exec(new ConnectExecutor(SetPreferenceExecutor, (exec) => {
  localStorage.setItem('app_pref_' + exec.key, exec.value);
}));

Now any component can read or write preferences through the bus:

const theme = this.postboy.exec(new GetPreferenceExecutor('theme'));
this.postboy.exec(new SetPreferenceExecutor('theme', 'dark'));

The component imports only the message classes – not the service. The storage mechanism is completely abstracted. If we later change to a cookie‑based storage, we update only the handlers. All components remain unchanged.

This is a trivial example, but the pattern scales to more complex synchronous operations: permission caches, local derived state, form validation rules, feature flags loaded at startup – anything that is fast and deterministic.

Executors vs. Callbacks: A Clearer Distinction

By having both, you can choose the right tool for the job – without losing the architectural benefits of the bus.

The “Hidden” Advantage: Middleware and Observability

One of the strongest arguments for a unified bus (covering sync and async) is observability.

Imagine you want to log every operation that touches user preferences – both reads and writes. With direct service calls, you would have to add logging inside the service methods. That’s easy, but you’re mixing concerns. With executors, you can attach middleware once on the bus:

bus.beforeExecute((exec) => {
  console.log(`Executing ${exec.constructor.name}`);
});
bus.afterExecute((exec, result) => {
  console.log(`Result: ${result}`);
});

Now every executor call – no matter where it originates – is logged. The same middleware can be used for performance monitoring, auditing, or even feature toggling. This is much harder to achieve with direct function calls unless you use aspect‑oriented programming or global decorators.

The bus becomes a single point of control for all cross‑cutting concerns, regardless of whether the operation is synchronous or asynchronous.

When Not to Use Executors

Executors are not a replacement for everything. They are ideal for:

• Fast, side‑effect‑free operations (microseconds).
• Reads from local caches (in‑memory, localStorage, sessionStorage).
• Simple computations (validation, formatting, permissions).
• Operations that must be synchronous for UI decisions (e.g., *ngIf conditions).

Avoid executors for:

• Network calls – they are inherently async, use callback messages.
• Heavy processing (> 10ms) that could block the UI – consider web workers or async processing.
• Operations that depend on async state – use observables.

Summary

The event bus pattern, when extended with synchronous executors, becomes a complete communication substrate for your frontend application. You now have a unified API for:

• Notifications (fire)
• Asynchronous requests (fireCallback)
• Synchronous requests (exec)

All three share the same benefits: decoupling, testability, middleware support, and swappability. By adopting executors, you close a gap that is often left open in event‑driven architectures – the handling of fast, local, synchronous operations – without sacrificing the architectural purity you’ve gained.

The examples in this article are built on the @artstesh/postboy library, which provides all three message types out of the box, with strong TypeScript support and lifecycle management. But the pattern itself is universal. Whether you build your own bus or use an existing one, consider adding synchronous messages to your toolbox. They complete the picture and make your architecture truly consistent.

In the next article, we will explore lifecycle management – how to automatically clean up subscriptions using registrators and namespaces, so you never have to worry about memory leaks again.

Next article: Lifecycle Management & Scoping – Cleanup Without Tears