如何为现有ASP.NET Core Web API添加多个Blazor Web应用

嘿，刚接触Blazor的话，这个问题确实很常见——尤其是在已有Clean架构的API基础上扩展多个前端的场景。下面给你几个最实用的方案，你可以根据团队的部署习惯、应用规模来选：

方案1：独立部署Blazor应用，通过反向代理统一路由 #

这是最灵活、最常用的方案，不管你用Blazor WebAssembly（WASM）还是Blazor Server都适用。

• 步骤拆解：
  • 给每个Blazor应用单独创建项目：比如选Blazor WASM的“独立”模式（不需要内嵌API），或者直接创建Blazor Server项目。
  • 配置现有API的跨域（CORS）：如果是Blazor WASM，因为它在浏览器端运行，必须允许来自Blazor应用域名的请求。在API的Program.cs里添加：

    builder.Services.AddCors(options =>
    {
        options.AddPolicy("BlazorCorsPolicy", policy =>
        {
            policy.WithOrigins("https://app1.yourdomain.com", "https://app2.yourdomain.com")
                  .AllowAnyHeader()
                  .AllowAnyMethod();
        });
    });
    
    // 注意要放在app.UseRouting()之后，app.UseAuthorization()之前
    app.UseCors("BlazorCorsPolicy");
    

  • 用反向代理统一路由：可以用Nginx、IIS应用请求路由（ARR），或者ASP.NET Core自带的YARP。比如配置路由规则：
    • https://yourdomain.com/api/* → 转发到现有Web API
    • https://yourdomain.com/app1/* → 转发到第一个Blazor应用
    • https://yourdomain.com/app2/* → 转发到第二个Blazor应用
• 优缺点：
  • ✅ 每个Blazor应用独立开发、部署，互不影响；API和前端完全解耦，符合微前端思路；甚至可以混合使用Blazor Server和WASM。
  • ❌ 需要额外配置反向代理；Blazor Server每个应用会占用独立的服务器资源。

方案2：将Blazor应用嵌入API项目（Razor类库方式） #

如果不想单独部署多个服务，想把所有应用打包成一个部署单元，这个方案很合适，适合小型应用场景。

• 步骤拆解：
  • 把每个Blazor应用的页面、组件封装成Razor类库（RCL）：创建RCL项目时，勾选“支持页面和视图”，这样可以包含路由逻辑。
  • 在现有API项目中添加对这些RCL的引用。
  • 配置API的Program.cs启用Blazor服务：

    // 注册Blazor相关服务（以Blazor Server为例）
    builder.Services.AddRazorPages();
    builder.Services.AddServerSideBlazor();
    
    // 配置端点
    app.MapBlazorHub();
    // 为每个Blazor应用映射不同的路由前缀
    app.MapFallbackToPage("/App1/{*path:nonfile}", "/App1/_Host");
    app.MapFallbackToPage("/App2/{*path:nonfile}", "/App2/_Host");
    

  • 在API项目中创建每个应用的_Host.cshtml页面：比如Pages/App1/_Host.cshtml，指定该应用的根组件和路由基础路径：

    @page "/App1"
    @addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers
    <!DOCTYPE html>
    <html lang="en">
    <head>
        <meta charset="utf-8" />
        <base href="/App1/" />
        <title>App1</title>
        <link rel="stylesheet" href="css/bootstrap.min.css" />
        <link rel="stylesheet" href="css/site.css" />
    </head>
    <body>
        <component type="typeof(App1RootComponent)" render-mode="ServerPrerendered" />
        <script src="_framework/blazor.server.js"></script>
    </body>
    </html>
    

• 优缺点：
  • ✅ 所有应用和API打包在一起，部署简单；共享API的配置和依赖。
  • ❌ 应用之间耦合度高，一个应用的改动可能影响整个部署单元；Blazor Server的话，所有应用共享服务器资源，高并发下可能有性能瓶颈；WASM不太适合这种方式，静态文件单独部署更高效。

方案3：基于Module Federation的微前端架构 #

如果你的团队追求现代微前端架构，想让多个Blazor WASM应用动态加载、共享资源，这个方案是未来方向。

• 步骤拆解：
  • 每个Blazor WASM应用作为独立模块开发：使用ASP.NET Core提供的Module Federation模板（或者手动配置webpack），把每个应用打包成可动态加载的模块。
  • 配置现有API允许跨域，让每个Blazor模块都能调用API接口。
  • 创建一个“壳（Shell）”应用：可以是简单的Blazor WASM应用，负责导航和动态加载各个子模块；也可以用反向代理直接路由到不同模块。
• 优缺点：
  • ✅ 真正的微前端，每个应用独立开发、部署，运行时动态加载；可以共享组件、依赖，减少重复代码。
  • ❌ 配置相对复杂，需要了解Module Federation的概念；目前Blazor对它的支持还在迭代中，可能会遇到一些小坑。

额外注意事项 #

• 身份验证适配：如果API已经用了JWT或Cookie认证，Blazor Server可以直接共享API的Cookie；Blazor WASM需要在客户端存储JWT，请求API时通过Authorization头带上。
• 共享组件复用：把通用的导航、布局、UI组件封装成RCL，让所有Blazor应用引用，减少重复开发。
• 遵循Clean架构：Blazor作为UI层，只负责展示和用户交互，业务逻辑尽量通过调用现有API实现，不要在Blazor里写核心业务代码。

备注：内容来源于stack exchange，提问作者user3552264