/v1/ws/prices, but the same pattern works for all six.
How it works
- Your backend opens one WebSocket connection to NGN Market, using the real API key from an environment variable.
- Your backend also runs its own WebSocket server, one your frontend connects to instead. No key required, since your backend is already authenticated upstream.
- Every message your backend receives from NGN Market gets forwarded to every browser client connected to it.
Backend: connect upstream, serve downstream
Node.js
Browser: connect to your own server, not NGN Market
Browser
snapshot/update, rendering prices) works exactly as it would if it had connected directly.
Tips
- Reconnect the upstream connection, not just the browser side. If your backend’s connection to NGN Market drops, every browser client downstream goes quiet too, even though their own connections are still open. Add reconnect-with-backoff logic to the
upstream.on('close', ...)handler above. - One upstream connection per symbol set you need, not per user. If different users need different watchlists on
/v1/ws/prices, open one upstream connection per distinct symbol set your app actually needs, and fan each one out to the browser clients that asked for it. That’s still far fewer connections than one per user. - This is a normal pattern, not a workaround. Proxying a key-authenticated connection through your own server is exactly how you’d already handle a REST API key in a frontend app. WebSocket doesn’t change that rule, it just changes where the key would otherwise leak if you skipped this step.
WebSocket Authentication
Why the key travels as a query parameter
Limits
How connections are counted per account