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).
