我应该使用Blazor WASM而不是Blazor Server吗？

Question

我是Blazor的新手。文章建议Blazor WASM应该比Blazor Server更受欢迎。

我正在构建一个小型Blazor服务器应用程序，需要操作存储在不同Azure表存储帐户中的数据。目前，这些存储的连接字符串保存在一个静态列表中。

如果我理解正确的话，Blazor server将运行在带有SignalR的Asp.Net核心上，向客户端发送二进制消息以进行DOM操作，而Blazor WASM将在客户端浏览器中运行，因此可以托管在一个非常简单和便宜的静态web服务器上。然而，WASM不能保密(比如连接字符串)。

如果我使用WASM而不是Server，难道我不需要一个带有API的单独服务器来为我的WASM客户端连接字符串等提供服务吗？或者我应该将连接字符串放在表存储中，并以某种方式公开声明(?)用于存储到Azure集成平台中的应用程序？

对此有什么想法吗？

Answer 1

因此，有两种方式来看待这一点。

一方面，您可以将server与wasm视为可互换的。根据微软的说法，这是“正确的”方式。如果您仔细地设计它，您将能够仅仅翻转两个开关来在两个模型之间切换。在这种情况下，差异相对较少，但它们很重要：

• 服务器会有可伸缩性方面的问题。你会有成千上万的同时活跃的用户吗？您将需要进行模拟负载测试以确保性能，如果没有正确完成，acceptable.
• Server会引发安全问题。您需要确保不存在不同用户会话的可能性，如果不在基础架构中解决，interacting.
• server会出现负载均衡器问题，level
• Client/wasm会出现严重的性能问题。
• Client在穿越企业防火墙时遇到了问题。。NET 6对此有缓解措施，但它们的有效性尚不清楚。

然而，在这两种情况下，任何后端/数据库等都将位于通过REST访问的单独服务器进程中。也就是说，如果你想保持事物的可互换性。所有数据库访问都必须由这台单独的服务器进行中介。像连接字符串这样的东西总是需要存在于那里，在他们的Blazor模型中。

现在，从另一方面来说，如果你不能互换地对待它们呢？在我看来，这为Server打开了一些有趣的可能性。例如，您可以抛弃所有API，直接访问Blazor应用程序中的数据库和其他后端资源。这基本上是一种Webforms风格的应用程序，除非没有post backs。如果处理得当，这将更加安全；由于没有可公开访问的API，唯一的公共端点发送和接收UI数据，从而使受攻击面变得小得多。不再需要无状态也有性能上的优势。例如，您可以查询一个数据库，并在查询结果传入时开始将其推送到UI，而不必等待加载所有结果，然后将结果放在响应中，就像使用API一样。

当然，缺点是您将提交到Server，并且不能轻松地更改为client/wasm。