Blazor in Production

Earlier this year I decided to resurrect my website. The site at the time was using Blazor Server and content was generated through a headless ghost install. While this gave a nice writing experience the maintenance of keeping a ghost install up-to date meant that the site ended up failing.

I was interested in Blazor after seeing the release of .NET 5, being able to write my site with c# sounded ideal.

I initially went with Blazor Server to build the site as it allowed for proper SEO. Unfortunately Blazor Server needing a constant connection was less than ideal as the browser would constantly kill this connection when in the background making for a less than ideal reading experience.

Improvements in pre-rendering has made Blazor WebAssembly more enticing to use. This coupled with the downsides of Blazor Server tip the scales in Blazor WebAssembly’s favour.

Moving to WebAssembly

Blazor WebAssembly is structured a lot like other SPA frameworks. The application runs from within the browser. This is different to Blazor Server which is executed from the web server.

Moving to Blazor WebAssembly from Blazor Server comes with some challenges however. As your code is now runs from the browser security needs to be rethought. Here is some tips for working with Blazor WebAssembly.

Static by default

Any content that can be made static should be. Static content is safer and more performant. Remember less code is safer code.

Dynamic is restful

If dynamic content is needed because static content isn’t possible than this should be fetched via an API. The API could be a standard Restful API or through more modern techniques like GraphQL. There is no reason to connect directly to a database from your Blazor client code.

SEO needs some thought

As your Blazor WebAssembly code needs to be downloaded before it can be executed search engines struggle to crawl your pages. This is because all they see is the webpage with the bootstrap code.

Blazor has a solution for this. Blazor Pre-render

Blazor Pre-render

Pre-rendering utilises Blazor Server to render the page out and then once the WebAssembly version is ready it is swapped out. This sounds too good to be true. Being able to get the SEO benefits of Blazor Server with the client side rendering of Blazor WebAssembly, well there is one downside. Your site now needs to be hosted on a web server and you are unable to utilise any of the static hosting sites like GitHub Pages for instance. You are able to read on how to implement pre-rendering on Microsoft Docs

The other issue with pre-rendering is data persistence, when the page swaps out to the WebAssembly version of the site all dynamic data is lost and needs to be refetched. Again Microsoft has a fix for this through the Preserve Component State Tag Helper. This helper allows to preserve state and doesn’t force a re-fetch of data on transition. You can read about it here

Today I discussed implementing Blazor WebAssembly for your production sites. Everything I spoke about in this post has been implemented here on glennhevey.com. Blazor WebAssembly is a great technology for building your next web project and if you take into consideration the information here you can get the best out of the platform.