Table of Contents
History on Client-Server Apps
When the original web first came into widespread public use things were reasonably basic. Webpages were effectively specialized documents, like a library. Users clicked on links to articles they found interesting. Somewhere, perhaps on another side of the world, another computer or server was the destination for that click or as we came to call it: the request. The user sends a request and, the server, the far-off computer, gives a response back to the user for every request. That response was typically formatted text, images and later, movies and music. Editing web pages was done mostly using plain text editors rather than more advanced ide software.
After several years and a few iterations, Web 2.0 emerged allowing a more interactive, programmable kind of web page which behaved more like an application. The process was asynchronous and, we were able to execute commands on databases and manipulate the data they contained in that way. Like, create a user, get all users and delete a user.
With the advent of Web 3.0 and beyond, a new concept applied to the systems is a continuous connection between a client and a server. Web applications could now carry out significantly complex tasks, interact with specialized hardware like GPS sensors and other activities rivaling traditional desktop application capabilities. Along with this rose the need to implement real-time connections which transmitted data between the web browser and servers in an optimized and highly efficient way. The connection between the server and client can be used on either side to update and set the state and react accordingly. We refer to that highly interactive nature as “real-time web applications”. They’re a long way from those original electronic reference type documents of the original web.
What methods are there for implementing real-time web applications?
Interval polling
This method is very straightforward. We go to the server and see if we have anything we need to do in the interval. And there are 3 cases:
- Nothing will be returned
- The server has data that return to us
- Some sort of internal server error
But no matter what, we go to the server to see if we can do anything.
Problems of interval polling
- More connections, more overhead
- Mode bandwidth
- The server can’t keep up with the request
Long polling
As you can see, we were making requests every 10 seconds no matter what. Long polling is a call that we open up and remains open until the server has something for us (depending on browser timeouts). And after a timeout, we open up our request all over again.
Benefits of this method:
- Less server overhead and resource consumption
The downside is we still make and open connections regularly.
Server-Sent Events
In this method, we open a connection to the server and, that server can remain open indefinitely. And server makes use of this connection or pipe to send us messages.
The best thing about this is the server can push data to the browser without requiring multiple connections. But this is one way in which the client cannot send messages to the server.
Web Sockets
Web sockets are the ability of the client in the server to open a one-on-one connection, which they both can send data over.
What are the benefits of Web Sockets?
- Bi-directional communication between the server and the client
- Gives a perfect solution
Note that websockets have problems with older browsers.
What is SignalR?
How does the SignalR compare with these other options? Imagine that you have several connected clients out there. They have come to your web server and downloaded all the assets, now they are ready to communicate with the server back and forth.
So, the SignalR exposes what is called a hub (server) – a central connection point for all incoming connections. The way of clients talk to our server is dependent on the client infrastructure and server infrastructure. This is known as a transport layer for SignalR. This transport can be one of the methods that we have discussed.
Depending on the infrastructure you have the transport layer gives different connection types and makes the connection resilient.
In this guide, you will learn how we use Telegram messenger is in sending you a user identifier so you can use your Delphi Windows and Mobile apps seamlessly.
How do I create Delphi programs which use SignalR?
There are several libraries and components available for Delphi which provides an easy implementation of SignalR applications. One of them is the SignalR API client by eSeGeCe.
What are the features of the eSeGeCe Delphi client?
- Protocol Versions 1.2 – 1.5
- Hubs messages
- RPC
- Error handling
- and more
One word of caution, the client uses WebSocket as a transport to connect to a SignalR server, if there is no support for that, an error will be raised.
When should I use SignalR in my app?
- Apps that require high-frequency updates from the server e.g: social networks, gaming, voting, auction, maps, and GPS apps.
- Monitoring apps
- Collaborative apps
- Chats and other apps that use notifications
The hubs are simple abstractions SignalR uses to communicate between clients and the server. As you can see, there are several ways to control messaging between clients and the server. The SignalR gives us the tools we need to control experiences via the connection timeline.
How to scale SignalR projects?
You don’t have a performance problem until you have a performance problem. To determine problems, you need numbers or just metrics.
SignalR is not able to natively work in a multi-server environment since it doesn’t know how to communicate between server instances. The Backplane is a mechanism that allows SignaR instances to communicate with each other.
Moreover, you can use external services to scale. For instance:
- Azure Service Bus
- This is a fully managed message broker with message queues and publish-subscribe topics. It safely coordinates transactional work that requires a high degree of reliability.
- Redis
- SQL Server
So, there is a wide range of methods to scale up your system if you need.
How to improve the performance of SignalR powered systems?
You can follow these tips to achieve high performance:
- Control how often messages are sent – Stay in control of when you send messages to the server or clients.
- Be on the lookout for accidental message loops.
- Map property names to smaller identifiers that are easier transmit
- Decrease the default message buffer size since it is 1000 messages per hub per connection