The trick is to start the company yourself. :) We're 3 years in and full .NET stack.

Is your project an internal app or public?

I'm cautiously optimistic about Blazor Server but I'm not sure I like the sticky SignalR requirement. The expectation seems to be that the backend server will keep around a lot of state (cough viewstate?) in memory associated to that session. It's a very convenient dev experience for sure, but it seems difficult to scale beyond internal business apps.

This is why they recommend using the Azure SignalR Service, I guess :)

Indeed. That's that the only way I'd consider it. Luckily, they are generous with the free messages. Last I looked it was about $161 per day to scale to 100k concurrent users. But that's just SignalR. We'll also need much beefier AppServices with lots more memory than what we use now.

Not quite sure how it works beyond that when you need multiple service instances connected with a backplane. The new premium tier I just saw sounds convenient though.

https://azure.microsoft.com/en-us/pricing/details/signalr-se...

https://youtu.be/OsdBpMumf_c?t=635

It is an internal app, otherwise I would go for web-assembly with an API.

dev on .net is something I can understand ... but deploying and running windows servers in prod sounds like a hellish nightmare

The full .NET stack runs on Linux now. It’s even in RHEL’s repos. Heck you can even run MS SQL Server on Linux now if that’s your thing.

It is in Ubuntu and the AUR ( Arch ) as well.

In pragmatic terms, .NET is as native as anything else in Linux at this point.

You can even build it from source: https://github.com/dotnet/dotnet

In fact, the VMR ( linked above ) ONLY works on Linux at the moment with Windows and Mac support planned. So, .NET is Linux-first in some ways.

MAUI is not Linux first of course. The rest of it is becoming more and more Linux and container focussed though it seems.

You can run it all on linux and containers or whatever you want these days.

Where I work, we all use MacBooks and deploy our services on Linux boxes. .NET has been cross-platform for years now.

What kind of setup do you have to avoid users noticing the drop of their websocket connection due to a deployment? Blazor Server development experience is very good, but even for an intranet application, it can have a poor user experience by default due to the requirement of a persistent connection.

It is yet to be launched but it will be used by a small number of users in a intranet.

If there are issues I will just convert to webassembly.

We've deployed multiple applications without issue over extranet. We release our apps usually outside office hours so a dropped connection or two isn't an issue. Just make it clear when there will be maintenance.

It's easy to start with, as I did, but do yourself a favor and move to Blazor Webassembly. Blazor Server handles UI events in a centralized way, and network lag really destroys the application. It might be ok on a fast and reliable intranet, but you really don't want to use it on the general internet.

Standard Blazor Webassembly project setup creates a server side project and a client side one. C# code on the client side is compiled to Webassembly. You then set up your server side functions called from the client side with usual C# .NET REST functions. This is less convenient than the Blazor Server model, but it captures the actual complexity of internet networking. It's also fast. You can put a lot of (hopefully non-confidential) processing onto the client side, running locally in the user's browser using a huge array of .NET library functions including from NuGet. It really is the way to go.

The load times and lighthouse score for the MUD Blazor site has put me off of Blazor entirely for anything public facing:

https://mudblazor.com/

Blazor Server works well for low-latency Intranet Apps, it's stateful SignalR rendering circuit isn't suitable for laggy Internet Apps where deployments and long running Tabs results in users seeing frequent YSOD's.

Which can be avoided with Blazor WASM that has different trade-offs with poor start times & SEO. Hopefully something that can be resolved with their upcoming Blazor United solution, which I'm assuming means no longer being able to host Blazor WASM's static assets from a CDN.

This is what we use it for. All of our internal admin/devops dashboards are built using blazor server. Employees on the east coast have the best experience, but no one in Texas seems to complain (server is in Virginia). We don't have any employees west of Austin, so latency works out fairly well for us.

Same here. Blazor Server is so awesome. It really allowed us to focus back on the business problems rather than getting some Stockholm syndrome about a library or framework that is actually just in the way and you have to take into account all the time.

It also allows to add real-time functionality in a breeze. Even business applications can profit from that, but you often just skip that because it is not worth the effort.