Best Approach for Preserving User Input Across Blazor Pages in ASP.NET Core Application with User-Specific Data Storage

Question

I have an ASP.NET Core application with Blazor pages featuring a sidebar containing five URLs. Each page consists of 15 input boxes. I need the input data to persist after page refreshes or when switching between URLs. Additionally, this data should be accessible in the backend for calculations. Considering the presence of a login page, the input values and backend data should be specific to the logged-in user. I've considered using server-side session storage, but I'm unsure if this is the most elegant solution. What are your suggestions for achieving this functionality?

Specifically, I'm looking for recommendations on how to:

1. Preserve input data across page refreshes and URL switches.
2. Store the input data securely and efficiently on the server, ensuring it's only accessible to the logged-in user.
3. Maintain a connection between the input data in the frontend and its corresponding representation in the backend for calculations.
4. Explore alternatives to server-side session storage if it's not the optimal solution for this scenario.

Any insights, recommendations, or best practices would be greatly appreciated. Thank you.

I must admit that I haven't delved into implementing any specific solutions yet. While I'm aware of the concept of server-side session storage and browser local storage, I haven't attempted to integrate them into my ASP.NET Core Blazor application. My hesitation stems from uncertainty about the most appropriate approach and concerns regarding scalability, efficiency, and data security.

Answer 1

Server-side storage - is a good way! I will just rephraze your claim to make it more specific - frontend storage is a good way.

The reason for rephrazing is latency. When you work with frontend - the latency is a measure of quality of service (QoS), so faster calls - means faster UI/API, better UX. So your storage have these requirements:

1. It should have really fast lookup. Any Cloud Tables or redis is what comes to mind. Redis is better because you can subscribe backend to latest updates instead of implementing notification yourself. Worst decision is SQL, transactions are bad for latency.
2. It should be as close as possible to frontend. Same region, maybe subnet, maybe machine, etc. Same region is usually fast enough from my experience in scaled systems, +20ms wont do a thing to latency.

This way your frontend will be fast, backend can be in any latency range and you also get a shared state between frontends (can freely scale frontend up/down, perform new releases and generally do maintenance tasks on your servers without loosing user session). So your user can , for example, switch between mobile site version, mobile app, desktop site, at the time you deploy new release and user can still have access to his settings.