Managing state in React often starts with a simple idea: keep data in one place and update it when something changes. But as an application grows, state management can become more complicated than the UI itself.

Traditional approaches often require immutable updates, carefully structured reducers, selectors, and additional boilerplate to keep components synchronized with application state.

These patterns work, but they introduce an extra layer of complexity. Developers spend more time describing how state should change rather than focusing on what the application actually needs.

This is where Valtio offers a different approach.

Instead of relying on manually managed immutable updates, Valtio uses JavaScript Proxies to make state reactive. You work with ordinary JavaScript objects, while Valtio tracks changes behind the scenes

The result is a simpler way to manage shared state without sacrificing performance or control.

The Core Concept: JavaScript Proxies

At the heart of Valtio is the JavaScript Proxy object.

A Proxy allows you to intercept fundamental operations on another object, such as reading, writing, and deleting properties. This gives libraries the ability to observe how an object is being accessed and modified without changing how developers interact with it.

Valtio builds its state management model around this capability.

Instead of creating a reducer or defining update functions for every state transition, you can create a proxy around a regular JavaScript object.

import { proxy } from 'valtio'

const state = proxy({
  count: 0,
  user: { name: 'Alex' }
})

state.count++

The important detail is that the state looks and behaves like a normal JavaScript object.

You can directly modify its properties, update nested objects, and work with familiar JavaScript patterns. Valtio handles the tracking and notification process internally.

This removes much of the ceremony associated with traditional state management.

Fine-Grained Reactivity with useSnapshot

Making state reactive is only part of the solution. In React, the real challenge is knowing when a component should render again.

Valtio solves this through useSnapshot.

ather than giving components direct access to the mutable proxy, useSnapshot provides a snapshot of the current state. It also tracks which properties a component actually reads.

import { useSnapshot } from 'valtio'

function Counter() {
  const snap = useSnapshot(state)

  return <p>{snap.count}</p>
}

Here, the component depends only on count.

If another property changes, such as state.user.name, the Counter component does not need to re-render because of that unrelated update.

This is the key advantage of Valtio's fine-grained reactivity.

With many traditional state management approaches, developers may need to write selectors or carefully organize subscriptions to prevent unnecessary renders.

Valtio tracks property access automatically and uses that information to determine which components need to update.

This makes component subscriptions more precise without requiring additional configuration.

Beyond the Basics

Valtio also provides a useful foundation for patterns that commonly appear in modern frontend applications.

Persistence :

Application state can be synchronized with browser storage, such as localStorage, allowing selected data to survive page refreshes.

This is particularly useful for user preferences, interface settings, and lightweight application data. Persistence is handled separately from the proxy itself, keeping storage concerns independent from state updates.

Derived State :

Valtio supports derived values through JavaScript getters.

Instead of manually updating a calculated value whenever its dependencies change, you can define logic that derives it from existing state.

This keeps related data together while avoiding unnecessary synchronization between multiple state properties.

Both patterns demonstrate an important idea: Valtio does not attempt to replace JavaScript. It builds on the language's existing capabilities.

Valitio in one

Valtio takes a different approach to React state management by using JavaScript Proxies as its foundation.

It removes much of the boilerplate associated with immutable updates while preserving the simplicity of working with regular JavaScript objects.

More importantly, its snapshot-based subscription model provides fine-grained reactivity, allowing components to respond to the exact parts of state they depend on.

The architecture is straightforward:

• Proxies make ordinary objects observable and mutable.
• Snapshots provide a consistent view of application state.
• Fine-grained tracking keeps React components synchronized with the data they actually use.

For modern frontend applications, this combination offers a practical balance between simplicity, performance, and maintainability.

Valtio is a good example of how understanding native JavaScript features can lead to cleaner abstractions and a better developer experience.

Sometimes, the best state management solution is not another layer of complexity, but a smarter way to work with the JavaScript we already know.

Most of the time, this leads to messy code, confusing bugs, and a system that breaks easily when it grows.

To build a clean, stable product that actually works in production, you need a clear step-by-step thinking process.

A great system design framework for frontend developers is called RADIO. It is an easy checklist of 5 steps:

