Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

I am new to Blazor and am trying to understand the differences between different hosting models.

From what I read I understand Blazor Server side and Blazor WebAssembly Hosted have server side code, both use Signal R to communicate with the Client.

So what is the difference between them? Where is the client side of these deployed to? What difference is in their connection with Server? If the Web App in turn calls a 3rd party web API how is the call routed?

One difference I found was in the project structure. Blazor Server side has only one project (with a Data Folder). Blazor WebAssembly Hosted has 3 projects (.Server, .Client and .Shared).

Does this answer your question? How can I tell if code will run on the client or server with Blazor? – Quango Feb 25, 2022 at 15:34 The link shows the difference between wasm(standalone) and server side. But I am looking for WASM (hosted) and server side. – Newbie Feb 25, 2022 at 15:52 WASM means the code runs on the client. Server means the code runs on an ASP.NET Server. A WASM client can be placed on a static file server, there's no requirement to use ASP.NET. ASP.NET Hosted WASM uses ASP.NET as the host. It serves up the WASM client as files that then run on the client. But it also can host other stuff like Web API etc. – Quango Feb 25, 2022 at 16:02 So does that mean, the ASP.NET host deploys the client code to the device on initial load? If the client code gets data from a third party API, does the call go through the server? Or does the call directly go from the client(device) to 3rd party API(as in the case of WASN standalone)? – Newbie Feb 25, 2022 at 16:24

The primary difference is where your .NET code is running: with Blazor Server, it's 100% server-side; with a hosted Blazor WASM application, .NET code is running on both the server and the client (though the server can run any other language or framework you want too).

From what I read I understand Blazor Server side and Blazor WebAssembly Hosted have server side code, ...

True, but it looks different.

The .NET runtime is 100% server-side with Blazor Server application. A framework JS library is used by the client to communicate with the server, but at the end of the day, you are getting one .NET application.

With Blazor WASM, your client is running a separate .NET runtime in your browser. In addition to the client WASM app, the hosted model generates a .NET Web API Server project; however you could use any backend technology to serve and enhance your client application (e.g. Express on Node.JS) because your client is server technology agnostic.

... both use Signal R to communicate with the Client.

Not necessarily. Blazor Server needs Signal R to continuously communicate and update the client, but Blazor WASM is more flexible. From the docs :

A hosted client app can interact with its backend server app over the network using a variety of messaging frameworks and protocols, such as web API , gRPC-web , and SignalR .

Again, Blazor WASM is agnostic towards your server-side. The hosted model generates a server-side for you, but you could technically use whatever you want.

Where is the client side of these deployed to?

Blazor Server doesn't compile a client-side per-say: once a connection is made to the application, it leverages Signal R to continuously push updates to the client over a web socket (or other technology when that is not available).

Blazor WASM is the client side: when you compile a WASM project, you are getting something similar to running Webpack against a React application. Blazor WASM is a front-end technology, so it can be served as a dependency of a static web page, or it can be augmented and served by a web-api, like with the hosted model.

What difference is in their connection with Server?

Again, Blazor Server requires Signal R, whereas Blazor WASM is technology agnostic: it can be made to use Signal R, but often all you will need is the standard HTTP protocol.

If the Web App in turn calls a 3rd party web API how is the call routed?

This is an entirely different question, but I can see the confusion. Your WebAPI is a totally separate application; your WASM application is none the wiser if it makes external requests.

The docs offer the following insights (note this does not distinguish the two models for WASM, but it still applies):

When the Blazor WebAssembly app is created for deployment without a backend ASP.NET Core app to serve its files, the app is called a standalone Blazor WebAssembly app. When the app is created for deployment with a backend app to serve its files, the app is called a hosted Blazor WebAssembly app.

The Blazor WebAssembly (WASM) hosting model offers several benefits:

There's no .NET server-side dependency after the app is downloaded from the server, so the app remains functional if the server goes offline.

Client resources and capabilities are fully leveraged.

Work is offloaded from the server to the client.

An ASP.NET Core web server isn't required to host the app. > - Serverless deployment scenarios are possible, such as serving the app from a Content Delivery Network (CDN).

The Blazor WebAssembly hosting model has the following limitations:

The app is restricted to the capabilities of the browser.

Capable client hardware and software (for example, WebAssembly support) is required.

Download size is larger, and apps take longer to load.

Versus Blazor Server:

The Blazor Server hosting model offers several benefits:

Download size is significantly smaller than a Blazor WebAssembly app, and the app loads much faster. -The app takes full advantage of server capabilities, including the use of .NET Core APIs.

.NET Core on the server is used to run the app, so existing .NET tooling, such as debugging, works as expected.

Thin clients are supported. For example, Blazor Server apps work with browsers that don't support WebAssembly and on resource-constrained devices.

The app's .NET/C# code base, including the app's component code, isn't served to clients.

The Blazor Server hosting model has the following limitations:

Higher latency usually exists. Every user interaction involves a network hop.

There's no offline support. If the client connection fails, the app stops working.

Scaling apps with many users requires server resources to handle multiple client connections and client state.

An ASP.NET Core server is required to serve the app. Serverless deployment scenarios aren't possible, such as serving the app from a Content Delivery Network (CDN).

From what I can tell, the best use cases for each model are as follows: Blazor Server - Embedded applications, Internal business apps with local network; Blazor WASM - High performance, client-side-only apps (think Photoshop); Blazor Hybrid - Native apps for desktop and mobile – OzzyTheGiant Aug 5, 2022 at 18:57 ".NET Core on the server is used to run the app, so existing .NET tooling, such as debugging, works as expected." - from trying them both briefly (Blazor WASM and Blazor Server), this is one of the bigger differences. Being able to debug things and get the full details when something goes wrong is pretty much invaluable. With Blazor WASM, it was very hard to do this for certain types of exceptions in my use case. – Per Lundberg Oct 1, 2022 at 9:37

A Blazor Web Assembly application runs wholly on the Client. There is no SignalR connection to the server: check the server program file. The server is simply the hosting platform for the loading page and WASM code, and provides any API controllers that the application uses. It's a standard DotNetCore web application.

Any API calls to third parties go directly from the browser running the Web Assembly application to the third party Urls.

See this gist I wrote for another similar Stack Overflow question that I now can't find. It describes what the various bits are in the Web Assembly hosted template. https://gist.github.com/ShaunCurtis/0ed8d257dff4d8497b97c88e5b2b30d0

Thanks for contributing an answer to Stack Overflow!

• Please be sure to answer the question . Provide details and share your research!

But avoid …

• Asking for help, clarification, or responding to other answers.
• Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers .