Loading
First things first, when adding Blazor Server to your stack you'll have to handle authorization. In Blazor authorization is made very simple and in simillar manner to adding authorization to your controllers. For my use case all it took was to add:
@attribute [Authorize(Roles = "TRANSLATOR")]
to the _Host.cshtml file.
If you're like me you're probably looking for a way to not write all your css styles from scratch. Althogh it can be optimal, powerfull, adding a toolkit like Bootstrap or MatBlazor can be a cheap and solid solution for your business. That ofc depends all of your use case and what your development team has experience with.
Good news is that you can even implement TailwindCSS into your application, but be wary that some features (like creating toggle for dark mode) will involve adding some JavaScript components to your frontend. Chris Sainty has some great blog posts and short talks on how that's done, so if you need more in depth information about using TailwindCSS with blazor I recommend checkint out his blog.
Sticky session goes hand in hand when working with BlazorServer. Blazor Server uses SignalR to communicate between the server and the client via the WebSockets protocol. Sticky session, or session persistence, makes sure all your requests will be handled by the same server process, or physical web server. Normally you would have a load balancer chosing which web server to serve your requests, but in order to make a SignalR work with multiple servers, we need to change that behaviour.
The error that you might be getting without sticky session enabled looks something like this:
Let's get started. I'll be using YAML-injection to change behaviour in our kubernetes manifest, you might opt out for different way depending on your infrastructure setup. All you need to do is add those 3 lines to the manifest:
nginx.ingress.kubernetes.io/session-cookie-max-age: '172800'
nginx.ingress.kubernetes.io/session-cookie-name: testName
nginx.ingress.kubernetes.io/affinity: cookie
Note! In order to see the changes you'll need to restart the deployment. Also if you're running your application on more than one server in your development or test environments, you'll need to repeat the process there as well.
Check out the docs for more information:
Sticky sessions example from kubernetes docs
For more in depth information about hosting and scaling SignalR application:
ASP.NET Core SignalR hosting and scaling
Error handling when working in Blazor Server might seem like a black box, since rather than operating with standard status codes and HTTP responses you're operating with SignalR connection passing and retreving data directly to your handlers. For my use case I opted out for Blazored Toast library, and injecting logger like so:
@inject ILogger<SomeRazorPageName> Logger
I'd imagine for most cases it's sufficent to have a easy way of informing the user when something went wrong and logging errors. Replicating and debugging is the absolute best part of Blazor Server, you're simply spinning up your Blazor application and you can step yourself all the way from frontend code to the backend code. No need to make api calls from Postman or Swagger, and no need of guessing if the error has occurend in frontend or backend of the application.
I believe Blazor Server is starting to become more and more essential, and has become my go to tool especially for developing internal applications. It drastically reduces amount of code needed to get started and is better at separating your client facing endpoints and internal UI logic. It can also be leveraged for a full on client facing application, but I remain sceptical in terms of scailing for a very large applications, and the overabundance of different JavaScript frameworks developers.