Blazor running c# on the server-side and in Electron - A Ramble

[davidbmasterson]

When I saw the demo of the c# code running on the server-side and sending the diff to the client

I thought my head would explode with all the things this would simplify for my team

We are a bespoke software company. We do not have a product, we write system for clients ranging from WinForms systems that track 1,000,000 tyres leaving a warehouse each year, to websites that quote business insurance to insurance brokers, to system for managing large plastic bag manufacturers and giant moulding factories and many more things.

What all these projects have in common are: -

• relatively small user bases, between 25 to maybe 500 users in total per application, not all of which use the system at the same time
• Complicated and often changeable data collection and validation requirements
• interaction with a SQL database, usually in azure.
• user identity and roles.
• User location within the UK so no more 500 miles from Cardiff or London data centres
• A web based application of some sort, even if it is only a part of a larger collection of applications

So potential down sides mentioned by Steve, Latency, Server Workload etc. would not be a problem for us.

What we could gain

• Objects never leave server, so are kept up to date in one place and do not need to be passed around
• Direct access to database
• Direct access to active directory
• Business logic, form validation etc all in one place, no need to part validate on the client and then revalidate on the server.
• single upgrade point, no worrying about cached copies.
• full .net
• load speed
• changes to business logic not needing to be sent to the client, or handled via an api.
• No sensitive data needed on the client
• No business logic on the client

While I appreciate that for huge large scale global applications hosting the application on the server using your own compute is a negative, but for relatively small user base, enterprise applications this seems to me like having my cake and getting to eat it too.

If it was possible I would like to see all three options built out, however my thoughts on importance have changed.

I started out seeing Blazor as a way I could replace angular or react etc. with a .net process which was really cool.

But the idea of having the option of running on the server or running like an installed application within electron allowing a multi-platform solution with access to local resources for the client compute option, these seem more compelling propositions than just removing the pain of having to code JavaScript (or even TypeScript) but still being limited by the browser manufacturers choices.

I apologies if this turned into a bit of a ramble, but I just wanted to let you guys know just how excited this project has got me and for a programmer of 30+ years that is quite an achievement.

Thanks for all your hard work on this, just so you know I will be absolutely gutted if this does not get the go ahead in all 3 forms, but can I have the server-side version first please.

[benaadams]

Latency

If you are going via a webapi and not caching data on the client; is server gen of html diffs much difference for latency? The main perf killer for non-SPA apps is full page reloads (re-compiling js, parsing css etc)

Also doesn't stop you from adding css animations or transitions to fill the time :)

[danroth27]

@davidbmasterson Thanks for the detailed feedback! A client-side model for Blazor is still our goal, but this feedback helps us understand if a server-side offering makes sense as a stepping stone to get there. It sounds like for your scenarios a servers-side offering would be valuable.

I'm going to go ahead and close this issue, as this isn't tracking any specific work with the product. Hope that's ok!

[Terricide]

Just FYI something like Wisej or Ooui might be a good fit.

[davidbmasterson]

@benaadams The issue with latency Steve was talking about was that if I want to change lets say the back colour of a selected row and that now requires a round trip to a server to set the SelectedRow value instead of in the local client app in the Blazor running in a browser model.

Then if the client was in London and the server was in Sydney

It would have 300ms latency + processing time on the server + processing time on the client which would be jarring if this was for all interactions,

However, if I was in London and the server was in Paris then the Latency would be 4ms which would not be an issue.

I was saying that for the 95% of SME websites written global reach is not the issue, remote working, client access etc. are more important and would not be effected by the extremes of global latency.

[benaadams]

Yes but you could do a lot of the instant feedback with css and no js e.g https://codepen.io/anon/pen/JZrYXe

And then wait for the server confirm to make it permanent

[davidbmasterson]

I appreciate that it would be possible to do such things but if the latency is in the 6 to 15 ms range i.e. 1000 miles from the server then I do not need to do anything other that process the click on the server and return the diff which would change the class on the row to selected, we may be talking a cross purposes did you see the asp.net community stand up this week https://www.youtube.com/watch?v=CWuIz9khK-o starting a 52:12

[benaadams]

we may be talking a cross purposes

I'm agreeing with you :)

A client-side model for Blazor is still our goal, but this feedback helps us understand if a server-side offering makes sense as a stepping stone to get there.

I just think a "server-side offering" is a completely valid deployment model and not a stepping stone.

Obviously client-side blazor is the must have deployment model; but server-side blazor fills a nice niche in the continuum that's currently under served: Client-side SPA<--->Server-side SPA<--->Full page refresh

