So far the Kladde has talked to the outside world in two ways. A program asks its API (modules 2.3 and 2.12), and the Kladde calls a foreign address on its own through a webhook (lesson 2.12.5). One way is still missing: the server tells an open browser on its own that something has happened. Someone in the office who has the appointment list open only learns about a new booking when they reload the page.
ASP.NET Core has SignalR for this. You already know it without having called it that: the connection behind the interactive islands from
lesson 2.5.8, the circuit under /_blazor, is a SignalR connection. In this module you build a hub of your own, through which the Kladde sends
messages to signed-in browsers. By the end of this lesson a new booking appears on the appointment list as soon as it is saved, and a screen
reader announces it.
When real time is worth it and when a reload is enough
An open connection per browser tab costs something: memory on the server, a connection the server has to hold, a script in the browser, and one more part that can fail. So the same question comes before the first hub as before the first island in lesson 2.5.8.
| Way | fits when | Example in the Kladde |
|---|---|---|
| Reload | the data rarely changes, or it doesn't matter whether you see a change a few minutes later | the contact list, last night's tenders |
| Interactive island (lesson 2.5.8) | one person takes many small steps on their page | the week calendar: paging without reloading the page |
| Hub of your own | a change that someone else triggers should reach many open pages within seconds | a new booking appears for everyone who has the appointment list open right now |
The island doesn't solve the appointment list's problem on its own. It talks to the server all the time, but only about its own clicks. If someone outside books an appointment, the island knows nothing about it. It takes a way for the server to tell all open pages.
And one rule holds for every live display: it is a hint, not a delivery. Whoever has no connection at the moment misses the message. That is fine as long as the page is correct after a reload. What must not get lost, such as the confirmation email to the person who booked, still goes through the outbox from lesson 2.8.4.