Blazor: Combine server and client to get the best of two worlds

[Bartolomeus-649]

Background

With Blazor Server you can be very productive , even though the use of HTML and CSS. You can code in a real programming language like C# and almost never need to deal with JavaScript. The downside of Blazor Server is that the client needs to have an active network connection to the server, and network lag can be a problem on bad/unreliable network connections or if the "distance" between the server and client is too far.

With Blazor Client/WASM you are productive too, but no way near the productivity you have in Blazor Server where you have access to the full .NET Core API and can access databases and and other server side resources directly. On the other hand, with Blazor Client you don't need an active network connection, and you can even run offline.

So, what if we could get the best of two worlds. What if we could offload stuff to the client and only send back the important things to the server.

Html now has support for Web Components (Custom elements, Shadow DOM, templates, etc.), which makes it possible to add new tags to be used in html. New tags can be defined and provides encapsulation so they won't interfere with each other or with the html page where they are used.

Nicole has a prof of concept where she combines a normal web page with a WASM web component on medium.com: https://medium.com/coinmonks/develop-w3c-web-components-with-webassembly-d65938284255

Feature request

Obviously in steps and not all at once

• There should be one Blazor.
• Blazor should natively support the concept of "Blazor Web Components" (BWC) written in a real language like C#.
• When designing a BWC you should also define which parts of it can run on the client without any interaction with the server. For example, a Slider control could allow dragging the handle and update the GUI accordingly and first when the handle is released trigger a change notification/event. In this case the GUI is a client side functionality, and the server only knows the "output value" of the Slider control.
• Client state should be shared between the server and the client in such a way that even if the server is restarted, the client can continue where it left of as soon as the server is back online.
• It should still be possible to have a WASM/client side only solution.

• There should be an automatic, native and super efficient way of making function calls between the client and the server. When you are in full control of both the server and the client there's no need to use REST or whatever. How the client communicate with the server should not be an issue for the developer who uses Blazor, it should be built in, strongly typed and "just work".

  Also, but not part of this Feature request, Blazor really needs to become a first class citizen in Azure:

• Fully support Application Insights, both on the server and on the client.
• Support deploying a new version without all connected users being disconnected (For example: Drain stop current, new connections to new deployment) for all supported platforms in Azure.
• Support scale out/up without downtime or impacting connected clients.

[carlosalcantara2668]

incredible if it works, it would be ideal

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[danroth27]

Related request: https://github.com/dotnet/aspnetcore/issues/17678

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[stamminator]

For my team, this feature's absence is the only major factor preventing us from being able to use Blazor for our upcoming rewrite of our main app. Blazor WASM's frontloading MBs of assemblies is out of the question for our use case — users will simply leave if the questionnaire link they clicked on takes several seconds to load — and Blazor Server isn't going to scale well or provide sufficiently low-latency front-end interactivity.

Until we have the ability to use both together (Server for landing page, switchover to WASM once assemblies loaded), Blazor is not an option for us.

[Laftek]

Any updates? Cannot wait to have this!

[positiveactionsvcs]

Hi, I have been doing Blazor WASM development in .NET 6 for several months now and I want to make a general comment which is that I would really like the .NET team to advance this.

I am the kind of developer that really appreciates quick start up of an app for debugging and for my users as it makes me more productive, and currently with WASM I feel that the app start-up time slows things down just a little too much. On a very fast PC it's not too bad but not all users have this.

My idea of a "middle-way" is to have a server-based Blazor project which downloads some WASM up-front without the need to download the entirety of .NET.

[stamminator]

My idea of a "middle-way" is to have a server-based Blazor project which downloads some WASM up-front without the need to download the entirety of .NET.

@positiveactionsvcs the challenge with this is that you still need the .NET runtime in place before anything can run in WASM. They've made some progress with this in .NET 6 and 7 (I forget what they call it, but I know it as "tree shaking") to have the client only download the parts of .NET that they need, but there are limits to how much size/speed this can save.

Ultimately, even if the .NET WASM runtime that's downloaded on the client is twice as bloated as it optimally could be, the model proposed in this issue mitigates it quite well.

[RemiGaudin]

Steve Sanderson just announced his Blazor United prototype: https://youtu.be/48G_CEGXZZM I think this is his solution for this issue ;)

[cactusoft]

There should be an automatic, native and super efficient way of making function calls between the client and the server. When you are in full control of both the server and the client there's no need to use REST or whatever.

I think this is really important. The beauty of Blazor server, and web forms before it, is that you have a single entrance into a page to authenticate the user, rather than the MVC approach where you move all your page logic client side and then need to secure a bunch of web API endpoints which are all publicly accessible.

I wonder if it is possible that the web assembly can be generated and secured in such a way that it can be trusted to communicate with whatever endpoints the API has, without each endpoint having to separately authenticate each request. Kind of like viewstate in web forms was encrypted so information could be stored and trusted. even though it was in plain sight.

[SteveSandersonMS]

I wonder if it is possible that the web assembly can be generated and secured in such a way that it can be trusted to communicate with whatever endpoints the API has, without each endpoint having to separately authenticate each request. Kind of like viewstate in web forms was encrypted so information could be stored and trusted. even though it was in plain sight.

Unless you have a specific proposal, I don't think we have any new mechanisms than have existed for other client-side code scenarios for the last few decades (e.g., native apps or JavaScript browser apps).

[RemiGaudin]

Blazor United related work is now tracked by https://github.com/dotnet/aspnetcore/issues/46636

[danroth27]

Hi folks. Since we're planning to address this feedback with the Blazor United effort, I'm going to go ahead and close this issue as a duplicate of https://github.com/dotnet/aspnetcore/issues/46636. so that we can focus our attention there.

[Bartolomeus-649]

@danroth27, @SteveSandersonMS I have seen no indications of this being addressed:

• There should be an automatic, native and super efficient way of making function calls between the client and the server. When you are in full control of both the server and the client there's no need to use REST or whatever. How the client communicate with the server should not be an issue for the developer who uses Blazor, it should be built in, strongly typed and "just work".

[danroth27]

I have seen no indications of this being addressed: There should be an automatic, native and super efficient way of making function calls between the client and the server.

@Bartolomeus-649 That's fair. We do envision facilitating client-server data access for Blazor United apps, but it hasn't been decided yet what approach we will take, and I don't think we have a good tracking issue for this yet. There's lots to consider: What format/protocol should we use? How do we provide a strongly typed integrated .NET programming model without introducing tight coupling? How do we enable interoperability for when these endpoints aren't just for the frontend client anymore? How do we appropriately surface considerations when making network calls like network failures or latency? Is there tech we can just reuse without having to reinvent the wheel? Etc. Do you want to split this out as a separate issue and start the discussion on a proposal?