Allow all or specific parts or a Blazor Server application to be stateless (no continuous SignalR connection and state automatically moved out of memory after rendering)

[nkosi23]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Blazor Server provides an inspiring and powerful application development and state management model. However at present a continuous SignalR connection must be maintained between every client and the server which limits scalability. Memory also is a limiting factor.

While the stateful nature of Blazor Server is generally highly desirable, an application may have hot paths not necessarily needing statefulness. For example a news website may have very high traffic on its "/home" and "/read/{articleId}" pages but have orders of magnitude less traffic on its account management pages and discussion forum. Since article reading pages do not have high interactivity and stateful requirements, keeping these components in memory is wasteful.

Such optimizations can make the difference between a single server being able to accommodate 100,000 users or 10,000. Having this option will make Blazor Server as competitive as other technologies for consumer applications.

Describe the solution you'd like

After #30344 is implemented (which is a hard prerequisite), Blazor Server will be in a position to allow users to create stateless components. Here what I have in mind:

• If a component is marked as stateless, its state is automatically persisted after rendering and moved out of memory
• Optionally (or alternatively - if keeping some components in memory and some not is not feasible), instead of marking individual components, the user can put specific routable components in a stateless area (this is similar to the idea of MVC areas). In practice a stateless area may simply be a route-defined namespace: for example Blazor Server would allow the user to define in the App component (or somewhere else more appropriate) that all routes matching the pattern "static/**" are part of a stateless area (eg. static/read/{articleId}).
• If a component is accessed using a route belonging to a stateless area:
  1. All the components of the page are considered stateless
  2. The SignalR connection is terminated after rendering
• To support these situations, the client side javascript runtime contains a code to reestablish the SignalR connection when the user interacts with the page (and the connection is immediately terminated after rendering). If feasible, users may be allowed to define on a per-component basis which event will trigger a reconnection (default is onclick, but sometimes onmouseover etc... may also be desirable)

With stateless areas, the developer chooses to trade responsiveness for better scalability and resource management. This will typically be used on the hot path of public consumer applications as for such applications it is very common to have high-traffic public pages being fairly static (and driving conversion to turn visitors into paying customers having access to the full or actual product).

The benefit of defining stateless areas using routes is that since Blazor Components may be accessed from multiple routes, developers are empowered to - for example - provide a stateful and more interactive experience to paying customers and a static and less responsive version to non-registered users (being orders magnitude more numerous but generating less revenue) and they can do so without needing to modify their components.

This feature will allow developers to have the best of both world and will further position Blazor Server and Azure as the perfect high-productivity environment to develop the next-generation of web applications. I have a sense that this feature would be quite in reach once #30344 lands.

Additional context

No response

[javiercn]

@nkosi23 thanks for contacting us.

Unfortunately this is not something we plan to pursue for the time being. Blazor model is inherently stateful and implementing something like this would be almost equivalent to a "modern" version of "ASP.NET Webforms" and would require us serializing the UI tree so that we can match existing event handlers in the DOM to elements in the UI during the "re-hydration" process, which is not trivial and not something we plan to pursue.

As per the stateless components bit, we wouldn't integrate something like that into routing or anything similar. We might in the future offer a way to do similar optimizations, but there's nothing currently planned in the near future.

[nkosi23]

@javiercn Indeed a modern version of ASP.NET WebForm is what I had in mind (I tried hard not to use the word but you have smelled it anyway 😆 fair enough). Thank you for clarifying that you are not interested in pursuing this path at this time.

Hopefully some sort of support for stateless scenarios will be added soon in one form or another to reduce the infrastructure costs of consumer applications - which is the main goal here.

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.