As Web applications have now become increasingly common, Web applications are now expected to not only offer functionality but also need to offer a great user experience. The most important aspect of a good user experience is speed. The web applications need to be fast for which it needs to deliver information in real-time, without the need to refresh the browser. All prominent programming platforms offer frameworks for building real-time applications. Socket.IO offered by Node.js is quite a good example of a real-time framework. Similarly, ASP.NET Core also offers a popular real-time framework called ASP.NET Core SignalR.
In this article, we will discuss the origins and features of SignalR and how it has been redesigned to work with ASP.NET Core to fulfil all the requirements of recent real-time applications.
SignalR was an open-source library that simplifies adding real-time functionalities to web applications. It was created in 2011. Later, it was brought into the ASP.NET project and was released as part of ASP.NET in 2013, Introduced as ASP.NET Core SignalR.
Before SignalR, developers used relatively inefficient techniques for real-time features such as AJAX polling or long-polling. SignalR was introduced to solve this problem by providing easy support for real-time capabilities on the ASP.NET stack. It was done by creating a server and client-side libraries that allows the server-side code to push the content to clients instantly without refreshing the browser.
SignalR supports the following list of techniques for providing real-time communication:
- Long Polling
- Server-Sent Events
It allows us to automatically choose the best transport method possible that is within the capabilities of the client and the server.
SignalR uses hubs to establish communication between clients and servers. A hub is a high-level pipeline that allows a client and a server to call methods on each other. It handles the dispatching across machine boundaries automatically, allowing the clients to call methods on the server and vice versa. It allows passing strongly typed parameters into methods, which also enables model binding.
SignalR provides two built-in hub protocols:
- a text protocol based on JSON
- a binary protocol based on MessagePack.
Working on the hub
- The client-side code is called by sending messages that contain the name and parameters of the client-side method.
- Objects sent as method parameters are then deserialized using the selected protocol.
- The client then tries to match the name to a method in the client-side code. When a match is found, it calls the method and the deserialized parameter data is finally passed to it.
Introducing ASP.NET Core SignalR
Despite being a useful tool at the time, various features in SignalR that were intended to make it easier to use ended up adding complexity and inefficiencies to the framework. To solve that, SignalR was rewritten from scratch when ASP.NET was redesigned from the ground up to create a faster, cross-platform ASP.NET Core.
Introduced as ASP.NET Core SignalR, they aimed to make it extensible enough to be future-proof against new protocols and transport technologies. Overall, ASP.NET Core SignalR contained the same core concepts and capabilities as SignalR. Hubs were still the main connection point between the server and its clients. Clients were able to invoke methods on the hub, and the hub also can invoke methods on the clients. The hub has control over the connections on which to invoke a certain method.
Some common use cases for ASP.NET Core SignalR include:
- Applications that require a high-frequency real-time update from the server side. It includes games, social networks, voting applications, auction applications, maps and GPS apps as well.
- Dashboards and monitoring applications such as company dashboards, instant sales updates, stock exchange updates or forex exchange updates etc.
- Collaborative and conferencing applications like Whiteboard apps and team meeting software.
- Web applications that require real-time notifications such as social networks, email, chat, games, travel alerts, and many other similar apps.
Features of ASP.NET Core SignalR
Following are some noteworthy upgraded features of ASP.NET Core SignalR:
See Also: 10 Indispensable Software Development KPIs That Every Project Leader Should Use
Built-in and Custom Protocols
ASP.NET Core SignalR ships with a new JSON message protocol that is now incompatible with earlier versions of SignalR. Along with that, it has a second built-in protocol based on MessagePack, a binary protocol that has smaller payloads than the text-based JSON.
ASP.NET did not have dependency injection built in, so earlier SignalR provided a GlobalHost class that included its own dependency resolver. Now, .NET Core SignalR simply leverages the built-in framework for the dependency injection.
Hubs in.NET Core SignalR now also support constructor dependency injection. It also does not require any extra configuration, similar to ASP.NET Core controllers or razor pages.
SignalR initially offered built-in support for scale-out using Redis, Service Bus, or SQL Server as a backplane. A backplane allows the creation of different instances of the same ASP.NET SignalR application to broadcast messages to the correct clients, regardless of whether the client is connected to the same instance or not. Apparently, this has proved to be a bit difficult to implement correctly and has added a lot of overhead and it did not work well for many scenarios.
ASP.NET Core SignalR was redesigned with a relatively simpler and more extensible scale-out model. It now does not allow a single client to connect to different server-side instances. It resulted in requiring sticky sessions to ensure server affinity for clients using protocols other than Websockets.
Earlier, SignalR included reconnection logic on both the clients and the server. Clients could attempt to reconnect if a connection was lost, and the server buffered unsent messages and replayed them when a client reconnected. This proved to be a very buggy and inefficient process, and the implementation also did not make much sense for every type of application.
ASP.NET Core SignalR now does not support automatic reconnection or automatic buffering of messages. Instead, it allows the client application to decide when it needs to reconnect to the server and it is up to the server to implement message buffering if required.
Wrapping it up
In this article, we covered a basic overview of ASP.NET Core SignalR. It was discussed how adding real-time Web functionalities to your cross-platform Web applications has become so easy using ASP.NET Core SignalR. We have just scratched the surface but you can explore further features and work of ASP.NET Core SignalR for creating highly scalable web applications.
Also Read: Guide On How Xperti Assists You In Finding .NET Jobs In The USA