• R - Requirements Explorations

• A - Architecture & High Level Design

• D - Data Model & Core Entities

• I - Interface (API)

• O - Optimization & Deep Dive

Each step prepares you for the next one. When you follow this order, you never feel lost, and your final product becomes solid and maintainable.

Let us walk through this framework from scratch using a real-world example: Building a Social Media Feed (like Facebook or Twitter).

1. Requirements (Understand What You Are Building)

Before writing any logic, you must be 100% sure about what you need to build. Never build on assumptions. Always ask questions to understand the goals and the limits.

We split requirements into two simple parts:

Functional Requirements

This is what the app actually does:

• Users can view a feed of posts with text and pictures.

• Users can write and publish a new post.

• Users can like and comment on posts.

• Users can scroll down continuously to load more posts.

Non-Functional Requirements

This is about system quality, speed, and reliability:

• The app must load fast and scroll smoothly without lag.

• It must work nicely on both phones and laptops.

• It must handle poor internet connections gracefully.

• It must handle hundreds of posts without crashing the browser memory.

2. Architecture (The Big Picture)

Now that you know the goals, step back and look at the whole system from above.

Architecture is not about small HTML tags or buttons. It is simply about big modules (boxes) and the flow of data between them (arrows).

We start by imagining the screen layout:

• A post creator at the top where users write.

• A post card that contains a user avatar, username, content, and a comments area.

Next, we connect these parts in a clean data flow:

• When a user writes a post or adds a comment, that input component talks to a central Controller.

• The Controller talks directly to the backend Server to save the data.

• When the Server replies, the Controller sends the fresh data into a central Store (our client cache).

• All view components (the post header, post body, and comment list) read from this Store and display the information.

This keeps our logic tidy. The visual components do not worry about the network, and the network layer does not care about how things look.

3. Data Model (What Data Exists and Where It Lives)

Every app is built around data. In this step, we identify our core entities, what fields they have, and where they live on the client side.

We divide all frontend data into two main sources:

Server Originated Data

This is data that lives inside a remote database. The server is the real owner of this data.

• Examples: User profile details, published posts, and comments.

• In the frontend, this data lives inside a central cache or store.

Client Only Data

This is data that starts on the user's device:

• Persisted data: Data the user writes locally that will soon be saved to the database (for example, the text inside a new post box before clicking send).

• Temporary data: Short-lived visual flags that we never save to a database (for example, showing a loading spinner, or keeping a dropdown open).

The Core Entities in Our Feed

• New Post Draft: Lives in the post composer component. It contains the text content and any selected media files.

• User: Lives in the central store. It contains id, username, and profile_pic.

• Post: Lives in the central store. It contains id, date, content, media, and the comments list.

Important Rules for Data

• Describe your entities clearly using TypeScript notation.

• Keep state minimal. Less state means fewer bugs.

• Never create a state variable for something you can calculate. For example, do not save totalComments in a state if you can just read comments.length.

4. Interface (API Definition)

An API is simply an interface or a contract that connects two layers together.

Many developers think an API is only between the frontend and the backend. But in frontend system design, an API can also be between two frontend components (Client to Client).

Every API needs three main things:

1. Functionality: What does it do?

2. Parameters (Input): What information does it take?

3. Response (Output): What does it return?

Real Example: Infinite Feed Pagination

You cannot load 10,000 posts all at once when a page opens. You fetch them in small batches (chunks) using pagination.

To do this, we use Cursor-based Pagination:

• Functionality: Get a batch of posts for the feed.

• Input Parameters: We send the batch size (for example: 10 posts) and a pointer called next_cursor. On the very first request, the cursor is empty.

• Output Response: The server sends back an array with 10 post objects, plus a new next_cursor token.

When the user scrolls near the bottom of their screen, the app catches this event, grabs that new cursor token, and sends another request to get the next 10 posts smoothly without duplicating anything.

At the component level, components communicate the same way: a parent component passes props down to a child component, and the child returns events (like an onLike click) back up to the parent.

5. Optimization (Making It Production-Ready)

