Which project template to choose if I want a seperate web api, yet still run server-side and later to client-side?

Question

When one creates a ASP.NET Core project using Blazor, this presents some interesting architecture decisions. There are 3 different project templates.
- Blazor
- Blazor (ASP.NET Core hosted)
- Blazor (Server-side in ASP.NET Core)

Question 1
I'm trying to understand the purpose or benefit of the "Blazor (Server-side in ASP.NET Core) " template or approach to structuring a project. Why have a .NET core app serve up another .NET core app ? Or am I missing something? Given the different hosting models explained here.
https://blazor.net/docs/host-and-deploy/hosting-models.html
Couldn't this simply be one project that uses server-side Blazor rather than 2?

Question 2
If I am looking at architecture like that shown in the image below, shouldn't I start with the "ASP.NET Core Hosted" template, then change the .Client project to use the "server-side" framework? That way, I still have a callable api that can be accessed from another app if needed? Or I suppose I can still use the "Server-side" template, which would pre-set all the startup plumbing for firing up the Client with the server-side hosting model, and combine this with adding my own API controllers to the .Server project, which would be called via the business rules library as per the diagram.

Question 3
At some point, I might want to switch the .Client app to use webassembly when the tooling/debugging support becomes better. I don't think the architecture I'm suggesting prohibits that? I would just change out the startup code in the .Server app, replace the reference to blazor.server.js with the blazor.webassembly.js and a few other things and I should be golden. Am I off base here?

Notes on architecture:
- Client app needs access to a resource via some CRUD operation, so it makes a call into a method in the Business Rules class library
- Business rules library references a class library that contains "dumb" POCO classes that represent various domain models. Makes a call to an api
- API controller/action then calls a Data library or repository that manages a Entity Framework DbContext for fetching/updating the data in the Db
- Both the Business rules library, the Data library and the API all reference the "Models" library.

Answer 1

Maybe this Blazor Template can help you to achieve what you want

I want a seperate web api, yet still run server-side and later to client-side?

Blazor Templates (Author here)

Is a Visual Studio 2019 Preview 3 project template for creating Blazor v0.8.0 solutions that can be hosted either client or server side, the idea behind this is to have a convenient implementation that allows changing from hosting models easily.

So basically in the same solution, you'll have:

• web-api (ASP.Net Core Hosted)
• server-side (Razor Components with SignalR and debugging)
• client-side (SPA + webassembly)

That way during development time you can select and run the server-side project in order to have full C# debugging capabilities, later on, select the client-side project and publish it as a Stand-Alone SPA running over webassebly without touching a single line of code.

Even more, while running in server-side mode not only the Razor Components with SignalR and debugging can be used but also the Web API controllers, so you can simulate the actual behavior the application will have in production.

Hope this helps

Answer 2

Question 1: Server side rendering has a number of benefits including:

1. Since the UI update is handled over a SignalR connection, we can avoid unnecessary page refreshes.
2. The app download size is smaller and the initial app loads faster. The Blazor component can take full advantage of server capabilities such as using .NET Core compatible APIs.
3. It will also support existing .NET tooling like debugging the application and JIT compilation.
4. Since server-side Blazor runs under native .NET Core process, and not under Mono WebAssembly, it is also supported on browsers that have no WebAssembly support.

Yes you could have one server side app with access to a db without needing api. This in turn would restrict your app to server side rendering unless you refactor.

Question 2: Yes I believe you should be fine as long as you write your code to support client functionality. e.g Http requests from the app to api.

Question 3: Yes you are correct with a few small changes within the code you will be able to support both server and client side. One thing I would query is how you write your code on the client i.e if you were to make use of standard .net libraries, they may not be fully supported from the client. Additionally, if you made a server side app first and made services to call to get data e.g. accessing db context, when switching to web client config you would most likely need to make http web requests.

Additional information about an experience switching can be found here: Link