FastEndpoints 实现 Blazor WebAssembly 的 GRPC 支持深度解析

背景与挑战

FastEndpoints 作为一个高效的 .NET API 框架，其远程消息功能(Fastendpoints.Messaging.Remote)原本主要面向服务器间通信场景。随着 Blazor WebAssembly 的普及，开发者希望能在浏览器环境中也能利用这一强大的命令-响应机制。

传统 GRPC 在浏览器环境面临核心限制：浏览器运行时无法直接使用 SocketsHttpHandler，而必须依赖 HttpClientHandler 和 Grpc.Net.Client.Web 包提供的 Web 传输层。这导致了原始 FastEndpoints 远程消息模块无法直接在 WASM 环境中运行。

技术实现方案

架构重组

解决方案的核心是对原有消息模块进行合理拆分：

1. FastEndpoints.Messaging.Remote.Core
   基础通信层，包含客户端核心功能，专为浏览器环境设计：

   • 移除了 SocketsHttpHandler 依赖
   • 集成 Grpc.Net.Client.Web 支持
   • 精简了仅保留必要的命令执行功能

2. FastEndpoints.Messaging.Remote
   完整功能包，包含服务端和高级特性：

   • 保持原有服务器实现
   • 依赖 Core 包提供基础能力
   • 添加事件发布/订阅等高级功能

关键实现细节

浏览器端配置需要特殊处理：

// WASM 项目启动配置
builder.Services.MapRemoteCore("https://api.example.com", c => 
{
    c.Register<CreateOrderCommand, CreateOrderResult>();
});

服务端 GRPC Web 支持需要显式启用：

// 服务端 Program.cs
app.UseGrpcWeb(new GrpcWebOptions { DefaultEnabled = true });

事件订阅机制经过优化后支持多客户端：

// 事件中心注册时指定广播模式
h.RegisterEventHub<OrderEvent>(HubMode.EventBroker);

性能优化与调试

实践中发现几个关键性能要点：

1. HTTP/2 协议配置
   Kestrel 必须明确配置 Http2 协议支持，否则会导致连接异常：

   "Kestrel": {
       "Endpoints": {
           "grpc": {
               "Url": "http://*:5000",
               "Protocols": "Http2"
           }
       }
   }
   

2. 事件实时性优化
   原始实现中的 60 秒等待超时会影响事件实时性，优化后改为：

   await subscriber.Sem.WaitAsync(cts.Token);
   

3. 客户端标识
   多客户端场景需要唯一标识来区分订阅者，避免消息被单客户端独占。

最佳实践建议

1. 混合应用架构

   • 浏览器端：使用 Core 包处理基础命令
   • 服务器间：使用完整包实现高级消息模式

2. 异常处理
   浏览器环境需特别注意 GRPC 状态码处理：

   try {
       await command.RemoteExecuteAsync();
   } catch (RpcException ex) {
       // 处理特定状态码
   }
   

3. 性能监控
   建议在生产环境监控：

   • GRPC 调用延迟
   • 消息吞吐量
   • 浏览器内存使用情况

未来展望

随着 Blazor WASM 的持续演进，FastEndpoints 的远程消息功能有望进一步优化：

1. 更智能的传输层自动选择
2. 针对浏览器环境的轻量级序列化
3. 与 SignalR 的深度集成方案
4. 客户端资源消耗的精细控制

这套方案不仅解决了浏览器环境的技术限制，更为分布式应用提供了统一的编程模型，体现了 FastEndpoints 框架强大的扩展性和适应性。