1

Our current Blazor Server project references the Client project, and we would like to decouple them, because we want the controllers to act as a WebAPI - to be used by our Blazor website, mobile apps and also customers wanting to integrate with our system. We have considered splitting the controllers out in a separate service project. Are there any pros or cons to this anyone can think of? And how would you go about doing it?

Edit - this is a WASM solution with Client, Server and Shared projects.

H H
  • 263,252
  • 30
  • 330
  • 514
Jesper
  • 331
  • 3
  • 12
  • 2
    Blazor Server doesn't use controllers, it uses pages and components. If you call API controllers through HttpClient you're already making "remote" calls on the server side. Those controllers could easily run on a separate port or URL. You'd only have problems if you tried to make HTTP calls from the browser using Javascript, in which case [CORS restrictions](https://docs.microsoft.com/en-us/aspnet/core/blazor/call-web-api?view=aspnetcore-6.0&pivots=server#cross-origin-resource-sharing-cors) would prevent calling a different domain. You can configure the Blazor Server to add allowed domains – Panagiotis Kanavos Sep 07 '22 at 08:57
  • 1
    I think this is about Blazor Wasm (Client+Server+Shared projects). @PanagiotisKanavos – H H Sep 07 '22 at 09:05
  • 2
    On the assumption that you are really taking about Blazor WASM, why do you want to de-couple them? You have to serve your WASM files from somewhere. All the Server project is doing for the WASM client is providing static file services. Get the base html file for the SPA and then provide the usual CSS and JS files along with the WASM files. The Blazor WASM SPA is just another client. – MrC aka Shaun Curtis Sep 07 '22 at 09:15
  • 2
    @enet the OP wrote `Blazor Server project` so I assumed that's what they meant. If they mean the Server project in a hosted Blazor WASM solution, CORS is an even bigger concern. – Panagiotis Kanavos Sep 07 '22 at 10:13
  • 1
    Having separate API endpoints makes *great* sense especially for more complex applications, but has its own complexity. Right now the Server project acts as one big service. It needs to be deployed when every subservice/controller/area changes. On the other hand, the services/modules that need to be deployed together are always deployed together. And authenticated, logged, configured together. Using multiple services instead of a single big one means that each service can be deployed independently, but now you have to manage version, auth, logging, tracing dependencies between those services – Panagiotis Kanavos Sep 07 '22 at 10:18

1 Answers1

1

Our current Blazor Server project references the Client project, and we would like to decouple them

The Server does have a project reference to the Client but that is a little trick, it makes MS-Build copy the output of Client to the Server's bin folders. So that the Server can easily 'serve up' the Client. The Server does not call or use any code in the Client.

You could remove the reference and do some configuration with path strings in the Server startup code instead. I don't know the exact details.

So, in accordance with the comment from @MrCakaShaunCurtis, you already have a separate API Server. One that runs on the same URL and port (no CORS issues) and with the small extra job of serving up a bunch of static files that form the Client.

H H
  • 263,252
  • 30
  • 330
  • 514