Introduction

When developers talk about real‑time web applications, Socket.IO often steals the spotlight. Its ease of use, automatic fallback mechanisms, and rich event‑driven API make it a go‑to solution for many Node.js projects. However, Socket.IO is just one of many ways to push data from server to client (and vice‑versa) without the classic request/response cycle.

Understanding non‑SocketIO types—the alternative protocols, transport layers, and data serialization formats—empowers you to:

  • Choose the right tool for specific latency, scalability, or compatibility constraints.
  • Avoid vendor lock‑in by leveraging standards that are language‑agnostic.
  • Optimize bandwidth usage and battery consumption on constrained devices.
  • Build hybrid architectures where different parts of the system communicate using the most suitable technology.

This article dives deep into the landscape of real‑time communication beyond Socket.IO. We’ll explore the underlying protocols, compare their trade‑offs, walk through practical code examples, and discuss real‑world scenarios where each shines.

Note: While Socket.IO builds on top of WebSockets (and falls back to HTTP polling), the “non‑SocketIO types” we discuss are independent of Socket.IO’s abstraction layer. They may still use WebSockets as a transport, but they expose a different API, data model, or operational semantics.

Table of Contents

  1. Why Look Beyond Socket.IO?
  2. [Core Real‑Time Transport Protocols]
    1. WebSockets
    2. Server‑Sent Events (SSE)
    3. Long Polling
    4. HTTP/2 Server Push & HTTP/3 QUIC
  3. [Message‑Oriented Middleware]
    1. MQTT
    2. AMQP / RabbitMQ
    3. NATS
  4. [Remote Procedure Call (RPC) Frameworks]
    1. gRPC
    2. GraphQL Subscriptions
  5. [Data Serialization Formats]
    1. JSON vs. MessagePack vs. Protocol Buffers vs. Avro
  6. [Choosing the Right Tool: Decision Matrix]
  7. [Scaling, Security, and Operational Considerations]
  8. [Practical Example: Building a Multi‑Protocol Notification Service]
  9. [Conclusion]
  10. Resources

Why Look Beyond Socket.IO?

Socket.IO is a convenient wrapper that abstracts away many low‑level details. However, this convenience can become a limitation:

SituationWhy Socket.IO May Not FitAlternative Approach
Strict Standards ComplianceSocket.IO uses its own protocol on top of WebSockets, which browsers and many third‑party services don’t natively understand.Pure WebSocket APIs (RFC 6455)
Low‑Bandwidth IoT DevicesOverhead of Socket.IO’s framing and JSON payloads can be costly.MQTT (binary, minimal header)
Inter‑service Communication in MicroservicesSocket.IO is primarily client‑to‑browser; services often need brokered, decoupled messaging.AMQP, NATS, or gRPC streaming
Strongly Typed ContractsSocket.IO’s dynamic events lack compile‑time guarantees.Protocol Buffers with gRPC
Server‑Push in HTTP/2Socket.IO cannot leverage HTTP/2 server push without additional layers.HTTP/2 Server Push or SSE over HTTP/2
Polyglot EcosystemSome languages lack mature Socket.IO client libraries.Language‑agnostic protocols (WebSocket, MQTT, gRPC)

Understanding the alternatives equips you to design systems that meet performance, interoperability, and maintainability goals without being constrained by a single library’s design decisions.

Core Real‑Time Transport Protocols

WebSockets

What it is:
A full‑duplex, persistent TCP connection established via an HTTP handshake (RFC 6455). Once upgraded, both client and server can exchange arbitrary binary or text frames at any time.

Key Characteristics

  • Low latency: Near‑real‑time message delivery.
  • Bidirectional: Ideal for chat, gaming, collaborative editing.
  • Standardized: Supported natively by browsers (WebSocket API) and many server frameworks.
  • Binary support: Send ArrayBuffer or Blob directly.

When to use:
When you need true duplex communication and can manage connection lifecycle (heartbeats, reconnection) yourself.

Simple Node.js server (ws library)

// server.js
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', ws => {
  console.log('Client connected');

  // Echo incoming messages
  ws.on('message', msg => {
    console.log('Received:', msg);
    ws.send(`Echo: ${msg}`);
  });

  // Periodic ping to keep the connection alive
  const interval = setInterval(() => ws.ping(), 30000);
  ws.on('close', () => clearInterval(interval));
});