This is the final step, where you turn your initial design into a fast, secure, production-grade application.

Here are the most important areas to think about:

Performance & Rendering

• Virtualization (Windowing): If a user scrolls through 500 posts, having 500 post items inside the browser DOM will make the page slow. With virtualization, we only render the few posts visible on the screen and discard the rest until the user scrolls back.

• Image Optimization: Load images only when they appear near the screen (lazy loading), and use modern lightweight formats like WebP.

• Optimistic UI: When a user clicks like, update the UI and increase the like counter immediately so the app feels instant. If the network call fails later, revert the counter and show a friendly message.

Network & Security

• Debouncing: When someone types in a search box, wait until they pause typing for 300 milliseconds before sending the network request.

• Security (XSS): Always clean and sanitize any text or comments written by users before displaying them, so nobody can inject harmful scripts.

Localization (i18n)

Make sure the app supports different languages and layouts easily. This means your UI can switch smoothly between Left-to-Right (English) and Right-to-Left (Arabic), and only loads the language translation file that the user needs.

Testing & Stability

• Use Error Boundaries so that if one single comment or post crashes, it does not bring down the entire website.

• Write tests for critical user flows to make sure core features never break.

Putting It All Together

Solving system design challenges is not about memorizing complex tools or showing off jargon. It is about having a clear, calm way of thinking.

Whenever you face a new feature at work or a question in an interview, do not rush into code. Take a breath, write down the word RADIO, and follow the steps one by one:

1. Understand the Requirements

2. Sketch the high-level Architecture

3. Define the Data Model

4. Specify the Interfaces

5. Think through Optimizations

   When you follow this framework, you will build applications that are clean, easy to maintain, and ready for real users.

To understand why these components exist and how they work together, we need to look back at how third-party authorization started, the architectural flaws that appeared, and the standardized solutions we use today.

1. The Historical Problem: The Password Anti-Pattern

In the early days of the web, photo-sharing platforms like Flickr became very popular. Soon, third-party services emerged to offer additional features, such as printing photos onto physical books, t-shirts, or mugs.

To access private photos from Flickr, these print services used a dangerous approach known as the Password Anti-Pattern:

Why this design was broken:

1 . Unrestricted Access : The third-party website received full administrative power over your account. It could view private messages, delete photos, or change your account details.

2 . Credential Storage : External services stored raw or reversibly encrypted passwords in their own databases. A single data breach on a small service exposed primary user credentials.

3 . No Granular Revocation : You could not revoke access for one service without changing your actual account password, which broke every other linked application.

2. The First Solution: OAuth 2.0 for Authorization

To solve the Flickr problem, the industry created OAuth 2.0.

OAuth 2.0 is an Authorization Framework. It allows a user to grant a third-party application limited access to their protected resources without sharing their password.

Instead of handing over credentials, the authorization server grants a scoped key called an Access Token:

• An Access Token acts like a hotel keycard: it opens specific doors (e.g., read photos only).

• It does not disclose the user's password.

• It can be revoked at any time from account security settings.

Crucial Concept: OAuth 2.0 answers the question: "What actions is this client allowed to perform?" (Authorization). It was never designed to prove: "Who is currently sitting in front of the screen?" (Authentication).

3. The Pseudo-Authentication Pitfall

As OAuth 2.0 gained widespread adoption, developers attempted to use it for single sign-on (SSO). The standard workaround looked like this:

1. Obtain an access_token from an identity provider like Facebook or Google.

2. Call a profile endpoint (e.g., GET /userinfo).

3. Assume that receiving profile data confirms successful user login.

This workaround caused security vulnerabilities:

• Opaque Tokens: The client application cannot reliably inspect an Access Token. It is an opaque string intended strictly for the Resource Server.

• The Confused Deputy Attack: A malicious website could obtain a valid Access Token from a user on its own platform, send that token to a different application, and falsely authenticate as that user. The receiving application had no cryptographic proof indicating which client the token was originally issued for.

• No Common Standard: Every provider returned user metadata using different key names and structures (user_id, id, sub, screen_name).

4. The Standard Solution: OpenID Connect (OIDC)

