Blazor 服务器端与 Blazor WebAssembly 托管
Blazor Server side vs Blazor WebAssembly Hosted
我是 blazor 的新手，正在尝试了解不同托管模型之间的差异。
据我了解，Blazor 服务器端和 Blazor WebAssembly Hosted 都有服务器端代码，两者都使用 Signal R 与客户端通信。
那么它们有什么区别呢？论文的客户端部署到哪里？它们与服务器的连接有什么不同？如果 Web 应用程序反过来调用第 3 方 Web API 调用是如何路由的？
我发现的一个区别是项目结构。 Blazor 服务器端只有一个项目（带有数据文件夹）。 Blazor WebAssembly Hosted 有 3 个项目（.Server、.Client 和 .Shared）。
Blazor Web Assembly 应用程序完全在客户端上运行。没有与服务器的 SignalR 连接：检查服务器 program 文件。服务器只是加载页面和 WASM 代码的托管平台，并提供应用程序使用的任何 API 控制器。这是一个标准的 DotNetCore Web 应用程序。
对第三方的任何 API 调用直接从浏览器 运行 Web Assembly 应用程序到第三方 Urls。
请参阅我为另一个我现在找不到的类似 Stack Overflow 问题写的要点。它描述了 Web Assembly 托管模板中的各个位。 https://gist.github.com/ShaunCurtis/0ed8d257dff4d8497b97c88e5b2b30d0
主要区别在于您的 .NET 代码 运行ning：对于 Blazor Server，它是 100% server-side；对于托管的 Blazor WASM 应用程序，.NET 代码在服务器和客户端上都是 运行ning（尽管服务器也可以 运行 您想要的任何其他语言）。
From what I read I understand Blazor Server side and Blazor WebAssembly Hosted have server side code, ...
没错，但看起来不一样。
- .NET 运行时间是 100% server-side Blazor 服务器应用程序，客户端使用框架 JS 库与服务器通信。归根结底，使用 Blazor Server 您只会得到一个应用程序。
- 使用 Blazor WASM，您的客户端实际上 运行 在您的浏览器中创建一个单独的 .NET 运行 时间。托管模型生成一个单独的 .NET Web API 服务器项目，但您可以使用任何后端来处理您的客户端应用程序（例如 Node.JS 上的 Express），因为您的客户端与技术无关。
... both uses Signal R to communicate with the Client.
不一定。 Blazor Server 需要 Signal R 与客户端持续通信和更新，但 Blazor WASM 更灵活。来自 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.
同样，Blazor WASM 与您的 server-side 无关。托管模型会为您生成 server-side，但从技术上讲，您可以随意使用。
Where is the client side of theses deployed to?
Blazor 服务器不编译 client-side per-say：一旦与应用程序建立连接，它就会利用 Signal R 通过 Web 套接字（或其他方式）不断向客户端推送更新技术不可用时）。
Blazor WASM 是 客户端：当您编译 WASM 项目时，您会得到类似于针对 React 应用程序的 运行ning Webpack 的东西。 Blazor WASM 是一项 front-end 技术，因此它可以作为静态网页的依赖项，或者可以通过 web-api 进行扩充和服务，就像托管模型一样。
What difference is in their connection with Server?
同样，Blazor Server 需要 Signal R，而 Blazor WASM 与技术无关：它可以使用 Signal R，但通常您需要的只是标准 HTTP 协议.
If the Web App inturn calls a 3rd party web API how is the call routed?
这是一个完全不同的问题，但我能看出其中的困惑。您的 WebAPI 是一个完全独立的应用程序；您的 WASM 应用程序 none 如果它发出外部请求则更明智。
文档提供了以下见解（请注意，这并不区分 WASM 的两个模型，但它仍然适用）：
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.
与 Blazor 服务器：
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).
我是 blazor 的新手，正在尝试了解不同托管模型之间的差异。
据我了解，Blazor 服务器端和 Blazor WebAssembly Hosted 都有服务器端代码，两者都使用 Signal R 与客户端通信。
那么它们有什么区别呢？论文的客户端部署到哪里？它们与服务器的连接有什么不同？如果 Web 应用程序反过来调用第 3 方 Web API 调用是如何路由的？
我发现的一个区别是项目结构。 Blazor 服务器端只有一个项目（带有数据文件夹）。 Blazor WebAssembly Hosted 有 3 个项目（.Server、.Client 和 .Shared）。
Blazor Web Assembly 应用程序完全在客户端上运行。没有与服务器的 SignalR 连接：检查服务器 program 文件。服务器只是加载页面和 WASM 代码的托管平台，并提供应用程序使用的任何 API 控制器。这是一个标准的 DotNetCore Web 应用程序。
对第三方的任何 API 调用直接从浏览器 运行 Web Assembly 应用程序到第三方 Urls。
请参阅我为另一个我现在找不到的类似 Stack Overflow 问题写的要点。它描述了 Web Assembly 托管模板中的各个位。 https://gist.github.com/ShaunCurtis/0ed8d257dff4d8497b97c88e5b2b30d0
主要区别在于您的 .NET 代码 运行ning：对于 Blazor Server，它是 100% server-side；对于托管的 Blazor WASM 应用程序，.NET 代码在服务器和客户端上都是 运行ning（尽管服务器也可以 运行 您想要的任何其他语言）。
From what I read I understand Blazor Server side and Blazor WebAssembly Hosted have server side code, ...
没错，但看起来不一样。
- .NET 运行时间是 100% server-side Blazor 服务器应用程序，客户端使用框架 JS 库与服务器通信。归根结底，使用 Blazor Server 您只会得到一个应用程序。
- 使用 Blazor WASM，您的客户端实际上 运行 在您的浏览器中创建一个单独的 .NET 运行 时间。托管模型生成一个单独的 .NET Web API 服务器项目，但您可以使用任何后端来处理您的客户端应用程序（例如 Node.JS 上的 Express），因为您的客户端与技术无关。
... both uses Signal R to communicate with the Client.
不一定。 Blazor Server 需要 Signal R 与客户端持续通信和更新，但 Blazor WASM 更灵活。来自 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.
同样，Blazor WASM 与您的 server-side 无关。托管模型会为您生成 server-side，但从技术上讲，您可以随意使用。
Where is the client side of theses deployed to?
Blazor 服务器不编译 client-side per-say：一旦与应用程序建立连接，它就会利用 Signal R 通过 Web 套接字（或其他方式）不断向客户端推送更新技术不可用时）。
Blazor WASM 是 客户端：当您编译 WASM 项目时，您会得到类似于针对 React 应用程序的 运行ning Webpack 的东西。 Blazor WASM 是一项 front-end 技术，因此它可以作为静态网页的依赖项，或者可以通过 web-api 进行扩充和服务，就像托管模型一样。
What difference is in their connection with Server?
同样，Blazor Server 需要 Signal R，而 Blazor WASM 与技术无关：它可以使用 Signal R，但通常您需要的只是标准 HTTP 协议.
If the Web App inturn calls a 3rd party web API how is the call routed?
这是一个完全不同的问题，但我能看出其中的困惑。您的 WebAPI 是一个完全独立的应用程序；您的 WASM 应用程序 none 如果它发出外部请求则更明智。
文档提供了以下见解（请注意，这并不区分 WASM 的两个模型，但它仍然适用）：
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.
与 Blazor 服务器：
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).