Browser client

<script>
  const socket = new WebSocket('ws://localhost:8080');

  socket.addEventListener('open', () => {
    console.log('Connected');
    socket.send('Hello Server');
  });

  socket.addEventListener('message', e => {
    console.log('Server says:', e.data);
  });

  socket.addEventListener('close', () => console.log('Disconnected'));
</script>

Server‑Sent Events (SSE)

What it is:
A unidirectional, server‑to‑client streaming protocol built on top of HTTP/1.1. The client initiates a GET request with Accept: text/event-stream, and the server keeps the connection open, pushing events as plain text.

Key Characteristics

  • Simple API: EventSource in browsers.
  • Automatic reconnection: Built‑in retry logic.
  • Text‑only: Payload is UTF‑8 strings (often JSON).
  • No binary support: Not suitable for large binary blobs.
  • Works over HTTP/2: Benefits from multiplexing.

When to use:
For live feeds where the client only needs to receive updates (e.g., news tickers, stock prices, monitoring dashboards).

Express.js SSE endpoint

// sse.js
const express = require('express');
const app = express();

app.get('/stream', (req, res) => {
  res.set({
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    Connection: 'keep-alive',
  });
  res.flushHeaders();

  let counter = 0;
  const timer = setInterval(() => {
    counter++;
    const data = JSON.stringify({ timestamp: Date.now(), count: counter });
    res.write(`event: update\n`);
    res.write(`data: ${data}\n\n`);
  }, 2000);

  req.on('close', () => {
    clearInterval(timer);
    res.end();
  });
});

app.listen(3000, () => console.log('SSE on http://localhost:3000/stream'));

Browser client

const source = new EventSource('/stream');

source.addEventListener('update', e => {
  const payload = JSON.parse(e.data);
  console.log('Update:', payload);
});

source.onerror = err => console.error('SSE error', err);

Long Polling

What it is:
A classic workaround for browsers lacking true push capabilities. The client sends an HTTP request; the server holds the request open until data is available or a timeout occurs, then the client immediately re‑issues the request.

Key Characteristics

  • Works everywhere: No special browser features needed.
  • Higher latency: Dependent on server response time.
  • More HTTP overhead: Each poll includes full headers.
  • Stateless server design: Easier to scale with load balancers.

When to use:
When you must support very old browsers or strict corporate proxies that block WebSockets and SSE.

Node.js long‑polling example (express)

// long-poll.js
const express = require('express');
const app = express();

let messages = [];
let waitingClients = [];

app.use(express.json());

// Client posts a new message
app.post('/msg', (req, res) => {
  messages.push(req.body);
  // Notify all waiting clients
  waitingClients.forEach(cb => cb());
  waitingClients = [];
  res.status(204).end();
});

// Client polls for new messages
app.get('/msg', (req, res) => {
  if (messages.length) {
    const batch = messages;
    messages = [];
    return res.json(batch);
  }

  // No messages yet: hold the request
  const timeout = setTimeout(() => {
    waitingClients = waitingClients.filter(cb => cb !== onReady);
    res.status(204).end();
  }, 30000); // 30‑second max wait

  const onReady = () => {
    clearTimeout(timeout);
    const batch = messages;
    messages = [];
    res.json(batch);
  };
  waitingClients.push(onReady);
});

app.listen(4000, () => console.log('Long polling on http://localhost:4000'));

HTTP/2 Server Push & HTTP/3 QUIC

What they are:

  • HTTP/2 Server Push allows the server to pre‑emptively send resources (e.g., CSS, JS, JSON) before the client requests them, using the same multiplexed connection.
  • HTTP/3 (based on QUIC) brings similar push capabilities, lower latency handshakes, and built‑in congestion control.

Key Characteristics

  • Multiplexed streams: Multiple logical streams share a single connection.
  • Header compression (HPACK/QPACK): Reduces overhead.
  • Binary framing: More efficient than plain text.
  • Limited browser support for push (Chrome, Edge) – many developers now prefer SSE or WebSockets for explicit push.

When to use:

  • Pre‑fetching assets for single‑page apps.
  • Push of small, predictable updates (e.g., configuration files) where you want to avoid extra round‑trips.
  • Low‑latency streaming in high‑performance services where you control both client and server (e.g., mobile SDKs using HTTP/3).

