𝐓𝐡𝐞 𝐇𝐚𝐧𝐝𝐥𝐞𝐫 𝐏𝐚𝐭𝐭𝐞𝐫𝐧: 𝐇𝐨𝐰 𝐒𝐞𝐧𝐢𝐨𝐫 𝐄𝐧𝐠𝐢𝐧𝐞𝐞𝐫𝐬 𝐊𝐞𝐞𝐩 𝐖𝐞𝐛𝐒𝐨𝐜𝐤𝐞𝐭 𝐂𝐨𝐝𝐞 𝐒𝐜𝐚𝐥𝐚𝐛𝐥𝐞

Most WebSocket codebases start the same way: one onmessage callback, a few if statements… and before long you’re staring at a 300‑line switch statement handling trades, tickers, books, candles, heartbeats — all in one place.
It works… until you need to test it, extend it, or debug it at 2am.
There’s a better pattern.

𝐓𝐡𝐞 𝐑𝐞𝐚𝐥 𝐏𝐫𝐨𝐛𝐥𝐞𝐦
WebSocket messages arrive as raw arrays or objects with minimal type information.
The naive approach couples routing and processing in one giant function.
That makes the code:
Hard to test
Hard to extend
Hard to debug
Easy to break

𝐓𝐡𝐞 𝐇𝐚𝐧𝐝𝐥𝐞𝐫 𝐏𝐚𝐭𝐭𝐞𝐫𝐧
The idea is simple: separate routing from processing.

𝟏️⃣ 𝐎𝐧𝐞 𝐡𝐚𝐧𝐝𝐥𝐞𝐫 𝐩𝐞𝐫 𝐜𝐡𝐚𝐧𝐧𝐞𝐥
Each channel gets its own pure function — no WebSocket context, no global state, no side effects beyond dispatching.

export const handleTradesData = (parsed, subscription, dispatch) => {
const currencyPair = subscription.request.symbol.slice(1)

if (Array.isArray(parsed[1])) {
const trades = parsed[1]
.sort((a, b) => b[1] - a[1])
.map(([id, ts, amount, price]) => ({ id, ts, amount, price }))
dispatch(tradesSnapshotReducer({ currencyPair, trades }))
} else {
const [id, ts, amount, price] = parsed[2]
dispatch(tradesUpdateReducer({ currencyPair, trade: { id, ts, amount, price } }))
}
}

Each handler has one job. Nothing more.

𝟐️⃣ 𝐀 𝐥𝐨𝐨𝐤𝐮𝐩 𝐦𝐚𝐩 𝐚𝐬 𝐭𝐡𝐞 𝐫𝐨𝐮𝐭𝐞𝐫
The middleware doesn’t need to know what a “trade” or “candle” is — it just picks the right handler.

export const handlers = {
TRADES: handleTradesData,
TICKER: handleTickerData,
BOOK: handleBookData,
CANDLES: handleCandlesData,
}
Adding a new channel becomes a two‑line change.

𝟑️⃣ 𝐀 𝐭𝐡𝐢𝐧, 𝐩𝐫𝐞𝐝𝐢𝐜𝐭𝐚𝐛𝐥𝐞 𝐦𝐢𝐝𝐝𝐥𝐞𝐰𝐚𝐫𝐞
The middleware handles cross‑cutting concerns (latency, stale detection, heartbeats) and delegates everything else.

const handler = handlers[subscription.channel]
if (!handler) return

handler(parsedData, subscription, store.dispatch)

𝐖𝐡𝐲 𝐓𝐡𝐢𝐬 𝐌𝐚𝐭𝐭𝐞𝐫𝐬
Because now everything is testable in isolation:

it('handles trades snapshot', () => {
const dispatch = vi.fn()
handleTradesData(mockData, mockSubscription, dispatch)
expect(dispatch).toHaveBeenCalled()
})
No WebSocket server.
No Redux store.
No global state.
Just a function.

𝐓𝐡𝐞 𝐓𝐚𝐤𝐞𝐚𝐰𝐚𝐲
This pattern is the Single Responsibility Principle applied at the architecture level:
Middleware decides when to process
Handlers decide how to process
Adding features becomes additive, not destructive
Debugging becomes targeted, not chaotic
This is the difference between code that works and code that scales.

𝗪𝗿𝗶𝘁𝘁𝗲𝗻 𝗯𝘆 𝗥𝗶𝗰𝗮𝗿𝗱𝗼 𝗦𝗮𝘂𝗺𝗲𝘁𝗵
𝗦𝗲𝗻𝗶𝗼𝗿 𝗙𝗿𝗼𝗻𝘁‑𝗘𝗻𝗱 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿 | 𝗥𝗲𝗮𝗹‑𝗧𝗶𝗺𝗲 𝗨𝗜 𝗦𝗽𝗲𝗰𝗶𝗮𝗹𝗶𝘀𝘁