How it Works

Unlike HTTP polling or traditional WebSockets where pub/sub routing must be written on top of JSON buffers in the application space, AfterLink utilizes dedicated message type bytes (MSG_SUBSCRIBE - 0x02 and MSG_PUBLISH - 0x03) to instruct the server on channel routing:

Client Pub/Sub Code Example

Below is an implementation showing how simple it is to register subscribers and push events onto channels:

Channel Routing Patterns

AfterLink supports two levels of channel routing matching structures:

• Exact Matching: Routes messages only to subscribers bound to the exact string channel, such as chat.room1.
• Wildcard Routing (Single level): Using the asterisks character (*), clients can subscribe to entire subgroups. For instance, subscribing to sensors.* catches broadcasts pushed to sensors.temperature, sensors.pressure, etc:

Cross-Node Redis & Redis Cluster Shared Pub/Sub

Using @ajaymyth/cluster, AfterLink pub/sub channels automatically bridge across worker process boundaries and multi-server instances using Redis or Redis Cluster (Redis.Cluster support added in v2.0.1). Messages published on any node are routed transparently across all subscribed socket workers.

Priority Queues & Custom Routing Keys

Protocol v2 embeds priority level queues (0-7) and custom string routing keys (0-255 bytes) directly inside the 16-byte fixed binary header:

• Priority Queues (0-7): Priority level 7 represents urgent system traffic (e.g. PRIORITY_ACK, emergency alerts), while level 0 is default background traffic. Server output buffers process higher priority frame queues first under high load.
• Custom String Routing Keys (0-255 bytes): Enables fine-grained routing filters and topic key metadata without needing to modify the main channel name or deserialize the MessagePack payload body.