Node.js HTTP/2 push example

// http2-push.js
const http2 = require('http2');
const fs = require('fs');
const server = http2.createSecureServer({
  key: fs.readFileSync('localhost-key.pem'),
  cert: fs.readFileSync('localhost-cert.pem')
});

server.on('stream', (stream, headers) => {
  const path = headers[':path'];
  if (path === '/') {
    // Push a CSS file before sending HTML
    stream.pushStream({ ':path': '/styles.css' }, (err, push) => {
      if (!err) {
        push.respond({ ':status': 200, 'content-type': 'text/css' });
        push.end('body { background: #fafafa; }');
      }
    });
    stream.respond({ ':status': 200, 'content-type': 'text/html' });
    stream.end('<!doctype html><html><head><link rel="stylesheet" href="/styles.css"></head><body>Hello HTTP/2!</body></html>');
  }
});

server.listen(8443);

Message‑Oriented Middleware

Real‑time systems often require decoupled, brokered messaging where producers and consumers don’t know each other’s network locations. Middleware solves this via topics, queues, and routing patterns.

MQTT

What it is:
A lightweight publish/subscribe protocol designed for constrained devices and low‑bandwidth networks (ISO/IEC 20922). Operates over TCP (or WebSockets) on port 1883 (or 443 for secure).

Key Characteristics

  • Small header (≈2 bytes) – ideal for IoT.
  • QoS levels:
    • 0 – at most once (fire‑and‑forget)
    • 1 – at least once (acknowledged)
    • 2 – exactly once (two‑phase handshake)
  • Retained messages: New subscribers receive the last retained payload.
  • Last‑Will‑Testament (LWT): Notifies others when a client disconnects ungracefully.
  • Topic hierarchy: /sensors/room1/temperature.

When to use:

  • IoT telemetry, mobile push, home automation, or any scenario with many low‑power clients.

Python MQTT publisher (paho‑mqtt)

import paho.mqtt.client as mqtt
import json, random, time

client = mqtt.Client()
client.username_pw_set("user", "pass")
client.tls_set()  # optional TLS
client.connect("broker.example.com", 8883)

while True:
    payload = json.dumps({
        "temp": round(20 + random.random()*5, 2),
        "ts": int(time.time())
    })
    client.publish("sensors/room1/temperature", payload, qos=1, retain=True)
    time.sleep(5)

JavaScript MQTT subscriber (mqtt.js over WebSocket)

import mqtt from 'mqtt';

const url = 'wss://broker.example.com/mqtt';
const client = mqtt.connect(url, {
  username: 'user',
  password: 'pass',
});

client.on('connect', () => client.subscribe('sensors/room1/temperature'));

client.on('message', (topic, message) => {
  console.log('Topic:', topic);
  console.log('Payload:', JSON.parse(message.toString()));
});

AMQP / RabbitMQ

What it is:
Advanced Message Queuing Protocol (AMQP) is a binary, application‑layer protocol for message‑oriented middleware. RabbitMQ is the most popular open‑source broker implementing AMQP 0‑9‑1.

Key Characteristics

  • Complex routing: Exchanges (direct, fanout, topic, headers) + bindings.
  • Acknowledgments & durability: Guarantees delivery even after broker restart.
  • Flow control & back‑pressure: Prevents overload.
  • Plugins for WebSocket, STOMP, MQTT: Enables browser clients.

When to use:

  • Enterprise integration where reliability, transactions, and sophisticated routing are mandatory.
  • Task queues (e.g., background job processing) combined with real‑time notifications.

Node.js producer (amqplib)

const amqp = require('amqplib');

async function publish() {
  const conn = await amqp.connect('amqp://guest:guest@localhost');
  const ch = await conn.createChannel();
  const exchange = 'logs';
  await ch.assertExchange(exchange, 'fanout', { durable: false });

  setInterval(() => {
    const msg = `Log ${new Date().toISOString()}`;
    ch.publish(exchange, '', Buffer.from(msg));
    console.log('Sent:', msg);
  }, 2000);
}
publish().catch(console.error);

Python consumer

import pika

def callback(ch, method, properties, body):
    print("Received:", body.decode())

connection = pika.BlockingConnection(pika.URLParameters('amqp://guest:guest@localhost/'))
channel = connection.channel()
channel.exchange_declare(exchange='logs', exchange_type='fanout')
result = channel.queue_declare('', exclusive=True)
queue_name = result.method.queue
channel.queue_bind(exchange='logs', queue=queue_name)

