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.

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.