The central store
So ever thought, how does the settings page of the website automatically have your data ? Obviously, at some point, user data comes from the database. But do you think that on every page reload, every component of the website directly queries the database again? In most modern applications, the answer is no. Then, how to provide user details to different parts of code, whenever they need it ? So in this blog we would discuss on different methods, which helps in solving this problem in your website.
The Local Solution
So, the first and the very basic solution is storing the required user details in the local storage using the Web Storage API. Using it is simple, you just need to do :-
localStorage.setItem('key','data'); // To store items
localStorage.getItem('key'); // To fetch items
Local Storage provides a key-value pair, where you need to create a key and store the details corresponding to that key. But, with great power comes great responsibilities. And local storage fails there. Because anything in local storage is accessible from any JavaScript running on your site. While localStorage is perfectly fine for caching non-sensitive data such as theme preferences, language settings, or UI state, it is generally not recommended for storing authentication tokens or sensitive user information.
Cookies: The Industry Standard
Hence, comes the best solution which is widely used and implemented by everyone, i.e. storing data in the cookies. Yeah, the same cookie, regarding which you receive a notification, whenever you visit a site 😂.
Before moving on, let's see, why using cookies is the best :-
Cookies can be marked as
HttpOnly, which prevents JavaScript from accessing themSupports various security attributes like
secure,same-site, etc.
But, are cookies fully secure ? No, cookies can be vulnerable to CSRF attacks if configured incorrectly. However, modern security features combined with HTTPS and proper server-side validation, make them a highly secure choice.
The Store
Now, we found our best way for storing the required user data, the cookies. But, we can't everytime, take the token from the cookie, decode it and then take the details and provide it to a component. Hence, we need a central store which works as the common source of truth across the website for different items.
For this central store, you can use Redux or Zustand, the best two state management libraries out in the dev world. I personally prefer Zustand, cause of it's easier syntax, and some other advantages.
Making Everything Work Together
Now comes the interesting part. We have:
User data stored securely inside an HttpOnly cookie.
A central store (Redux/Zustand) that components can access.
But how do we connect these two? And the answer is hydration.
Whenever a user reloads the page, the in-memory store is completely reset, because Zustand and Redux stores live inside the browser's memory. Once the page refreshes, all that data disappears.
To solve this, we create an endpoint, usually something like /api/me. This endpoint acts as a trusted server-side layer that verifies the token before exposing user information to the frontend.
On every application load, an authentication hook runs automatically and calls this endpoint.
useEffect(() => {
fetch("/api/me");
}, []);
Now, what happens inside /api/me?
The browser automatically attaches the HttpOnly cookie.
The server reads the cookie.
The JWT signature is verified.
The token payload is decoded.
User information is extracted.
The user object is returned to the frontend.
And hence in this way, we don't query the database, as all the essential information required by the frontend already exists inside the JWT payload. The server simply verifies the token, extracts the information, and sends it back.
Once the response reaches the frontend, we hydrate our store. And, now the store contains the latest user information and becomes the single source of truth for the entire application.
Any component that needs user information can simply subscribe to the store.
Whether it's the Navbar, Profile page, Dashboard, Settings page, or any future component, everyone reads from the same store instead of making separate API requests.
This gives us three major benefits:
Better performance because we avoid repeated requests.
Cleaner code because all user information comes from one place.
Consistent UI because every component sees the same data.
The complete flow looks like this:
And that's how modern web applications keep user information available across the entire application without querying the database on every page reload.
Things To Check Out
Zustand - https://zustand.docs.pmnd.rs/learn/getting-started/introduction
Redux - https://redux.js.org/introduction/getting-started
Hope, I didn't bore you and helped you understand something new regarding frontend 😊. And hopefully, you now realize that frontend is much more than just moving elements around the screen 😂.
See you in the next blog, with some new frontend topic...