To address the limitations of using OAuth 2.0 for authentication, the industry introduced OpenID Connect (OIDC) as an identity layer on top of OAuth 2.0:

$$\text{OIDC} = \text{OAuth 2.0} + \text{Identity Layer}$$

OIDC adds three primary components:

1. The openid Scope

Adding openid to the requested scopes signals to the provider that this is an authentication request rather than a simple resource delegation.

2. The ID Token

Alongside the standard Access Token, the server issues an ID Token. The ID Token is a signed JSON Web Token (JWT) containing structured user assertions called Claims:

• sub (Subject): A stable, unique identifier for the user.

• iss (Issuer): The identity provider that generated the token.

• aud (Audience): The exact client_id of the application authorized to read the token. If the value does not match your application ID, you must reject it.

• exp (Expiration): The exact timestamp when the token expires.

3. Standardized Discovery

Providers expose a metadata document at a fixed endpoint:

/.well-known/openid-configuration

This endpoint allows applications to retrieve public signing keys (JWKS) and authorization endpoints automatically.

5. Architectural Building Blocks

Before tracing the execution sequence, review the core entities and credentials:

6. Execution Flow: The Authorization Code Grant

For web applications with an application server, the Authorization Code Flow provides a secure handoff between the untrusted browser and backend servers.

Why we do not send tokens directly to the browser:

• Web browsers run client-side extensions and maintain navigation histories that could expose sensitive tokens.

• A client browser cannot store a Client Secret without leaking it to end users.

• The backend-to-backend exchange (Step 6) takes place across an encrypted, isolated channel that the browser never intercepts.

7. Authentication vs. Authorization Summary

By keeping these responsibilities separate, modern web systems prevent credential leaks, protect sensitive API resources, and maintain clear security boundaries.

For a long time, people thought the frontend was just about styling buttons, moving pixels around, and calling a few APIs. But modern frontend applications are not just static pages anymore. They are complex applications running on real devices with real memory constraints and network limitations.

The truth is, you are already doing frontend architecture and system design every single day—even if you don't call it that yet.

Every time you choose how your app fetches and caches data, how you split your code, how you manage state across components, or how you optimize a heavy list so the browser doesn't freeze, you are making architectural and design choices.

The real problem happens when we mix both concepts together:

• An architectural mistake cannot be fixed by just writing a clever custom hook.

• A bad component design can still ruin a well-architected app.

To build solid web applications, we need to know the difference between the big picture and the day-to-day implementation details.

Before zooming into client-side engineering, let's step back and look at Software Architecture and Software Design in general. Understanding how they work at a high level makes it much easier to see where our frontend code fits into the bigger picture.

1. What is Software Architecture?

software architecture has multiple perspectives depending on how you look at the system. Rather than relying on a single rigid definition, industry leaders often describe it through four complementary viewpoints:

1. System Structure: Architecture is about the overall structure of a system—the major building blocks and how they relate to one another.

2. Early Critical Choices: Architecture represents the decisions you wish you could get right early in a project, because changing them later is costly and disruptive.

3. Core Priorities: Architecture is about the "important stuff"... whatever that is for your specific business and technical context.

4. Organizing for Quality: Architecture is the set of significant design decisions about how the software is organized to promote desired quality attributes (like scalability, reliability, maintainability, and security).

In summary: Software Architecture is the high-level skeleton and the hard-to-change foundational choices that shape everything else.

2. What is Software Design?

While architecture sets the boundaries, Software Design handles the detailed execution inside those boundaries. It is all about how specific modules, classes, and functions are written to solve concrete problems cleanly:

• The Scope: Low-level (individual modules, components, and functions).

• The Core Question: "How does this specific part work internally?"

• The Cost of Change: Decisions here are easy and cheap to refactor locally without breaking the whole platform.

• The Goal: Code maintainability, clean interfaces, and applying patterns like SOLID to write readable, reusable code

3. Architecture vs. Design: Side-by-Side

Why Do We Actually Need to Care About This Difference?

Distinguishing between architectural decisions and design decisions isn't just theory—it actively protects the engineering team, saves time, and shields the product from painful rewrites.

