Local Interactive mode and RServer

The local option allows you to use static pages, which are Web Pages with no connection to Web Assembly. The local option is a mix of Web Assembly on some pages and static on others.

Blazor servers contain a SignalR service which supports Web Sockets. A Web Socket is a two-way long term, connection between the server and the client. When a Web server receives an HTTP Get request for an interactive page, it sends back a reply and disconnects the HTTP connection. Standard HTTP.

In the reply from Blazor there are links to load java script that causes the client to open an IP port so the server can connect to the client. The server and client then have a two connection that remains open. It is with this connection that the server downloads code and pushes content to the client. The Web Socket is how the client and server communicate in interactive modes. This is why in Interactive modes the HTTP classes have null values.

When prerendering is performed in interactive mode, the prerender is the reply to the HTTP get request. When ready, the Interactive rendering is pushed to the client with the Web Socket.

In Local mode you can have Static pages on the server that are fetched with standard HTTP request and have no Web Assembly. The server simply replies with a rendered web page. Each time you go from an interactive page to a Static page the web socket connection is closed. When you go from a static page back to an active page the Web Socket is re-opened. Any Web Assembly downloaded earlier is still in the client.

The SignalR server allows code in the server to push content to the client. You can use the SignalR server to push your own content to the client.

Interactive Location = Local

Create a new Solution named BlazorWorkbenchL and a project named BlazorWorkbench.WasmL using Web Assembly for interactive mode and Local for interactive location. You will find that only the counter page is in the client project. The home and weather are now in the server project. The Home and Weather pages are static, so they are in the server. They will be fetched with a standard HTTP get request.

When you run the app, the home page appears right away. Since it is static, you do not have to wait for web assemblies to be downloaded. Then navigate to the counter page, you will have to wait a few seconds as the web assemblies are downloaded. Then navigate back to home. The web socket is closed. Navigate back to counter, this time the page appears right away as the web assemblies are already loaded.

The counter page has an extra statement that identifies the render mode for the page. A page without a render mode setting will be served as a static page even though it is in the client. This means you can’t do what we did in the global mode of placing the pages into an RCL and having them work in all of the interactive modes. If you should have a page with render mode set to server or auto in the Web Assembly app, it will throw an Unsupported render mode exception.

You can create a local project for Auto and Server modes. In addition, the WebApp template has an option for interactive mode of None. If you use this option, then the only mode you can use is static. The None option creates a multi-page app with Blazor components. An action such as an OnClick for a counter button would have to point to Java Script. You will see that there is no counter page in the None option.

Web API

The static paths in the server with Local option can be used to create Web APIs with HTTP. This allows you to create an interactive user interface and a Web API in one Blazor App. The interactive app could be used to monitor and manage the Web APIs or it could be a user interface that allows you to enter transactions.

The clients are never given direct access to SQL databases. The server performs all data base access. The data exchange can be through SignalR. But depending upon policy and requirements, you may have to use a Web API.

Enterprise apps often have the same transaction from multiple sources. Every transaction has to be validated and updated according to certain rules. These rules should be coded one time for processing a particular transaction type no matter what the source is. You don’t code an order processing transaction just for a rest Web Interface and again for orders received from a customer with a SOAP API exchange. Having developers create code for updating the same transaction from different sources should never happen. As a result, many web apps just support a user interface that calls HTTP Web APIs on other servers.