Who owns the clock? Lessons from a live Blazor and SignalR multiplayer game
A developer describes building a live bingo game on .NET 10, shared by a Blazor Web App and a MAUI Blazor Hybrid app over SignalR. The post covers keeping the game lifecycle on the server, using a BackgroundService to announce start times, making joins idempotent, and handling InteractiveAuto components that boot twice. It is a practical read for anyone building real-time Blazor apps.
Key points
- The game lifecycle is one enum derived on the server and pushed over SignalR; clients compute it locally only on a cold start.
- A BackgroundService with a PeriodicTimer ticks every 15 seconds and checks only games with connected visitors.
- Ending a game sets IsEnded = true in the database before broadcasting, so only one ending can win.
- Joining is an idempotent POST to /api/bingo/joingame; loading a game is a read-only GET.
- InteractiveAuto components can boot twice, so server state is re-fetched each time and JS interop setup must be safe to rerun.
The author built a live bingo game for meetings and watch parties, shared by a Blazor Web App and a MAUI Blazor Hybrid app through one Razor Class Library and SignalR. The main lesson is that the server should own the game lifecycle, since clients that guess the state on their own quickly drift apart.
The post walks through a single lifecycle enum derived on the server, a BackgroundService that wakes every 15 seconds to announce a start time and end finished games, and a database flag that prevents a double ending. Joining is a separate, idempotent POST rather than a GET that writes state, and a registry keeps only the newest browser session active. The author also notes that InteractiveAuto components can boot on the server and again in the browser, so state must be re-fetched and interop setup must be safe to rerun.
Real-world use
- A live quiz, poll or voting app where many phones must show the same state at the same time.
- A Blazor Web App with scheduled events that must notify connected users at a set time.
- A product that shares one Razor Class Library between a website and a MAUI Blazor Hybrid app.
Why it matters
In a real-time Blazor app the server should own state, because client caches and components that reboot under InteractiveAuto can show conflicting truths or fire duplicate events. The patterns here apply directly to any SignalR-backed app.