Days later: the STOMP pipe behind Britain's viral rail map

4 min read 1 source explainer
├── "The real story isn't the map — it's that Network Rail's open STOMP feed makes this kind of infrastructure trivially accessible to solo developers"
│  └── top10.dev editorial (top10.dev) → read below

The editorial reframes signalbox.io as a demonstration of an underappreciated public data feed. Network Rail publishes a real-time firehose over ActiveMQ/STOMP for free, and that infrastructure — not the map's polish — is what allowed one person to build what would normally be a six-figure consultancy project.

├── "Web developers should subscribe UIs directly to message brokers instead of defaulting to polling REST endpoints"
│  └── top10.dev editorial (top10.dev) → read below

The editorial argues signalbox.io illustrates a pattern most web devs have never internalized: the browser (via WebSocket bridge) or a Node process can subscribe directly to a STOMP broker, letting the broker itself act as the fanout. This eliminates the usual stack of polling, stale JSON endpoints, and self-managed Redis pub/sub that 'real-time' dashboards typically drag in.

└── "signalbox.io is impressive on its visual and UX merits"
  └── scrlk (Hacker News, 338 pts) → read

The submitter presented signalbox.io as a live map of every train on Great Britain's rail network, and the HN thread rewarded it with 338 points and 126 comments largely on the strength of how polished and responsive the interface is — dots sliding along tracks with headcode, origin, destination, and delay one click away.

What happened

signalbox.io climbed to 338 points on Hacker News this week with a deceptively simple pitch: a live map of every train currently moving on Great Britain's rail network. Dots slide along tracks in near-real-time. Click one and you get the headcode, origin, destination, and delay in seconds. It looks like something a Class 1 operator would pay a consultancy six figures to build.

It was built by one person, on free data, using off-the-shelf parts.

The hidden protagonist of the story is a piece of infrastructure most developers don't know exists: Network Rail's open-data STOMP feed. Network Rail — the state-owned company that runs the tracks — publishes a firehose of real-time messages via an ActiveMQ broker, spoken over STOMP (Simple Text Oriented Messaging Protocol). Train movements, TRUST reports, signalling area updates, VSTP schedule inserts. All of it. Free, with a signup form and a rate limit.

The HN thread we already covered focused on how good the map looks. The more interesting story — the one worth a follow-up — is what's *under* the map.

Why it matters

If you've never touched STOMP, here's the short version: it's a text-based protocol for talking to message brokers, roughly what HTTP is to REST APIs. Subscribe to a topic, receive messages as they're published, ack or nack them. It has none of the ceremony of Kafka, none of the vendor lock-in of SQS. It's boring, decades old, and — critically for hobbyists — trivial to consume from a browser via WebSocket bridges, or from a Node.js process in under 50 lines.

What signalbox.io demonstrates is a pattern most web devs have never internalized: your UI can subscribe directly to a message broker. The whole map is essentially `STOMP subscribe → transform → Mapbox layer update`. No polling. No REST endpoint returning stale JSON every 10 seconds. No Redis fanout you had to spin up yourself. The broker *is* the fanout.

This matters because most 'real-time' dashboards you build at work are polling REST endpoints at 5-second intervals and calling it live. It's not. It's a photocopier pretending to be a video camera. Every one of those dashboards would be simpler, cheaper, and genuinely real-time if the underlying system published to a broker and the UI subscribed. The reason it doesn't happen is cultural — nobody puts "knows STOMP" on a job req — not technical.

The other lesson is about public data. Network Rail's feed is not unique. TfL runs one. National Grid ESO publishes generation and demand feeds. NOAA has weather. USGS has real-time earthquake streams. FAA System Wide Information Management (SWIM) pushes flight data. The EU's Copernicus program dumps satellite passes. The moat around a project like signalbox.io isn't the tech — it's knowing the feed exists and being bothered enough to read the schema docs. Every public-facing dashboard startup you've seen in the last five years — flight radars, marine traffic, wildfire maps — is a thin veneer over a feed that's been sitting there, free, for years.

Community reaction on HN clustered around two themes. UK devs were nostalgic — several noted they'd built similar toys with the same feed a decade ago (opentraintimes.com being the classic). Non-UK devs asked the useful question: "why can't I get this for my country?" The answer is usually that the feed exists; it's just buried behind a national-transport-authority login page nobody links to from Google.

What this means for your stack

Three concrete takeaways for practitioners:

Stop building polling loops for internal dashboards. If your ops team is refreshing a Grafana panel every 30 seconds to watch a queue depth, you already have the message broker. Bridge it to WebSocket with something like `stompjs`, `mqtt.js`, or the AMQP-over-WebSocket bridges most brokers ship with. A 20-line change moves you from "kind of live" to "actually live" and drops your API load meaningfully.

Treat public data feeds as first-class dependencies. Before you scope a project that needs real-world data — logistics, environmental, traffic, energy — spend an afternoon searching for the raw feed. Not the JSON API the agency's dev portal advertises; the underlying push feed the JSON API is scraping. It's almost always there, almost always freer, and almost always fresher. The gap between a hobbyist toy and a VC-funded startup in this space is often just knowing which feed to subscribe to.

Learn one message protocol well. STOMP, MQTT, or AMQP — pick one and get comfortable. All three are portable, ancient, and dramatically underused in modern web work. Kafka gets all the resume real estate, but for consumer-facing real-time UIs — maps, dashboards, live scores, order books — the lighter-weight brokers are usually the right choice, and the deployment story is orders of magnitude simpler.

On a practical note: if you want to poke at Network Rail's feed yourself, sign up at datafeeds.networkrail.co.uk, use `stompjs` in Node, subscribe to `TRAIN_MVT_ALL_TOC`, and watch train movements stream into your console within about ten minutes of coding. That's the entire barrier to entry for the kind of project that got 338 HN points this week.

Looking ahead

The signalbox map will get its 15 minutes and fade. The lesson underneath it won't. As more of public infrastructure — transit, energy, weather, water — is instrumented and pushed to open feeds, the returns to being the person on your team who knows how to consume them will keep growing. The next viral "how did they build that" project is almost certainly already streaming past your Wi-Fi router, waiting for someone bothered enough to subscribe.

Hacker News 353 pts 135 comments

Real-time map of Great Britain's rail network

→ read on Hacker News

// share this

// get daily digest

Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.