channel.basic_consume(queue=queue_name, on_message_callback=callback, auto_ack=True)
print('Waiting for logs...')
channel.start_consuming()

NATS

What it is:
A high‑performance, cloud‑native messaging system using a simple publish/subscribe model. It emphasizes speed (sub‑microsecond latency) and scalability via clustering and leaf nodes.

Key Characteristics

  • Stateless core: No persistence by default (though JetStream adds streams and durability).
  • Subject‑based routing: orders.created, orders.*.
  • Request‑reply pattern: Supports RPC‑style interactions.
  • Automatic reconnection & heartbeats.

When to use:

  • Microservice communication where ultra‑low latency is crucial (e.g., financial trading, real‑time analytics).
  • Event‑driven architectures that need simple pub/sub without heavy broker configuration.

Go NATS example

package main

import (
    "log"
    "github.com/nats-io/nats.go"
)

func main() {
    nc, _ := nats.Connect(nats.DefaultURL)
    defer nc.Drain()

    // Subscriber
    nc.Subscribe("updates.*", func(m *nats.Msg) {
        log.Printf("Received on %s: %s", m.Subject, string(m.Data))
    })

    // Publisher
    for i := 0; i < 5; i++ {
        nc.Publish("updates.stock", []byte(fmt.Sprintf("price=%d", 100+i)))
        time.Sleep(time.Second)
    }
}

Remote Procedure Call (RPC) Frameworks

While pub/sub excels at broadcasting, many real‑time apps need bidirectional request/response streams with strong typing.

gRPC

What it is:
Google’s open‑source RPC framework built on HTTP/2, using Protocol Buffers for schema definition. Supports unary, server‑streaming, client‑streaming, and bidirectional streaming RPCs.

Key Characteristics

  • Strongly typed contracts: Compile‑time generation of client & server stubs.
  • Binary payloads: Protobuf is compact and fast.
  • Multiplexed streams: Multiple RPCs share a single HTTP/2 connection.
  • Built‑in authentication (TLS, token metadata).
  • Cross‑language support: Go, Java, C#, Python, Node.js, etc.

When to use:

  • Microservice APIs where latency and contract safety matter.
  • Real‑time data pipelines (e.g., telemetry streaming from edge devices).
  • Hybrid systems that combine request‑response with streaming (e.g., chat with presence updates).

Proto definition (chat.proto)

syntax = "proto3";

package chat;

service Chat {
  // Bidirectional streaming for chat messages
  rpc Stream(stream Message) returns (stream Message);
}

message Message {
  string user = 1;
  string text = 2;
  int64 timestamp = 3;
}

Node.js server (grpc-js)

const grpc = require('@grpc/grpc-js');
const protoLoader = require('@grpc/proto-loader');
const packageDef = protoLoader.loadSync('chat.proto', {});
const chatProto = grpc.loadPackageDefinition(packageDef).chat;

function stream(call) {
  call.on('data', msg => {
    console.log('Received:', msg);
    // Echo back with server timestamp
    const reply = {
      user: 'server',
      text: `Echo: ${msg.text}`,
      timestamp: Date.now(),
    };
    call.write(reply);
  });
  call.on('end', () => call.end());
}

const server = new grpc.Server();
server.addService(chatProto.Chat.service, { Stream: stream });
server.bindAsync('0.0.0.0:50051', grpc.ServerCredentials.createInsecure(), () => {
  server.start();
  console.log('gRPC server listening on 50051');
});

Python client

import grpc, chat_pb2, chat_pb2_grpc, time

channel = grpc.insecure_channel('localhost:50051')
stub = chat_pb2_grpc.ChatStub(channel)

def generate_messages():
    for i in range(5):
        yield chat_pb2.Message(user='client', text=f'Hello {i}', timestamp=int(time.time()))
        time.sleep(1)

responses = stub.Stream(generate_messages())
for resp in responses:
    print(f'[{resp.timestamp}] {resp.user}: {resp.text}')

GraphQL Subscriptions

What it is:
An extension to the GraphQL query language that enables real‑time data via a subscription operation. Typically implemented over WebSockets using the graphql-ws or subscriptions-transport-ws protocols.

