CODEWITHSUNDEEP
c#asp.netsignalrblazor
user13028433
user13028433

Reputation:

How does Blazor server work in the back end?

Imagine this code:

@page "/"

@code{
    string name;
    string greet;
}
@{
    void sayhello()
    {
        greet = $"Hello, {name}";
    } 
}
<span>Type your name : </span>
<input Type="Text" @bind="name" />
<br/>
<button @onclick="sayhello">Say hello!</button>
<hr/>
<h1>@greet</h1>

This code will get the user's name and say hello to the user. But how does it work? Is this true?

In Blazor WebAssembly, it runs like a c# standalone program in the client machine. But in BlazorServer, it does the same but in the server not in the client machine and it sends the updated UI to the client using SignalR.

Upvotes: 1

Views: 3520

Answers (1)

Lachlan Gordon
Lachlan Gordon

Reputation: 86

As you say, Blazor can run in two ways, Server side or client side.

When it's client side think of it just like JavaScript in the browser. When the page loads the code is downloaded onto the client computer. It the runs inside the browser without any need to contact the server when you click the button.

When running server side Blazor, anything that happens client side is sent from the browser to the server to be processed and then is sent back to be displayed.

The level where this server/client transaction happens is a bit different to most web frameworks.

If we look at three different levels or server rendering:

  1. Form Submission with HTML response. When the client submits a request, the server returns HTML for the browser to render, with all data already inline in the HTML. This is how ASP.Net MVC, PHP and various other server side technologies traditionally worked. This method typically transfers a complete page over HTTP for every click on the page.

  2. AJAX/XHR request to API. The page starts by loading HTML and JavaScript. When you click a button on a page it sends a request to the server, the server responds with just the data needed, then displays the Data. This method typically transfers a lot of markup at load time and then data only when necessary. This is the model used in Blazor WASM/Client and in Single-Page-Application Frameworks(SPAs).

  3. In Blazor server there is a (near) continuous connection back and forth between the client and server, every click the user makes is transferred back and forth from client and server, but instead sending the full HTML page or the data each time, just the minimal changes to update the page are made. This happens over SignalR, but it could happen over Http or another protocol, SignalR is just chosen as an efficient protocol for real time data transfer.

As mentioned by @Crowcoder and @Adyson SignalR is an abstraction, which mainly uses websockets, and sometimes HTTP or other technologies. The abstraction is provided by Microsoft largely because WebSockets are fast and efficient, but unpleasant to code for and unstable. Rather than everyone having to write the necessary code to safely use WebSockets, SignalR wraps it up in an easy to consume API. The Blazor link between client and server is built using that abstraction.

These three scenarios are not hard an fast divisions. The three layers are often mixed together and there are lots of ifs and buts and scenarios that sit somewhere on the border. They are however, common scenarios that help to understand where the two types of Blazor sit in the web framework landscape.

Upvotes: 7

Related Questions