You open Uber. You see your driver moving on the map. Every few seconds, their little car icon slides down the street toward you.
How does that work? How does your phone know where someone else's phone is, right now, updating constantly?
This post explains the technology behind real-time location tracking—without a single line of code. If you've ever wondered how apps show moving dots on maps, or why some websites feel "live" while others feel static, this is for you.
The Problem With Normal Websites
Let's start with how regular websites work.
Imagine you're at a restaurant. You sit down, look at the menu, and when you're ready, you raise your hand. A waiter comes over. You say "I'll have the pasta." The waiter goes to the kitchen, gets your pasta, brings it back, and leaves.
That's how normal websites work. Your browser (you) asks for something (raising your hand). The server (the kitchen) prepares it and sends it back. Then everyone goes quiet until you ask again.
This is called request-response. You request. They respond. Silence.
It works great for static content—articles, product pages, your bank balance. You load the page once and read it.
But what about live sports scores? Stock tickers? Uber drivers? You'd have to keep raising your hand every second: "Where's my driver now? And now? And now?"
That's exhausting. And slow. There has to be a better way.
The Phone Line That Stays Open
Here's the better way: instead of hanging up after each question, what if you just... kept the line open?
Imagine calling a friend and saying "I'm going to leave this call connected. Whenever something interesting happens, just tell me." You don't have to keep calling back. They just speak whenever there's news.
That's a WebSocket.
A WebSocket is a connection between your browser and a server that stays open. Instead of request-response-silence, it's more like a phone call that never hangs up. Either side can talk whenever they want.
When your Uber driver moves, their phone sends their location to Uber's servers. Those servers immediately push that update through the WebSocket to your phone. No waiting. No asking. The update just arrives.
This is what makes apps feel "live." The data flows in real-time, like a conversation, not like exchanging letters through the mail.
But Wait—What If the Call Drops?
Phone calls drop. Tunnels. Bad signal. Weak WiFi.
When you're tracking something important—like a delivery driver with your dinner—you don't want the map to just freeze when the connection hiccups.
This is where SignalR comes in.
SignalR is like a really persistent phone operator. It manages the WebSocket connection for you, and when the call drops, it automatically tries to reconnect. It has a strategy:
- First, it tries to reconnect immediately.
- If that fails, it waits 2 seconds and tries again.
- Then 5 seconds. Then 10. Then 30.
This is called "exponential backoff"—each retry waits longer, so you don't overwhelm the system by frantically redialing.
But here's the clever part: while SignalR keeps trying to restore the real-time connection, it doesn't leave you staring at a frozen screen. It falls back to the old way—asking "where is everyone?" every 30 seconds.
It's like if your phone call dropped, but while you're redialing, someone runs back and forth with handwritten notes. Slower, but you're never completely in the dark.
Drawing the Map
Okay, so now we understand how location data flows in real-time. But how does it actually appear on a map?
Enter Leaflet.
Leaflet is a library—think of it as a pre-built toolkit—that draws interactive maps in your browser. You've used Google Maps? Leaflet is what developers use to build their own custom maps.
It handles all the hard stuff:
- Loading the map tiles (those square images that make up the map)
- Letting you zoom and pan around
- Placing markers (like those driver icons) at specific coordinates
- Making markers clickable
When a location update arrives through SignalR, we tell Leaflet: "Move that marker from here to there." Leaflet handles the visual animation. The dot slides across the map.
The Translation Problem
Here's where it gets a little weird.
The app I'm building uses a technology called Blazor, which lets me write in a programming language called C#. It's like writing a recipe in French.
But Leaflet is written in JavaScript—a completely different language. It's like the map can only read English.
So how do you make them work together?
JavaScript Interop is basically translation.
Imagine you're the project manager, and you speak French. You have a brilliant map artist who only speaks English. You need to give them instructions: "Put a pin here. Move it there. Remove that one."
You don't learn English. You don't make them learn French. You hire a translator.
In our app, the translator is a thin layer of code that:
- Listens for French instructions from me (C#)
- Translates them into English commands for the map (JavaScript)
- And when the map has something to report back—like "someone clicked this marker"—translates that back into French
The clever bit: the translator doesn't try to explain everything to both sides. The map artist keeps all their paints and brushes (the Leaflet map, markers, and internal state). I just send instructions and receive events. I don't need to understand brushstrokes. They don't need to understand project management.
This separation is why it works smoothly. Each side does what it's good at.
Putting It All Together
So here's the full picture of how a real-time tracking map works:
A phone somewhere (the driver's, the delivery person's) captures GPS coordinates.
Those coordinates travel to a server, where they're stored and broadcast to anyone who needs them.
SignalR maintains an open connection between the server and everyone viewing the map. When new coordinates arrive, it pushes them instantly through that connection.
If the connection breaks, SignalR keeps trying to restore it while falling back to periodic polling.
JavaScript Interop translates those coordinates into map commands: "Move marker JD to latitude 43.0, longitude -87.9."
Leaflet updates the visual—the marker slides to its new position on the map.
All of this happens in under a second. The driver moves their truck. The supervisor sees the dot move. It feels like magic, but it's really just a chain of well-coordinated handoffs.
Why This Matters Beyond Tech
You might not be building a tracking app. But understanding this pattern helps you understand a lot of modern software:
- Chat applications use WebSockets so messages appear instantly instead of requiring you to refresh.
- Collaborative documents (like Google Docs) use similar real-time connections so you see others typing live.
- Stock tickers and sports scores stream through persistent connections.
- Online games need constant, low-latency communication—WebSockets are essential.
The web used to feel like reading a newspaper. Now it feels like having a conversation. WebSockets are the reason.
The Mental Model
If you remember one thing from this post, remember the phone call analogy:
Regular websites are like calling someone, asking a question, getting an answer, and hanging up. Every time you need something, you call again.
WebSockets are like calling someone and just... staying on the line. When either of you has something to say, you just talk.
SignalR is the phone operator who keeps the connection alive, redials when it drops, and sends messenger pigeons as a backup.
Leaflet is the artist who draws everything on the map.
JavaScript Interop is the translator who helps the project manager and the artist work together despite speaking different languages.
And when all of them work in concert, you get to watch a little car icon crawl toward your house with your pizza.
This is part of the ELI5 series—technical concepts explained without the jargon. If you want to see how these ideas translate into actual code, check out When Your Map Library Doesn't Speak C# and Making SignalR Connections That Don't Give Up.
Sometimes the best way to understand something technical is to forget it's technical at all.
