Description
Is there any documentation, article or other resource that shows the ways of solving the issue with loosing app state in server-size blazor? The documentation says:
Blazor server-side apps require an active SignalR connection to the server. If a connection is lost, the app attempts to reconnect to the server. As long as the client's state is still in memory, the client session resumes without losing any state.
It says that as long as the client's state is still in memory, the client session resumes without losing any state. But what can we do when the client's state is not in the memory anymore because the app was down after redeployment for example or when the client was disconnected and tries to connect again but reaches different server.
So the main questions are:
- What are the best practices of persisting the users app state and recovering it after the sever was down.
- How to make sure that user reconnects to the same sever after being offline (or if we can make sure).
I think answering those questions at early stage is important in terms of using server-side blazor in any kind of solid business where things like scaling out are in use.
When it comes to first question i suppose we could keep the state in Redis but then we would need to somehow identify the users, including anonymous ones, to have a unique key for each app state per user.
Would be also very nice to know how Blazor is managing the users app state in memory. And how to control the whole process of using it in order to put some extra logic to persist and recover.
The second question is maybe handled by Azure SignalR Service, but I haven't seen any solid article or documentation saying about it in context of sever-side blazor. I found a nice starting point here:
https://docs.microsoft.com/en-us/aspnet/signalr/overview/performance/scaleout-in-signalr