Concepts
Wire Broker
Publish messages that reach whoever is subscribed right now and are never stored. Delivery semantics, and when to choose it over the Event Broker.
The Wire Broker moves messages that are never stored. Publishing one hands it to everyone subscribed to the topic or to one of its super topics at that moment, then it's gone: no history, no replay, nothing to read back or purge. Thuum holds a message in memory only while delivering it.
Choose it when data must not be kept anywhere, or when a late copy is worthless: sensor readings and setpoints, commands, signals, anything where only "now" matters.
Messages#
A message has a type you choose and JSON data, like an event. Thuum adds an id and a
timestamp, which identify it while it's in transit:
{
"id": "0f6c2a1e-3b7d-4e8a-9c41-2d5f8a7b6e10",
"topic": "plant:line-3",
"type": "readings",
"data": { "t1": 71.4, "p2": 2.08 },
"ts": 1792590697447
}| Field | Rules |
|---|---|
id | Random, generated by the server. Nothing is stored under it. |
topic | The exact topic it was published on. |
type | 1–64 characters of a-z A-Z 0-9 _ . : -. |
data | Any JSON value except null: object, array, string, number, boolean. At most 64 KiB as JSON. |
ts | When the server received it, in epoch milliseconds. |
The Wire Broker never looks inside data: encrypt it yourself if you like, as a string.
Publish and subscribe#
The Wire Broker is WebSocket only: there is no REST data route, because there is nothing to read.
const socket = acme.wire.connect();
socket.onMessage((message) => {
console.log(message.topic, message.type, message.data);
});
await socket.ready;
await socket.sub('plant');
const { id, ts } = await socket.pub('plant:line-3', 'readings', { t1: 71.4 });sub (needs S) delivers every message published on the topic and on all its sub-topics, from now
on. pub (needs P) resolves once the message has been handed to the current subscribers. It
doesn't mean anyone received it: there may be no subscribers, and then the message is simply gone.
Delivery guarantees#
- At most once, now or never. A message reaches the connections subscribed when it's published. A connection that is down, or not yet subscribed, misses it for good: there is no history to catch up from. If you need the current value after a reconnect, ask the other side for it (for example, publish a "hello" and have the source answer with the latest values).
- Everyone subscribed receives it, publisher included, as on the Event Broker.
- Once per connection. Overlapping subscriptions (
plantandplant:line-3) still deliver a message once. - Ordering. Messages from one publisher on one topic arrive in the order they were published.
- Permissions are fixed at connect. A claim change applies to new connections.
Nothing is stored#
The Wire Broker has no data table, no retention, no backups of its messages, and logs none of their contents. What Thuum keeps is metadata: which key connected and when, topic names, message counts and sizes. Hash your topic names if they would identify anything.
Try it#
Open Wire Broker → Live in the console: subscribe in one tab, publish in another.
When to use the Event Broker instead#
If a client that was offline must catch up on what it missed, use the Event Broker: it keeps a recent history. If subscribers only care about the latest value and late joiners should read it from Thuum, use the State Broker. The Wire Broker is for data that must not be kept, or that is worthless once it's late. See Event Broker and State Broker.