Here’s an overview of what problems SignalR solves, and how it does it using various technologies.
This blog post is apart of a course that is a complete step-by-setup guide on how to build real-time web applications using ASP.NET Core SignalR. By the end of this course, you’ll be able to build real-world, scalable, production applications using the tools and techniques provided in this course.
If you haven’t already, check out the prior sections of this course.
A common problem among web developer is refreshing data in real time. HTTP by nature is a stateless request-response protocol. The client (browser) makes a request to the server, which in turns provides a response.
Every time the client (browser) wants new data, it must make a request to the server. HTTP doesn’t have any means to have the request originate from the server to the client. The client must always make the request. You can think of this as being a pull-based protocol.
Check out the video below for an example of a demo application that has a scenario where the pull-based nature of HTTP is less than ideal for the end user.
In contrast, moving towards a Push Model allows the server to push data to the client without the client to always make a request (pull) it.
SignalR supports 3 methods for enabling this: WebSockets, Server Sent Events, and Long Polling.
Check out the video below for an overview of all three methods and how they work.
In these videos, I’ve covered what problems SignalR solves and how it solves it using WebSockets, Server-Sent Events or Long Polling. Let’s start digging into setting up SignalR in an ASP.NET Core web application in the next section.
Get The Course!
You’ve got several options:
- Check out my Practical ASP.NET Core SignalR playlist on my CodeOpinion YouTube channel.
- Access the full course now by enrolling for free on Teachable.
- Follow along with the blog post series here on CodeOpinion.com
All of the source code for this blog post and this course is available the Practical.AspNetCore.SignalR repo on GitHub.