Search code examples
architecturemicroservicesblazor

Blazor WebAssembly (Hosted) MicroService Strategy

The guts of my application is made up of a suite of microservices, with each mostly using DDD Architecture.

In a standard MVC solution, the client would access my controllers and the controllers would interact with my microservices.

In a Blazor Server setup, the approach would be similar.

However, with a Blazor WebAssembly (Hosted) setup I have the opportunity to reference my microservices directly from the Blazor WebAssembly Client.

Is this wise?

Or would I be better off creating a facade on the Blazor server (which in turn accesses the microservices) and only communicate with that facade from the Blazor WebAssembly client?

My Blazor Server has its own needs to reference the microservices and I was just about to register the microservices on the client as well before wondering if this was sensible.

Solution

  • It highly depends on your architecture and its constraint, and a proper answer is thought.

    BFF

    You could use the BFF (Backend for Frontend) pattern, your facede. In this case, another microservice will act as a gateway between your Blazor application and your microservice landscape.

    So, the frontend doesn't need to know what information is in what service to find. Usually, this simplifies the development of the frontend. Besides, the BFF could handle cross-cutting concerns like authentication.

    However, you introduce a new microservice that doesn't help to solve your business problem. You are adding another layer of accidental complexity.

    Besides, with BFF, you kind of create a kind dependency between your services. If you change or add a capability of your microservice, you need to update the BFF as well.

    Calling them directly

    If your microservices have a kind of HTTP (REST) API (not every microservice needs that btw) that could be exposed to the public (your Blazor client), calling them directly from the client is an option.

    Each service needs to handle cross-cutting concerns, like authentication by themselves. The clients need to track multiple potential connections to the service. They will have different URLs but maybe also need different headers etc.

    Conclusion

    It depends. You know your architecture best, and there are plenty of articles discussing the pros and cons of BFF. I can recommend starting with this article https://learn.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern.

    • Do we talk about 3 or 30 microservices?
    • How often are the microservices called by the client?
    • How often the client needs to ask multiple services to generate a view?
    • Have you used an API gateway before?
    • Is authentication needed or a concern?
    • How regularly changes the API of the microservices?

    I hope my answer helps you to find your answer. :)