Is consuming your own API necessary in this case?

Question

I have a solution with:

• ASP.NET Core WebAPI project
• Blazor Server project (web)

I also have 2 Class Libraries

• Core (domain models and interfaces here)
• Infrastructure (implementation of interfaces here)

Is it worth it for my Blazor Server to consume my own WebAPI via HttpClient? Or let my Blazor Server have a DbContext in program.cs too and access the database directly?

Because calling the WebAPI with HttpClient might be slower. And if I choose to call the database directly with Blazor, then I have a lot of copy paste (DbContext, inject services, etc in Program.cs), AKA copying the whole CompositionRoot.

What's your opinion to what I should be doing as for the right approach?

Answer 1

When you want to be sure to have total separation (for future microservices archtitecture) then yes, call the API with HttpClient. But that does reduce your performance, and it's a drag.

As an alternative you can add a separate MyService.Contracts project for each MyService. That project should contain the interfaces and also the DTOs you use for your API.

The other services should only take a dependency on each others .Contracts projects. That prevents directly calling other services.

And then each MyService project should expose a helper method to register all its services with the DI. In Program.cs you can then set everything up. Note that the actual Service classes can now be internal .

In the Onion Architecture view: the contracts are in an inner ring, their implementations go on the outside.