[danroth27]

I just think a "server-side offering" is a completely valid deployment model and not a stepping stone.

Cool, that's useful feedback as well.

[zsvanderlaan]

I'd like to add another vote in favor of server-side for enterprise! All of the reasons listed were exactly what had occurred to me and absolutely blew my mind in terms of the development velocity speedup.

If this feature becomes available I and many others in the community will become blazor marketing machines! I just posted the below to the Gitter, and an even more positive announcement to my office's teams off-topic discussion. This would easily blow existing spa solutions out of the water for big and small customers.

PLEASE find a way to support both using a convention to allow for configuration per component instance. Blazor will become the standard UI development environment overnight.

Gitter: I am absolutely in love with the server model. Is there any code I can run right now to test drive this idea? It seems like it would be perfect for rapidly prototyping, and I'd like to dig into my next project this weekend.

I think it would be good enough for any internal enterprise application and most non-animation-heavy external ones as well (I could be wrong here, it would be amazing if I could use blazor for webVR in the future too).

With the next generation of cellular, 5G has been demonstrated to have really low latency and gigabit bandwidth, I think it would allow for a native feel in most cases while dramatically improving development velocity by cutting out all of the boilerplate / ceremony around the http connection by allowing access to server resources such as the DB or file system or remote process / network calls. It would allow the client architecture to mimic that of existing desktop applications.

I think the silver bullet though would be to offer both, and have a flag which could be set at an individual component level so that some components run on the client to get that sweet instant rendering of user interactions, while those which load sensitive data run on the server, only with significantly less developer overhead.

Office Topic Discussion: I think this is the coolest tech demo I've seen in my life.

TLDW: It's not just about Blazor, which is now old news, its a couple of new POC's, they show the server doing all the rendering, sending back diffs of the html over a websocket connection so that device compute power does not affect the app. also allows for seamless invocation of C# to do things like DB reads directly from client code, without ever having to deal with XHR or HTTP fetch or defining controller endpoints ever again, you can just directly access server resources, but all code invocations happen on the server so the client doesn't have arbitrary execute.

If you only have 5 minutes start here, it will blow your mind: https://youtu.be/CWuIz9khK-o?t=3135

otherwise the 45 minute version starts here and covers sharing object models across client and server, cross platform apps using electron (its not always evil, its the wrapper for VSCode). The code is just beautiful, and it looks like it removes so many artificial barriers that are the result of dealing with HTTP / remote interaction. https://youtu.be/CWuIz9khK-o?t=1182

[Kaffeegangster]

I confirm every single point of @davidbmasterson . Server side blazor would simplify developing internal LOB apps. It is just brilliant to send the virtual dom diffs to the client.

[GoranHalvarsson]

Hello Yes, I have to take back what I said about server-side. I thought about server-side in the "old way", you know do action on each web request and all that. But this is an entirely "new" way using server-side, no need to wait for each request. Do everything via websockets, this is wonderful. I think you are on to something here. Keep up with the good work Blazor people!!

[benaadams]

Server-side SPA, so hot right now! (from Airbnb)

Server-Driven Rendering

Even though we’re not using React Native, we still see the value in writing product code once. We still heavily rely on our universal design language system (DLS) and many screens look nearly identical on Android and iOS.

Several teams have experimented with and started to unify around powerful server-driven rendering frameworks. With these frameworks, the server sends data to the device describing the components to render, the screen configuration, and the actions that can occur. Each mobile platform then interprets this data and renders native screens or even entire flows using DLS components.

Server-driven rendering at scale comes with its own set of challenges. Here is a handful we’re solving:

[ghost]

Hello,

First of all i would like to say thank you very much for your great efforts making these nice things.

After watching this video about standalone using electron and server side via websockets. I have this question.

Can't we have a mix of server side with client side. So we get asp.net core for server side with blazor blocks (inside same cshtml file) for client side instead of javascript?

And let the blazor as a great choice for client side apps.

Regarding latency. I think too many people care about that. For example The nearest Azure server to me has 110 ms latency

[danroth27]

@ghost We're in the process right now of exploring various options for server-side Blazor including integration with existing ASP.NET Core MVC and Razor Pages based apps. We'll share more about what we think is possible and reasonable as those investigations progress.

Latency will certainly be an issue depending on the interactive nature of your app and your environment. That's one of the reasons why our end goal remains focused on delivering a client-side application model.

[enetstudio]

I guess that using server-side Blazor (Razor Components) in internal enterprise application may also have the advantage of forgoing proxy servers, and using only the Kestrel web server which is very fast.