Key Characteristics

  • Single endpoint: Queries, mutations, and subscriptions share the same schema.
  • Declarative data selection: Clients specify exactly which fields they want.
  • Leverages existing GraphQL tooling (type validation, resolvers, authorization).

When to use:

  • Applications already built around GraphQL that need real‑time updates (e.g., collaborative dashboards).
  • Fine‑grained field selection for bandwidth‑constrained clients.

Apollo Server with Subscriptions (Node.js)

import { ApolloServer, gql } from '@apollo/server';
import { makeExecutableSchema } from '@graphql-tools/schema';
import { PubSub } from 'graphql-subscriptions';
import { createServer } from 'http';
import { WebSocketServer } from 'ws';
import { useServer } from 'graphql-ws/lib/use/ws';

const typeDefs = gql`
  type Message {
    id: ID!
    text: String!
    author: String!
  }

  type Query {
    _empty: String
  }

  type Subscription {
    messageAdded: Message!
  }

  type Mutation {
    addMessage(text: String!, author: String!): Message!
  }
`;

const pubsub = new PubSub();
const resolvers = {
  Mutation: {
    addMessage: (_, { text, author }) => {
      const msg = { id: Date.now().toString(), text, author };
      pubsub.publish('MESSAGE_ADDED', { messageAdded: msg });
      return msg;
    },
  },
  Subscription: {
    messageAdded: {
      subscribe: () => pubsub.asyncIterator(['MESSAGE_ADDED']),
    },
  },
};

const schema = makeExecutableSchema({ typeDefs, resolvers });
const server = new ApolloServer({ schema });
await server.start();

const httpServer = createServer();
const wsServer = new WebSocketServer({
  server: httpServer,
  path: '/graphql',
});
useServer({ schema }, wsServer);

await new Promise(r => httpServer.listen({ port: 4000 }, r));
console.log('🚀 Server ready at http://localhost:4000');

React client (Apollo)

import { gql, useSubscription } from '@apollo/client';

const MESSAGE_SUB = gql`
  subscription OnMessageAdded {
    messageAdded {
      id
      text
      author
    }
  }
`;

export function MessageFeed() {
  const { data, loading } = useSubscription(MESSAGE_SUB);
  if (loading) return <p>Loading...</p>;

  return (
    <ul>
      {data.messageAdded.map((msg: any) => (
        <li key={msg.id}>
          <strong>{msg.author}:</strong> {msg.text}
        </li>
      ))}
    </ul>
  );
}

Data Serialization Formats

Choosing the right payload format is as important as picking the transport. Below is a quick comparison of the most common formats used with non‑SocketIO real‑time channels.

