How to configure dotnet-webapi-boilerplate to use with a Blazor client

[MarcoGaribaldi]

Hello,

I am trying to use dotnet-webapi-boilerplate with a Blazor WASM front-end. I am new to Blazor so I need some help in configuring the webapi Program.cs so that it works together with Blazor. According to docs I read and confronting how BlazorHero's Program.cs is, my understanding is that I need to add some configuration lines, as marked in the following code. Can anyone please check this out and let me know if this is correct? Thanks in advance for any suggestions you can share.

`
using System;
using FluentValidation.AspNetCore;
using FSH.WebApi.Application;
using FSH.WebApi.Host.Configurations;
using FSH.WebApi.Host.Controllers;
using FSH.WebApi.Infrastructure;
using FSH.WebApi.Infrastructure.Common;
using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Serilog;

[assembly: ApiConventionType(typeof(AppApiConventions))]

StaticLogger.EnsureInitialized();
Log.Information("Server Booting Up...");
try
{
var builder = WebApplication.CreateBuilder(args);

builder.Host.AddConfigurations();
builder.Host.UseSerilog((_, config) =>
{
    config.WriteTo.Console().ReadFrom.Configuration(builder.Configuration);
});

builder.Services.AddControllers().AddFluentValidation();
builder.Services.AddInfrastructure(builder.Configuration);
builder.Services.AddApplication();

var app = builder.Build();

// Start Added Lines =====================================
// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseWebAssemblyDebugging();
}

app.UseHttpsRedirection();
app.UseBlazorFrameworkFiles();
app.UseStaticFiles();
app.UseRouting();
app.MapControllers();
app.MapFallbackToFile("index.html");
// End Added Lines =====================================

await app.Services.InitializeDatabasesAsync().ConfigureAwait(false);

app.UseInfrastructure(builder.Configuration);
app.MapEndpoints();
app.Run();

}
catch (Exception ex) when (!ex.GetType().Name.Equals("StopTheHostException", StringComparison.Ordinal))
{
StaticLogger.EnsureInitialized();
Log.Fatal(ex, "Unhandled exception");
}
finally
{
StaticLogger.EnsureInitialized();
Log.Information("Server Shutting down...");
Log.CloseAndFlush();
}
`

[chrislangston]

Hi @MarcoGaribaldi , did you take a peek at the docs for standing up the Blazor Boilerplate sample app? That documentation can be found here: https://fullstackhero.net/blazor-webassembly-boilerplate/general/getting-started/

[chrislangston]

@MarcoGaribaldi I think I understand what you're asking now. Are you wanting to be able to host the backend API and the front-end Blazor SPA together and have it served up by the backend API project?

An out of the box asp.net Blazor WebAssembly that is dotnet Core hosted all runs together. However, I believe the approach the fullstackhero templates are taking is to host them separately.

[MarcoGaribaldi]

I think I understand what you're asking now ...

Yes, correct.

An out of the box asp.net Blazor WebAssembly that is dotnet Core hosted all runs together. However, I believe the approach the fullstackhero templates are taking is to host them separately.

I am not sure to understand what you mean. I am moving my first steps with Blazor, so I may be using the wrong approach. Let me better explain what I am doing: I have added the Client project of the Blazor boilerplate to the WebAPI boilerplate solution. I am using BlazorHero's setup as a reference. In my solution, Client and Host are two separate projects, I haven't merged them together. The reason I am doing all this is multi-tenancy, as BlazorHero does not support it. Both Blazor and multi-tenancy are new concepts to me, so this approach is a good exercise for me to learn and study the code. Based on the info I have, Program.cs in the Host project of the WebAPI boilerplate requires those extra lines of configuration to launch and work together with Blazor client project. Are you suggesting that what I am doing is wrong?

[fretje]

It is definitely possible to do it that way, but as you have experienced hands-on, it makes things more complicated. ;-)

It's easier to keep both the apps as separate server instances. That's why the api is hosted on localhost:5002 and the blazor client on localhost:5001 by default, and the blazor client has a configuration value in wwwroot/appsettings.json - ApiBaseUrl - which points to localhost:5002. There's also a configuration value on the api side in configurations/cors.json - CorsSettings > Blazor - which points to localhost:5001 (to enable cors).

It's still possible to host both apps behind the same url, if you put a reverse proxy in front of them (which is probably what you want to do in production anyway).

This way it's also possible to scale both apps in a different way. Or - if you split up the api in different services each hosted in their own server instance - to scaled those in a different way (micro-services architecture).

[MarcoGaribaldi]

It's easier to keep both the apps as separate server instances. That's why the api is hosted on localhost:5002 and the blazor client on localhost:5001 by default, and the blazor client has a configuration value in wwwroot/appsettings.json - ApiBaseUrl - which points to localhost:5002. There's also a configuration value on the api side in configurations/cors.json - CorsSettings Blazor - which points to localhost:5001 (to enable cors). <

Ok, this is helpful. Thank you. I believe that how the API and the Blazor client are hosted is what BlazorHero also does, right? I have the same set up, but need to check the cors settings.

So, in order to launch the client for debugging or to check how the interface is coming, do you suggest to use the approach I am using with the additional configuration lines in Program.cs of the API, or is it better to configure the solution with multiple startup projects, so to launch both projects together?

[kirkey]

I am also facing the same issue right now. I have built a set of CRUD and then tried to deploy it on IIS which has given me a lot of problems with port configurations. On development was ok but on IIS, they're gone crazy.