Chapter 4: Adding order-tracking functionality with SignalR
The chapter introduces a delivery-tracking app whose map updates automatically as a driver moves, and identifies the two capabilities needed to build it.
After this chapter you will be able to
- Automatic delivery map updates. Describe the intended delivery-tracking experience: the backend tracks a driver’s coordinates, and the map marker updates when the driver moves without the user refreshing the screen.
- Real-time client–server communication. Explain that SignalR lets servers push updates to connected clients in real time and supports communication in both directions over a single connection. Give a use case such as live chat, notifications, or location tracking.
- Transport choices and fallback. Describe SignalR's default use of WebSocket and its ability to fall back to server-sent events or long polling when WebSocket cannot be used. Distinguish long polling from server-initiated pushes.
- Hub abstraction for calls. Explain that SignalR hubs provide high-level remote procedure call APIs through which the server and client can call methods on each other, avoiding manual implementation of transport mechanisms.
- OpenLayers mapping role. Explain why the order-tracking UI uses OpenLayers: it is a freely available JavaScript library for displaying dynamic, interactive maps in a browser and working with geographic data.
- Delivery-tracking backend responsibilities. Describe the two responsibilities assigned to OnlineShop.ApiService: hosting a SignalR hub for real-time communication and simulating a stream of location updates.
- Location hub and callable method. Describe how LocationHub is defined and what connected clients can pass to its UpdateLocation() method.
- Location update broadcast. Trace how UpdateLocation() sends coordinates to clients and how the clients identify the event to handle.
- SignalR hub registration. Explain that the OnlineShop.ApiService registers SignalR dependencies in Program.cs and associates the hub with an HTTP endpoint before app.Run(). Describe /locationHub as a chosen path relative to the service address, not a required pathname.
- Sending updates outside the hub. Explain how LocationUpdater can send updates to clients connected to LocationHub without running inside the hub.
- Background location simulation. Describe how LocationUpdater simulates delivery movement and how it is run.
- OpenLayers map initialization. Describe how the frontend JavaScript initializes the OpenLayers map, including its map object, base layer, and initial view.
- Delivery marker replacement. Trace what the JavaScript does when given new delivery-driver latitude and longitude coordinates.
- Frontend dependency placement. Describe where App.razor registers the OpenLayers library, its stylesheet, and the custom JavaScript file.
- Interactive rendering requirement. Explain why the default rendering mode must change and identify which App.razor elements receive the attribute for interactive rendering.
- SignalR service discovery. Explain why the SignalR connection needs a custom message-handler setup to use Aspire service discovery, and how that lets the page address the API service by name.
- Post-render connection timing. Explain why the page initializes its map and starts the SignalR connection after rendering, and why the earlier change away from static server-side rendering matters.
- Location update display. Trace how coordinates received through SignalR become a marker on the map, including the roles of JavaScript interop and the UI-thread update.
What it builds on
- Using service discovery (chapter 1) · Using Aspire service discovery to address services.
Section by section
Introduction
The chapter introduces a delivery-tracking app whose map updates automatically as a driver moves, and identifies the two capabilities needed to build it.
- Automatic delivery map updates: Describe the intended delivery-tracking experience: the backend tracks a driver’s coordinates, and the map marker updates when the driver moves without the user refreshing the screen.
Why it matters: This is the user-facing behavior the chapter’s real-time tracking system is meant to provide. - Real-time tracking library roles: Explain the two challenges identified for real-time tracking and match each to its library: SignalR manages live communication from server to browser, while OpenLayers displays the interactive map.
Why it matters: Separating communication from map display clarifies why the app uses both libraries.
Key terms: delivery-tracking app, driver’s coordinates, marker, SignalR, OpenLayers, real-time communication, interactive map
4.1 What is SignalR?
This section explains how SignalR provides real-time client–server communication, abstracts its transport through hubs, and supports updates across multiple servers.
- Real-time client–server communication: Explain that SignalR lets servers push updates to connected clients in real time and supports communication in both directions over a single connection. Give a use case such as live chat, notifications, or location tracking.
Why it matters: This is why SignalR fits features that need updates as they happen. - Transport choices and fallback: Describe SignalR's default use of WebSocket and its ability to fall back to server-sent events or long polling when WebSocket cannot be used. Distinguish long polling from server-initiated pushes.
Why it matters: Real-time functionality can remain available when WebSocket connections are not an option. - Hub abstraction for calls: Explain that SignalR hubs provide high-level remote procedure call APIs through which the server and client can call methods on each other, avoiding manual implementation of transport mechanisms.
Why it matters: Hubs are the programming abstraction used to manage SignalR interactions. - Updates across multiple servers: Explain that SignalR can scale across multiple servers using backplanes so clients receive updates regardless of which server they are connected to.
Why it matters: The real-time feature can serve clients connected to different servers in a distributed application.
Key terms: SignalR, real-time, bidirectional communication, push updates, WebSocket, server-sent events, long polling, transport mechanism, hubs, remote procedure calls (RPCs)
4.2 Introduction to OpenLayers
This section introduces OpenLayers as the browser-based mapping library for the order-tracking UI and describes the geographic data it can display.
- OpenLayers mapping role: Explain why the order-tracking UI uses OpenLayers: it is a freely available JavaScript library for displaying dynamic, interactive maps in a browser and working with geographic data.
Why it matters: This identifies what OpenLayers contributes to the tracking interface before the UI is built. - Vector and raster layers: Distinguish the vector and raster geographic data OpenLayers can render, using examples given in the section.
Why it matters: The distinction shows the range of geographic content the map library can display.
Key terms: OpenLayers, interactive maps, geographic data, vector, raster, layers
4.3 Building a delivery-tracking system
The section identifies the delivery-tracking backend’s responsibilities and clarifies that the example assumes an order has already been placed.
- Delivery-tracking backend responsibilities: Describe the two responsibilities assigned to OnlineShop.ApiService: hosting a SignalR hub for real-time communication and simulating a stream of location updates.
Why it matters: These two roles explain what the delivery-tracking backend is meant to provide without requiring implementation details yet. - Assumed order placement: Explain that this delivery-tracking example treats an order as already placed and focuses on Aspire integration rather than implementing order-processing business logic.
Why it matters: This boundary keeps the tracking example from being mistaken for a complete checkout and order-processing system.
Key terms: OnlineShop.ApiService, SignalR hub, location updates, Aspire integration, business logic, order-processing workflow
4.3.1 Setting up a SignalR hub
This section explains how the backend SignalR hub accepts delivery-driver coordinates and broadcasts them to connected clients.
- Backend SignalR dependency: State why OnlineShop.ApiService needs no additional NuGet package to use SignalR.
Why it matters: It clarifies what the backend already has available before adding the hub. - Location hub and callable method: Describe how LocationHub is defined and what connected clients can pass to its UpdateLocation() method.
Why it matters: This identifies the server-side entry point for location updates. - Location update broadcast: Trace how UpdateLocation() sends coordinates to clients and how the clients identify the event to handle.
Why it matters: It explains how a location update becomes an event that connected clients can receive.
Key terms: OnlineShop.ApiService, SignalR, ASP.NET Core SDK, NuGet dependencies, LocationHub, Hub, UpdateLocation(), latitude, longitude, SendAsync()
4.3.2 Registering a SignalR hub
The section explains how to register the SignalR hub and give it a recognizable HTTP endpoint.
- SignalR hub registration: Explain that the OnlineShop.ApiService registers SignalR dependencies in Program.cs and associates the hub with an HTTP endpoint before app.Run(). Describe /locationHub as a chosen path relative to the service address, not a required pathname.
Why it matters: Registration gives the hub an endpoint that clients can address.
Key terms: Program.cs, OnlineShop.ApiService, SignalR dependencies, HTTP endpoint, app.Run(), /locationHub
4.3.3 Simulating location updates
The section shows how a background service simulates delivery-driver movements and sends location updates to connected SignalR clients.
- Sending updates outside the hub: Explain how LocationUpdater can send updates to clients connected to LocationHub without running inside the hub.
Why it matters: The updater needs a way to reach connected clients while running outside the hub. - Background location simulation: Describe how LocationUpdater simulates delivery movement and how it is run.
Why it matters: This supplies changing location data for clients without requiring a real delivery driver.
Key terms: IHubContext, LocationHub, Clients property, LocationUpdater, background service, location updates
4.4 Building the frontend map UI
This section sets up the frontend SignalR client and describes JavaScript that displays an OpenLayers map and replaces its delivery-location marker as coordinates arrive.
- Frontend SignalR client dependency: Explain why OnlineShop.Web needs the Microsoft.AspNetCore.SignalR.Client NuGet package even though ASP.NET Core includes server-side SignalR components.
Why it matters: The web project needs the client library to act as a SignalR client. - OpenLayers map initialization: Describe how the frontend JavaScript initializes the OpenLayers map, including its map object, base layer, and initial view.
Why it matters: The location marker needs an initialized, visible map on which to appear. - Delivery marker replacement: Trace what the JavaScript does when given new delivery-driver latitude and longitude coordinates.
Why it matters: Replacing the old marker lets the map show the driver's latest reported location rather than accumulating past markers.
Key terms: OnlineShop.Web, Microsoft.AspNetCore.SignalR.Client, NuGet package, site.js, OpenLayers, ol, Map(), OSM, view, location marker
4.4.1 Registering frontend dependencies
This section prepares the Blazor frontend for a map by registering its JavaScript and CSS dependencies and enabling interactive rendering.
- Frontend dependency placement: Describe where App.razor registers the OpenLayers library, its stylesheet, and the custom JavaScript file.
Why it matters: These references put the map’s frontend dependencies in place before the map component is built. - Interactive rendering requirement: Explain why the default rendering mode must change and identify which App.razor elements receive the attribute for interactive rendering.
Why it matters: Interactive rendering allows the Blazor component to invoke the JavaScript needed for the frontend map.
Key terms: App.razor, OpenLayers, content delivery network (CDN), head tag, body tag, _framework/blazor.web.js, static server rendering, interactive render mode, HeadOutlet, Routes
4.4.2 Building the interactive UI
Builds a Blazor order-tracking page that connects to an Aspire-hosted SignalR hub and displays location updates on an interactive map.
- SignalR service discovery: Explain why the SignalR connection needs a custom message-handler setup to use Aspire service discovery, and how that lets the page address the API service by name.
Why it matters: It lets the frontend connect to the separately hosted backend without putting its IP address in the page. - Post-render connection timing: Explain why the page initializes its map and starts the SignalR connection after rendering, and why the earlier change away from static server-side rendering matters.
Why it matters: The map must be ready before the page starts receiving updates intended for it. - Location update display: Trace how coordinates received through SignalR become a marker on the map, including the roles of JavaScript interop and the UI-thread update.
Why it matters: It connects live backend location messages to a visible, updating frontend map.
Key terms: IHttpMessageHandlerFactory, HttpMessageHandlerFactory, WithUrl(), apiservice, service discovery, life-cycle event method, static server-side rendering mode, initializeMap, StartAsync(), IJSRuntime
4.5 Summary
Where this is used later
- Working with RabbitMQ (chapter 7) · The earlier delivery-tracking system whose order placement was emulated.
- Adding order-processing functionality (chapter 7) · Adds order-processing functionality that is outside this example’s scope.
- Adding the SignalR client to the page (chapter 5) · Provides an earlier example of handling SignalR events in a frontend UI.
Concepts explained in this chapter
- hubA SignalR abstraction that exposes methods for real-time communication between a server and connected clients.
- ASP.NET Core SignalRSignalR is a .NET library for real-time web communication between clients and servers, including bidirectional message delivery.
- SignalR connectionA client-side communication object that configures and maintains a connection to a SignalR hub.
- service discoveryService discovery is a mechanism by which services locate the network endpoints of other services dynamically rather than relying on fixed addresses.
- OpenLayersOpenLayers is an open-source JavaScript library for displaying and interacting with maps in web applications.
- JavaScript interopJavaScript interop is a mechanism for communication between .NET code in Blazor and JavaScript code running in the browser.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.