DEV Community: Kushal Rathod

The Central Store

Kushal Rathod — Sat, 20 Jun 2026 10:39:50 +0000

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 them
Supports 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...

Lies on Frontend

Kushal Rathod — Sat, 13 Jun 2026 10:14:30 +0000

Hey 👋

So, this is my first blog on this platform, actually, my first blog anywhere 🙃. And since I have a keen interest in Frontend, you'll mostly find my yaps around that only. Yeah, I call my blogs "yaps" (just me things).

So what's a better way to start writing than talking about one of the biggest lies I've heard throughout engineering?

"Frontend is dead."

I have friends who work on backend and low-level stuff. I'll mention some of them at the end - do check them out if backend is your thing (not a paid PR 😂). But honestly? Those things never really interested me. While, Frontend always did.

Whether it was learning JavaScript internals, understanding how rendering works, or building UI components that actually feel good to use, frontend was one of the few things in engineering that genuinely kept me curious.

And because of that, I decided that this is the direction I want to build my career in. But then people around you start saying things.

"Bruh, Frontend? It's 2026. Wake up."
Your YouTube feed starts recommending videos titled: "Frontend is DEAD."
Some professors say things like: "If you just want to do frontend and join a company, then why are you even doing engineering?"

And after hearing enough of these things, there was a point where even I started questioning myself. Like, Really? Frontend?

Two Things Before We Continue

If you've heard similar things and you're tired of listening to them, do these two things:

Listen to this song 🎵
Kuch to log kahenge, logon ka kaam hai kehna.
(People will say things. It's their job to do so.)
Continue reading 😌
Because I have a few things to say.

Frontend Isn't Dead

If you're still reading, let me try to convince you that choosing frontend isn't some terrible career decision. First of all, companies like Microsoft, Uber, and many others aren't crazy. They still hire frontend engineers. They have Frontend SDE-II roles, Senior, Staff and Principal Frontend roles.

If frontend were truly dead, these positions wouldn't exist. Now yes, one thing is true. Frontend roles have slowly shifted towards full-stack expectations. Companies often expect engineers to understand the entire flow—from UI to APIs to databases. But that doesn't mean you need to become a backend wizard who can design distributed systems in their sleep.

I do think everyone should learn some backend. And by some backend, I don't mean just making one Express server and calling it a day. Understand APIs. Understand databases. Understand caching. Understand queues. Understand how systems scale. Even though you don't go much deep, but you need to know them.

Frontend Is Just Moving Buttons

Now let's talk about my favorite lie.

"Frontend is just moving buttons around."

Bruhhhh 😭. If that's what frontend is, then yeah, Frontend is dead. Because even AI can generate that. But frontend is much more than that. There's:

Performance optimization
SEO
Rendering strategies
Frontend caching
State management
Accessibility
Testing
Bundle optimization
Web security
Architecture decisions

And a lot more.

A frontend engineer might spend days improving page load times by a few hundred milliseconds. Reducing bundle size. Optimizing React renders. Improving Core Web Vitals. Designing a caching strategy. Making sure an application works for thousands or millions of users. That's not "moving buttons." That's engineering.

And if you look at most frontend job descriptions, you'll notice these are exactly the things companies care about.

What I Think Every Frontend Developer Should Learn

My opinion?

Learn some backend. Not because frontend is dying. Because understanding the entire system makes you a better frontend engineer. Learn frontend system design too. And yes, Frontend system design is a real thing 🙃. System design doesn't automatically mean databases, load balancers, and microservices.

Learn how large frontend applications are structured. Learn state management. Learn performance. Learn rendering. Learn architecture.

And of course, work with AI. But don't blindly copy-paste everything it gives you. Make AI work for you and not the other way around.

And never leave the fundamentals. Whether it's JavaScript, React, browser internals, networking, or performance. The fundamentals are still undefeated.

Final Yap

If someone tells you frontend is dead, send them this blog 😌.

And if frontend is something that genuinely excites you, don't abandon it because a random YouTube thumbnail told you to. Learn it properly. Go deeper than just components and styling. Understand the engineering behind it. And most importantly, build stuff. A lot of stuff.

Also, wait for more yaps 👀. They won't be motivational posts 😂. But, instead I will talk about actual frontend things:

JavaScript internals
Debouncing
Event loop
Rendering
Performance
Browser magic

And hopefully make them interesting enough that you don't fall asleep halfway through.

If Backend Is Your Thing

If you're into backend, low-level systems, databases, or backend system design, check out:

https://keep-alives.hashnode.dev/

THANKS for reading the first YAPPPPPP ❤️

CodeCoach — A new way of practicing codeforces

Kushal Rathod — Fri, 16 Jan 2026 20:05:41 +0000

Hi coders, hope you all are coding well. I am Kushal (or TheCodster) and wanted to share something with you all.

So, I have not been much into CP, but what I have seen is people practicing random topics or sheets for improving themselves. But I believe why solve any random questions, and not just practice what is required. Hence, after talking to my peers, I thought of building CodeCoach.

CodeCoach is an open-source platform, aimed to improve your skills where you lack. Just, select the topics, your rating, and the daily questions limit, and boom, you are done. You will receive daily questions but not at a fixed time, instead whenever you login and get the questions, from that time, the 24 hour clock will start. You can build your streak, track your stats and more.

It's still an evolving platform, where you can also contribute, and make it grow, as it will help our coder's community only. Please do give it a look, and share your response, like how was the idea, any bugs on the website, what more should be added and more. Let's build a platform for the community, by the community.

Website: CodeCoach
GitHub: github.com/KushalXCoder/codecoach