Our GreatIdeaz trellis application was originally built as a .NET Framework 4.7.2 web forms application. When we decided to modernize it and create trellispark we chose Blazor as the natural way forward.
Like many development teams we had to make a choice between Blazor Server or WASM Client.
In our .NET Framework 4.7.2 app all access to data was on the server, behind the firewall, and we only served “completed” pages to the user’s browser. These pages only contained the data that the user was meant to see, or workflow activities that the user was allowed to do. We could perform logic in our server-side aspx page code-behind using the whole dataset, confident that nobody outside the firewall could see what was happening.
When we looked at modernization, the obvious path was to use Blazor Server. That way we could do the same sort of processing on the Server and just pass the “completed” user experience to the client browser. This was considered the minimal changes and the default go to approach.
We realized that there was still a choice to be made and so we did a lot of research, built some prototypes, and had a lot of internal architectural design discussions.
We found that the key problem with WASM clients is that you almost have to assume that the client is compromised and somebody on the client can see anything you send. This meant that we couldn’t just send the whole of a record to the client as the user might not be allowed to see certain fields or initiate some workflows. Using a WASM Client would mean a significant change to the architecture of our application – essentially splitting the UX.
On the Server side we can still see the whole record and initiate any required workflow. But we could only send a restricted set of data and controls to the user’s WASM client for actual rendering based on the state of the record and roles of the user, etc.
For us this was a significant piece of work and was why we had to really question whether we wanted to go WASM Client instead of Server.
In the end we thought that the benefits of being able to utilize the capabilities of the underlying device would minimize our server footprint making our applications more scalable. Having a WASM Client also helps with network traffic flow and enables a much more responsive user experience as we can process a lot of events client side and only post back data changes to the server. Also, with the release of MAUI Essentials we are now in the process of harnessing device features like geolocation, maps, phone, etc. for native cross platform applications.
In the long run, we decided that the rework to move to the WASM client was justified based on scalability and performance considerations. It also gave us the opportunity to rearchitect with an eye towards future MAUI Hybrid solutions.
In the Blazor documentation it says that moving between Server and WASM Client is simply a compile time choice. I don’t think that is true for most applications. But now that we have developed a secure WASM Client, it would be easy for us to go to Server if the circumstances justified it.
If we had started with Blazor Server, it would be impossible to simply switch to WASM Client without re-architecting the solution – the security issues alone would be untenable. Overall, we are thoroughly happy with our decision to invest the time and make the transition to Blazor WASM Client and our trellispark platform has benefited tremendously.