fullstackhero
Support WASM and Blazor Server mode switching
It will be nice to have an option to switch to/from WASM and Blazor Server mode. Server mode will make life easy during development phase (speed and debugging) for template users.
Or include a Blazor Hero template for Blazor Server mode.
@SathyarGit agree. Always better to develop in Blazor Server as it has full debug experience that is also fast to iterate on and then use Blazor Wasm for "production". Having this build into this template will be useful.
Potentially also useful is to incorporate a "prerendered" solution in production apps. On the first render of the app it's "blazor server" , once the app dll's have been downloaded it auto switches to a WASM solution. I understand this was introduced to mitigate the slow startup time of Blazor Wasm apps.
@neozhu plse see
https://andrewlock.net/enabling-prerendering-for-blazor-webassembly-apps/ https://jonhilton.net/blazor-prerendering-net6/
@Pinox
The problem I see with Blazor Prerendering apart form dual data retriving issue is, the need to implement both server-side and client-side implementations of all the services that we use in our Blazor app. So that the users will not get a sever error when they try to navigate to a certain URL explicitly. This is a time consuming work and probably would become a huge cost for a small benefit when scaling up the application. You can find a detailed description about the said issue here. I would personally recommend holding back the Prerendering implementation untill we get a proper solution.
@ANMSalman When implementing Blazor Server with WASM most of your code will be in shared projects, WASM will in this case reference the code from Blazor Server so that there is no duplication of code. So in debug mode you will run the Blazor Server implementation for quick iteration and in production you can run an instance of Blazor Server + Blazor WASM static files if you so wish.
Obviously running a Blazor Server app in production you will need a seperate instance (console app) running.
In .net 5 you will get 2 initial downloads of data (one from Blazor Server and then Blazor WASM when it comes online) In .net 6 that double loading issue has been solved as in one of my previous links above,
From my perspective the faster iteration time on Blazor Server makes it worthwhile to architect BlazorHero in such a fashion.
The switching from Blazor Server to WASM in production is a nice to have as initial load will depend on the size of the application. In bigger application where download time is an issue the switching from Blazor Server to WASM is probably worth it, also in mobile facing applications the WASM initial download might not be desirable as the initial load is now determined by the capability of the mobile device + mobile data speed that can be outright slow and unstable.
Obviously for line of business apps that mainly run on an intranet that is fast and stable the Blazor Server startup will be an overkill.
@Pinox I have a question. Blazor app is use httpclient consume web api in WASM, after switch to Server mode , do those code need to change?
@neozhu I think that depends on your implementation. If you client (Blazor Server and Blazor WASM) access an API (over http) then I don't see a reason why they will be different.
If the Blazor Server implementation access the database directly (not through API / HTTP ) then your server side code will be different.
WASM project can be switch to server mode directly, not change any code in theory. If Blazor Server application project (access the database directly) that doesn't switch to WASM mode directly. Right?
@neozhu plse see https://www.youtube.com/watch?v=AmhlPFguOMs&ab_channel=AshProgHelp-ProgrammingHelp
I have a pull request to enable BlazorHero client to run in server mode. When run in server mode, dev and debugging is a bit more friendly - UI load time is lot shorter and debugging experience is better. Change is based on http://www.appvnext.com/blog/2020/2/2/reuse-blazor-wasm-ui-in-blazor-server
https://github.com/blazorhero/CleanArchitecture/pull/186
This has been open for a while and I'm not sure where it is at on the roadmap, but you should also consider adding in Maui support as an option as well.