Here is why understanding the boundary matters:

• Calibrate Decision Weight: It helps the team understand exactly how seriously they should treat a choice before committing to it.

• Stop Underestimating Architecture: It prevents hasty, impulsive bets on fundamental system structures that take months of painful refactoring to undo.

• Stop Overestimating Design: It protects engineers from "analysis paralysis"—spending days debating tactical, local implementation details that can easily be changed later.

The Transition: From General Concepts to the Browser

Everything discussed so far applies to software engineering as a whole. Now, we shift our focus directly to the frontend.

In client-side engineering, these exact same rules govern our work—except the constraints are now the browser environment, user devices, network latency, and runtime memory.

4. Frontend Architecture (The Macro Blueprint)

Frontend Architecture is not about picking a styling framework or deciding folder structures. It focuses on the fundamental, hard-to-reverse decisions that dictate how the application is built, loaded, and served to the user.

Core Architectural Decisions:

• Rendering and Delivery Strategy: Determining whether routes use Client-Side Rendering (CSR), Server-Side Rendering (SSR), or Static Site Generation (SSG). This directly impacts Core Web Vitals, initial load performance, and infrastructure requirements.

• Application Topology: Choosing between a Modular Monolith, a Monorepo setup, or decentralized Micro-Frontends to support team scale.

• Network and Data Boundaries: Defining how data enters the client (REST, GraphQL, or WebSockets) and establishing global caching layers with Service Workers or HTTP cache headers.

• State Topology: Drawing clear boundaries between server cache, persistent storage (IndexedDB/LocalStorage), and runtime memory.

Key rule: If changing a decision later requires rewriting large portions of the codebase or changing deployment pipelines, it belongs to Frontend Architecture.

5. Frontend System Design (The Micro Execution)

While Frontend Architecture sets the global boundaries, Frontend System Design handles how you construct features and components inside those boundaries. It deals with the day-to-day tactical execution to make the UI fast, resilient, and easy to maintain.

Core Design Decisions:

• Component Composition: Designing reusable UI primitives and component contracts using patterns like Compound Components, Render Props, or Slots.

• State Encapsulation: Deciding where state lives locally (inside a component, custom hook, or context , Redux , Zustand , etc.) to prevent unnecessary re-renders across the tree.

• Logic Decoupling: Separating complex business logic and API calls from JSX templates by moving them into isolated Custom Hooks and utility functions (bast practice).

• Local Performance Optimizations: Applying techniques like virtualized lists for heavy datasets, memoization, debouncing search inputs and Abort controller, lazy Loading and dynamic component imports .

• Client Data & API Caching: Managing server-state lifecycles at the feature level—implementing caching, background revalidation (stale-while-revalidate), and query deduplication (e.g., using TanStack Query , RTQ or SWR) to avoid redundant network requests.

Key rule: If a decision can be refactored or improved locally within a feature without breaking the rest of the application, it belongs to Frontend System Design.

6. The Real-World Difference: A Tale of Two Decisions

To see how this distinction plays out in real projects, compare two common scenarios frontend teams face:

Scenario A: Switching Core Frameworks (Architecture)

Your team starts building an enterprise web application with React. Eight months into production, with hundreds of components, hooks, and routing logic already shipped, someone suggests switching to Angular or Vue.

Can you change this in a sprint? No. That choice requires tearing down and rewriting virtually the entire codebase from scratch. It impacts build tooling, developer hiring, libraries, and testing pipelines.

Because the cost of reversing it is monumental, choosing your core UI runtime is a Frontend Architecture decision.

Scenario B: Changing Styling Approaches (Design)

Now consider how you style that same application. You started using standard CSS Modules. As the design system scales, managing class names slows the team down, and you decide to adopt Tailwind CSS.

Do you have to stop shipping and rewrite the whole product? No. You can install Tailwind and begin using utility classes in new components immediately, while migrating older components gradually over time without breaking production.

Because this change is localized and can be refactored step-by-step without bringing down the system, choosing your styling pattern is a Frontend System Design decision.