Pause and resume Blazor applications

[javiercn]

Summary

Enable the ability to "pause" a blazor application and enable components and services within a Blazor application to persist their state when the application is being "shut down" and enable a mechanism to retrieve and restore that state afterwards.

Motivation and goals

Today it is very hard to do prerendering without having the content flash on the page due to the fact that a regular component will render multiple times during an asynchronous code path like retrieving data from a service or datase and produce an intermediate render without content that will quickly replace the content on the rendered page to be followed by the actual content afterwards.

That experience is desirable when the application is not prerendering so as to be able to show content quickly to users, but it's jarring when prerendering is enabled. The guidance that we give our users is to compute all the state of the application ahead of time and pass it down to the root component as a parameter, with the idea of avoiding any asynchronous code paths when the state is available.

This has several drawbacks, like the fact that users need to extract complicated logic out of their blazor application to be run outside of the application context and avoid asynchronous code paths on their code which are very easy to introduce.

The idea is that when we prerender the application we "pause" the application and "persist" the state of components that opt-in into it. We marshal that state to the client and when the app "resumes" we make that state available for components that opted-in on to the feature.

This enables application authors to preserve all the state of their components, like data that was retrieved from a database and ensure that they can produce a deterministic render that is equivalent to content they prerendered on the server.

In addition to that, this same mechanism can be used within server-side Blazor to empower customers to "pause" Blazor server applications and resume them at a later point, for example when there is no activity within a circuit for a given period of time or when a server is experiencing heavy load, enabling better resource management.

In scope

• Provide APIs to preserve and restore component state when an application is "paused" and "resumed".
• Marshall the application state to the client and pass it back to the app when it "restarts".

Out of scope

• Serializing random object graphs.
• Automatic state management/restore.

Risks / unknowns

TBD

Examples

• Marshalling state retrieved from a service or database.
• Marshalling authentication state on the client.

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[michalczerwinski]

Some food for thought, from the perspective of large ERP system written in Blazor Server side:

• most Blazor components can be divided into two groups: readonly and edittable
• if all the compoenets in circuit are readonly we can safely asume component can be restored based on the params and urls
• if any of the component is editable then this component needs to serialize/deserialize the state

Perhaps having some attribute to mark the component type might be a good idea? Then system can act based on this

[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.

[mkArtakMSFT]

Moving out of 6.0 to make room for some of the tooling asks from the Razor compiler

[rwkarg]

Would also be nice in the Blazor Server scenario to have the state/interaction stored in an Orleans grain to survive changing servers such as during a deployment. We frequently deploy updates several times a day and the current loss of connection and state during a rollout led to us not using server side Blazor despite it otherwise being a better development experience.

[vindberg]

How come this was cut!? Please consider this back It's an essential feature for any server side webapp. Our users are seeing "connection lost" even when its a somewhat static page! Any workarounds you can suggest?

Thanks.

[HybridSolutions]

How come this was cut!? Please consider this back It's an essential feature for any server side webapp. Our users are seeing "connection lost" even when its a somewhat static page! Any workarounds you can suggest?

Thanks.

My 2 cents on this issue. Love Blazor, and never imagined I could see a time that I don't miss JS, but this issue of having an application getting disconnected every time after ~10m and showing that to the users it's bad. It's bad because users don't understand what happened, and they shouldn't, and also because my clients hate to see that on their websites after browsing other websites on other tabs. The visual experience is not good and at least, an automatic refresh of the page could be an option instead of that "Could not reconnect to the server. [Reload] the page to restore functionality." message.

I can't use Blazor on new projects because clients don't quite like this behavior as well. It's not critical, but bothers. Really hoping this can be addressed in .NET 7 somehow. For me, this should be nr 1 priority for the .net team.

UPDATE
As I mentioned in this issue, Blazor apps are disconnecting after 5-10minutes because the browser is forcing tabs to sleep, cutting off SignalR connection. If a tab does not sleep, a connection holds for hours without any glitch. This new browsers feature should be taken into account behind the scenes somehow.

Also, happy to see this original issue (#27576) is on the list for .NET 7

[javiercn]

For all folks watching this issue. I'm going to close this one in favor of #30344 as both are tracking the same work (we already did support for prerendering in 6.0) and the other issue more clearly reflects the intent (and we keep continuously confusing these two issues in our planning process).

If you want to clearly show support for a better reconnection experience where you can "pause" the app and "restore" it from that state, I suggest you instead upvote the issue #30344 to show support for it.

[vindberg]

@javiercn Thanks for the update - where do I upvote? Just a "thumbs up"?

[javiercn]

@vindberg yep