FormatBinary?Schema?Typical Size (vs JSON)Language SupportIdeal Use‑Case
JSONNoNone (dynamic)1× (baseline)Every languageQuick prototyping, human‑readable logs
MessagePackYesOptional~0.5×Broad (Node, Python, Go, Rust)Low‑overhead binary over WebSocket or MQTT
Protocol BuffersYesStrong (.proto)~0.3×Google‑backed (Go, Java, C#, Python, JS)gRPC, high‑performance microservices
Apache AvroYesStrong (JSON schema)~0.4×Hadoop ecosystem, Java, PythonBig data pipelines, schema evolution
CBORYesOptional~0.4×IoT, embedded (C, Rust)Constrained devices needing JSON‑like API

Example: MessagePack over WebSocket

Server (Node.js, ws + msgpack5)

const WebSocket = require('ws');
const msgpack = require('msgpack5')();

const wss = new WebSocket.Server({ port: 8081 });
wss.on('connection', ws => {
  ws.on('message', data => {
    const obj = msgpack.decode(data);
    console.log('Decoded:', obj);
    // Echo back a binary response
    const reply = msgpack.encode({ ack: true, ts: Date.now() });
    ws.send(reply);
  });
});

Browser client

import msgpack from 'msgpack-lite';

const socket = new WebSocket('ws://localhost:8081');
socket.binaryType = 'arraybuffer';

socket.addEventListener('open', () => {
  const payload = msgpack.encode({ cmd: 'ping', ts: Date.now() });
  socket.send(payload);
});

socket.addEventListener('message', e => {
  const data = new Uint8Array(e.data);
  const obj = msgpack.decode(data);
  console.log('Server ack:', obj);
});

Binary formats dramatically reduce bandwidth, which is critical for mobile networks or large‑scale telemetry streams.

Choosing the Right Tool: Decision Matrix

Below is a condensed matrix that helps map requirements → protocol → serialization.

RequirementRecommended TransportSerializationReasoning
Bidirectional chat with rich UIWebSocket (or gRPC‑Web)JSON or MessagePackLow latency, full duplex, easy browser support
IoT sensor telemetry (thousands of devices)MQTT over TCP or WebSocketMessagePack or ProtobufSmall header, QoS levels, retained messages
Server‑to‑client live feed (stock ticker) with no client writesSSE (or HTTP/2 push)JSON (or CSV)Simpler client, automatic reconnection
Enterprise task queue + progress notificationsAMQP (RabbitMQ) + WebSocket bridgeJSONRobust routing, durability, and optional real‑time bridge
Microservices with strict contractsgRPC (HTTP/2)Protocol BuffersStrong typing, streaming, multiplexed calls
Legacy browsers behind corporate proxyLong PollingJSONWorks everywhere, albeit higher latency
High‑frequency trading platformNATS JetStream + ProtobufProtobufSub‑microsecond latency, clustering, persistence
GraphQL‑centric front‑end needing real‑timeGraphQL Subscriptions (WebSocket)JSON (GraphQL response)Unified schema, field selection
Low‑bandwidth mobile push notificationsHTTP/2 Server Push (or SSE over HTTP/2)JSONLeverages existing HTTP/2 connection, minimal overhead

Scaling, Security, and Operational Considerations

1. Horizontal Scaling

TransportScaling Strategy
WebSocketUse a sticky session load balancer (e.g., NGINX ip_hash) or a message broker (Redis Pub/Sub, Kafka) to broadcast events across nodes.
SSEStateless; can be load‑balanced without sticky sessions because each connection is independent.
MQTTDeploy a clustered broker (e.g., Mosquitto with bridge, EMQX) for high availability.
gRPCRely on HTTP/2 connection pooling; front‑ends can use Envoy or Istio for load balancing.
NATSNative cluster mode; leaf nodes enable geographic distribution.
AMQPUse mirrored queues or high‑availability policies in RabbitMQ.

2. Authentication & Authorization

  • WebSocket & SSE – Upgrade request can carry JWT in Authorization header or query string; server validates before establishing the stream.
  • MQTT – Username/password, client certificates, or token‑based authentication via plugins.
  • gRPC – Metadata interceptors for OAuth2, mTLS, or custom API keys.
  • NATS – Supports JWT‑based user permissions (NATS 2.0+).

3. TLS / Encryption

All modern transports support TLS:

  • WebSocket Secure (wss://) – Same TLS handshake as HTTPS.
  • SSE – Delivered over HTTPS.
  • MQTT – mqtts:// or WebSocket over TLS.
  • gRPC – HTTP/2 over TLS (default in production).
  • NATS – TLS or NATS‑TLS for encrypted traffic.

4. Monitoring & Observability

  • Metrics – Prometheus exporters exist for ws, mqtt, nats, grpc. Export connection counts, message rates, latency histograms.
  • Tracing – OpenTelemetry instrumentation for WebSocket (ws), gRPC, and NATS enables end‑to‑end request tracing.
  • Logging – Structured logs (JSON) with correlation IDs help debug dropped messages.

5. Fault Tolerance

  • Heartbeat / Ping – WebSocket ping/pong, MQTT keepalive, NATS PING, gRPC keepalive.
  • Retry Strategies – Exponential backoff for reconnection; client libraries often provide built‑in logic (e.g., socket.io-client but also mqtt.js).
  • Message Persistence – Use broker‑side persistence (MQTT QoS 1/2, RabbitMQ durable queues, NATS JetStream) for guaranteed delivery.

Practical Example: Building a Multi‑Protocol Notification Service

Let’s synthesize the concepts into a real‑world scenario: A SaaS platform wants to push critical alerts to three distinct consumer groups:

  1. Web Dashboard – Rich UI, needs low latency.
  2. Mobile App – May be offline intermittently, bandwidth‑constrained.
  3. Third‑Party Integration – Other services need to consume alerts via a standard API.

Architecture Overview

+-------------------+               +-------------------+
|   Web Front‑end  |   WebSocket   |   Notification   |
| (React/Angular)   | <-----------> |   Service (Node) |
+-------------------+               +-------------------+
          |                                      |
          | SSE (fallback)                       |
          v                                      v
+-------------------+               +-------------------+
|   Mobile Client  |   MQTT (WS)   |   MQTT Broker     |
| (React Native)   | <-----------> |   EMQX Cluster    |
+-------------------+               +-------------------+

          |
          | gRPC (bidirectional streaming)
          v
+-------------------+
|  Integration API  |
| (Go / Java)      |
+-------------------+

Step‑by‑Step Implementation

1. Core Notification Service (Node.js)

We’ll use Express for HTTP endpoints, ws for WebSocket, mqtt library for MQTT publishing, and @grpc/grpc-js for gRPC streaming.

// notifier.js
const express = require('express');
const http = require('http');
const WebSocket = require('ws');
const mqtt = require('mqtt');
const grpc = require('@grpc/grpc-js');
const protoLoader = require('@grpc/proto-loader');
const path = require('path');

const app = express();
app.use(express.json());

const server = http.createServer(app);
const wss = new WebSocket.Server({ server });

// MQTT client (WebSocket transport)
const mqttClient = mqtt.connect('wss://mqtt.example.com:8083/mqtt', {
  username: 'notifier',
  password: 'secret',
});

// Load gRPC proto
const protoPath = path.join(__dirname, 'alert.proto');
const packageDef = protoLoader.loadSync(protoPath, {});
const alertProto = grpc.loadPackageDefinition(packageDef).alert;

// Store active gRPC streams for broadcasting
const grpcStreams = new Set();

// ----- HTTP endpoint to post alerts -----
app.post('/alert', (req, res) => {
  const alert = { ...req.body, ts: Date.now() };
  broadcast(alert);
  res.status(202).json({ status: 'queued' });
});

// ----- WebSocket broadcast -----
function broadcast(alert) {
  // 1. WebSocket (dashboard)
  wss.clients.forEach(ws => {
    if (ws.readyState === WebSocket.OPEN) {
      ws.send(JSON.stringify(alert));
    }
  });

  // 2. MQTT (mobile)
  const topic = `alerts/${alert.severity}`;
  mqttClient.publish(topic, JSON.stringify(alert), { qos: 1 });

  // 3. gRPC streams (integrations)
  for (const call of grpcStreams) {
    call.write(alert);
  }
}

// ----- SSE fallback for browsers that cannot use WS -----
app.get('/sse', (req, res) => {
  res.set({
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    Connection: 'keep-alive',
  });
  const send = data => {
    res.write(`data: ${JSON.stringify(data)}\n\n`);
  };
  // Simple in‑memory subscription
  const listener = alert => send(alert);
  wss.on('connection', () => {}); // keep reference for cleanup (omitted)
  // Attach listener
  wss.on('alert', listener);
  req.on('close', () => wss.removeListener('alert', listener));
});

// ----- gRPC server -----
function streamAlerts(call) {
  grpcStreams.add(call);
  call.on('cancelled', () => grpcStreams.delete(call));
}
const grpcServer = new grpc.Server();
grpcServer.addService(alertProto.AlertService.service, { StreamAlerts: streamAlerts });
grpcServer.bindAsync('0.0.0.0:50051', grpc.ServerCredentials.createInsecure(), () => {
  grpcServer.start();
  console.log('gRPC streaming on 50051');
});

// ----- Start HTTP + WS server -----
const PORT = 8080;
server.listen(PORT, () => {
  console.log(`HTTP/WS server listening on http://localhost:${PORT}`);
});

2. Web Dashboard (React + WebSocket)

// Dashboard.tsx
import React, { useEffect, useState } from 'react';

type Alert = {
  id: string;
  severity: 'info' | 'warning' | 'critical';
  message: string;
  ts: number;
};

export function Dashboard() {
  const [alerts, setAlerts] = useState<Alert[]>([]);

  useEffect(() => {
    const ws = new WebSocket('ws://localhost:8080');
    ws.onmessage = ev => {
      const alert: Alert = JSON.parse(ev.data);
      setAlerts(prev => [alert, ...prev].slice(0, 50));
    };
    ws.onerror = err => console.error('WS error', err);
    return () => ws.close();
  }, []);

  return (
    <div>
      <h2>Live Alerts</h2>
      <ul>
        {alerts.map(a => (
          <li key={a.id}>
            <strong>{a.severity.toUpperCase()}:</strong> {a.message}{' '}
            <em>({new Date(a.ts).toLocaleTimeString()})</em>
          </li>
        ))}
      </ul>
    </div>
  );
}

3. Mobile Client (React Native + MQTT over WebSocket)

// MobileAlerts.tsx
import React, { useEffect, useState } from 'react';
import { View, Text, FlatList } from 'react-native';
import mqtt from 'mqtt';

type Alert = {
  message: string;
  severity: string;
  ts: number;
};

export function MobileAlerts() {
  const [alerts, setAlerts] = useState<Alert[]>([]);

  useEffect(() => {
    const client = mqtt.connect('wss://mqtt.example.com:8083/mqtt', {
      username: 'mobile',
      password: 'secret',
    });

    client.on('connect', () => {
      client.subscribe('alerts/#', { qos: 1 });
    });

    client.on('message', (_, payload) => {
      const alert = JSON.parse(payload.toString());
      setAlerts(prev => [alert, ...prev].slice(0, 30));
    });

    return () => client.end();
  }, []);

  return (
    <View>
      <Text style={{ fontSize: 20, marginBottom: 10 }}>Alerts</Text>
      <FlatList
        data={alerts}
        keyExtractor={(_, i) => i.toString()}
        renderItem={({ item }) => (
          <Text>
            [{new Date(item.ts).toLocaleTimeString()}] {item.severity}:{' '}
            {item.message}
          </Text>
        )}
      />
    </View>
  );
}

4. Integration Service (Go – gRPC streaming client)

// client.go
package main

import (
	"context"
	"io"
	"log"
	"time"

	pb "example.com/alertpb"
	"google.golang.org/grpc"
)

func main() {
	conn, err := grpc.Dial("localhost:50051", grpc.WithInsecure())
	if err != nil {
		log.Fatalf("dial: %v", err)
	}
	defer conn.Close()

	client := pb.NewAlertServiceClient(conn)
	stream, err := client.StreamAlerts(context.Background())
	if err != nil {
		log.Fatalf("stream: %v", err)
	}

	for {
		alert, err := stream.Recv()
		if err == io.EOF {
			break
		}
		if err != nil {
			log.Printf("recv error: %v", err)
			time.Sleep(time.Second)
			continue
		}
		log.Printf("Received alert: %s - %s", alert.Severity, alert.Message)
	}
}

alert.proto (used by both server and Go client)

syntax = "proto3";

package alert;

service AlertService {
  rpc StreamAlerts(Empty) returns (stream Alert);
}

message Empty {}

message Alert {
  string id = 1;
  string severity = 2;
  string message = 3;
  int64 ts = 4;
}

Outcome

  • Dashboard receives updates instantly via WebSocket.
  • Mobile app stays online via MQTT, benefiting from QoS 1 guarantees and automatic reconnection.
  • Third‑party services consume alerts through a strongly typed gRPC stream, enabling sophisticated processing pipelines.

The architecture demonstrates how multiple non‑SocketIO transports can coexist under a single logical notification domain, each chosen for its strengths.

Conclusion

Socket.IO offers a convenient, all‑in‑one solution for many real‑time web needs, but it is far from the only tool in the toolbox. By understanding and leveraging non‑SocketIO types—WebSockets, Server‑Sent Events, Long Polling, MQTT, AMQP, NATS, gRPC, GraphQL Subscriptions, and the appropriate serialization formats—you can:

  • Match the protocol to the problem (duplex vs. uni‑directional, low‑latency vs. high‑reliability).
  • Scale horizontally with stateless transports or broker clusters.
  • Guarantee delivery where it matters via QoS levels or persistent streams.
  • Maintain strong contracts using Protobuf or Avro, improving developer productivity.
  • Future‑proof your system by selecting standards that enjoy broad language support and active community backing.

When designing a real‑time system, start by listing functional and non‑functional requirements, consult the decision matrix, and prototype with the lightweight options before committing to a full‑blown broker. The right combination of transports and data formats will keep your application responsive, secure, and maintainable—no matter how many users or devices you need to serve.

Resources

These resources provide deeper dives into each technology discussed and can help you prototype, benchmark, and productionize the solutions that best fit your real‑time needs.