Have you ever opened the Network tab in your browser’s Developer Tools and noticed a long list of HTTP headers?

You might have seen headers such as:

Content-Type: application/json
Authorization: Bearer eyJhbGciOi...
Accept: application/json
Cache-Control: no-cache
Set-Cookie: sessionId=abc123; HttpOnly; Secure

But what do these headers actually mean?

Why does the browser send some headers to the server, while the server sends others back to the browser?

And as a frontend developer, when should you use headers in your JavaScript or React applications?

Let’s understand these concepts from scratch.

In this article, we’ll cover:

• What HTTP headers are and why we need them.
• The difference between request headers and response headers.
• Important headers you’ll encounter in real applications.
• How to send and read headers using JavaScript.
• How headers work with authentication, caching, and CORS.
• How to inspect headers in browser Developer Tools.

By the end, you’ll be able to look at an HTTP request and understand what most of its important headers are doing.

1. First, Understand How HTTP Communication Works

Imagine you’re building an e-commerce application.

A user opens the product listing page, and your React application needs to fetch products from the backend.

Your frontend sends a request:

fetch("https://api.example.com/products");

The browser sends an HTTP request to the server.

The server processes the request and returns a response containing the requested data.

The flow looks like this:

       Browser / React Application
                  |
                  |
            HTTP Request
         URL + Headers + Body
                  |
                  v
             API Server
                  |
             Process Request
                  |
                  v
            HTTP Response
          Status + Headers
               + Body
                  |
                  v
       Browser / React Application
                  |
                  v
             Display Products

An HTTP message contains more than just the data you’re requesting.

It also contains information about the request or response, such as:

• The expected data format.
• The format of the data being sent.
• Authentication credentials.
• Caching instructions.
• Cookie information.
• Security policies.

This additional information is often communicated through HTTP headers.

2. What Are HTTP Headers?

HTTP headers are key-value pairs that provide metadata about an HTTP request or response.

For example:

Content-Type: application/json

Here:

• Content-Type is the header name.
• application/json is the header value.

Together, they tell the recipient that the message body contains JSON data.

Another example:

Authorization: Bearer my-access-token

This header carries an authentication credential that the server can validate.

A simple HTTP request might look like this:

GET /products HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer my-access-token

The request line identifies the method and requested resource. The headers provide additional information.

The server might respond with:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

[
  {
    "id": 1,
    "name": "Laptop",
    "price": 65000
  }
]

The response includes a status line, headers, and a body.

Important: These examples use the traditional HTTP/1.1 text representation to make the messages easy to read. HTTP/2 and HTTP/3 use different wire formats, but the header concepts remain largely the same.

3. Request Headers vs Response Headers

HTTP headers are commonly discussed in two categories.

Request headers

Request headers provide information about the request being sent by the client.

For example:

GET /products HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer my-access-token

The browser is requesting products and indicating that it accepts JSON responses.

The authorization header provides a credential for the server to validate.

Response headers

Response headers provide information about the response being returned by the server.

For example:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=300

The server is returning a successful response containing JSON, with a caching policy that allows the response to be stored and reused for up to 300 seconds, subject to the applicable HTTP caching rules.

Quick comparison

+----------------------+--------------------------+
| Request Headers      | Response Headers         |
+----------------------+--------------------------+
| Sent by the client   | Sent by the server       |
| Describe the request | Describe the response    |
| Accept               | Content-Type             |
| Authorization       | Set-Cookie               |
| Content-Type         | Cache-Control             |
| Origin               | Access-Control-Allow-*   |
+----------------------+--------------------------+

This is a simplified comparison. Some headers, such as Cache-Control and Content-Type, can appear in both requests and responses.

Now let’s explore the headers you’ll encounter most frequently.

4. Important HTTP Request Headers

4.1 Accept

The Accept header tells the server which response media types the client is willing to receive.

For example:

Accept: application/json

This tells the server that the client accepts JSON responses.

Another example:

Accept: text/html

This indicates that the client accepts HTML.

You can also specify multiple media types:

Accept: application/json, text/plain

Real-world use case: Your frontend communicates with an API that supports different response formats. The Accept header can help the server select an appropriate representation.

Remember the distinction:

• Accept describes the response format the client can accept.
• Content-Type describes the media type of the message body.

4.2 Content-Type

The Content-Type header describes the media type of the body being sent.

For example, suppose your React application sends JSON to the backend:

fetch("https://api.example.com/users", {
  method: "POST",
  headers: {
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    name: "Rohit",
    role: "Frontend Developer"
  })
});

The request body is:

{
  "name": "Rohit",
  "role": "Frontend Developer"
}

The Content-Type header tells the server how to interpret that body.

Other common media types include:

application/json
text/html
text/plain
application/x-www-form-urlencoded
multipart/form-data

One important detail: when uploading a FormData object using fetch, you should generally not manually set Content-Type: multipart/form-data. The browser needs to generate the boundary parameter and include it in the header.

4.3 Authorization

The Authorization header is used to provide credentials for authenticating a request.

For example:

Authorization: Bearer eyJhbGciOi...

In JavaScript:

const token = "your-access-token";

fetch("https://api.example.com/profile", {
  headers: {
    Authorization: `Bearer ${token}`
  }
});

The backend receives the token and validates it according to the application’s authentication system.

If the credential is invalid or missing, the server may reject the request.

A common distinction:

• Authentication: Who are you?
• Authorization: Are you allowed to perform this action?

The header carries credentials; the server must still validate them and enforce authorization rules.

Also, a Bearer token is only one possible authentication scheme. The Authorization header supports other schemes as well.

4.4 Cookie

The Cookie header sends cookies that the browser has selected for a request.

For example:

Cookie: sessionId=abc123

Browsers typically manage this header automatically when applicable cookies match the request’s domain, path, security, and other cookie rules.

With an HttpOnly cookie, JavaScript cannot read the cookie value through document.cookie, but the browser can still send it with eligible requests.

This is one reason cookie-based authentication needs careful configuration.

Important: In browser JavaScript, you generally cannot manually set the Cookie request header through fetch. The browser manages it.

4.5 Origin

The Origin header identifies the origin from which a request was initiated in applicable contexts.

An origin consists of:

scheme + hostname + port

For example:

Origin: https://myapp.example.com

This header is important for Cross-Origin Resource Sharing (CORS).

Suppose your frontend runs at:

https://myapp.example.com

And your backend runs at:

https://api.example.com

These are different origins, even though they share the same parent domain.

The browser may include an Origin header, and the server can use it as part of its CORS decision.

The frontend cannot freely set the Origin header manually using fetch; it is controlled by the browser in relevant requests.

4.6 User-Agent

The User-Agent header traditionally identifies information about the client software making a request.

For example, a request might include browser and operating-system details.

Servers have historically used this information for analytics, compatibility decisions, and debugging.

However, User-Agent information can be reduced or modified for privacy reasons, so it shouldn’t be treated as a reliable way to identify a user or establish trust.

4.7 Cache-Control

Cache-Control communicates caching directives.

For example, a request can include:

Cache-Control: no-cache

This indicates that a stored response should be revalidated before being reused when applicable.

It does not necessarily mean that the browser must avoid storing the response.

Another directive is:

Cache-Control: no-store

This tells caches not to store the request or response under the applicable caching rules.

The distinction matters:

• no-cache → stored responses generally need validation before reuse.
• no-store → don't store the message in caches.

The header can appear in both requests and responses, and the meaning depends on the directive and message context.

5. Important HTTP Response Headers

Now let’s explore headers that the server commonly sends back to the browser.

5.1 Content-Type

The response Content-Type tells the client what kind of data the response body contains.

For example:

HTTP/1.1 200 OK
Content-Type: application/json

The response body might be:

{
  "id": 101,
  "name": "Rohit"
}

For an HTML page, the server might send:

Content-Type: text/html; charset=utf-8

Why is this important?

The client needs to interpret the response correctly. The server should send the appropriate media type rather than relying on the browser to guess.

5.2 Set-Cookie

The Set-Cookie response header instructs the browser to create or update a cookie, subject to cookie rules.

For example:

Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax

Let’s understand the attributes:

• HttpOnly prevents ordinary JavaScript access to the cookie.
• Secure restricts cookie transmission to secure HTTPS connections.
• SameSite=Lax limits sending the cookie in certain cross-site contexts.

The browser stores the cookie when the applicable rules permit it.

On a later matching request, the browser may automatically send it:

Cookie: sessionId=abc123

This is commonly used in session-based authentication.

A key distinction:

Set-Cookie is a response header, while Cookie is a request header.

5.3 Cache-Control

Servers use Cache-Control to control how responses may be cached.

For example:

Cache-Control: public, max-age=3600

This allows eligible shared and private caches to store the response for up to 3,600 seconds, subject to other caching rules.

For sensitive responses, a server may instead use:

Cache-Control: no-store

This is useful when the response contains sensitive information that shouldn’t be stored in HTTP caches.

Caching policies should be selected according to the data and the application’s requirements.

5.4 Access-Control-Allow-Origin

This is one of the most important response headers for frontend developers.

The Access-Control-Allow-Origin header tells browsers which origin is permitted to access a response through CORS.

For example:

Access-Control-Allow-Origin: https://myapp.example.com

This allows the specified origin to access the response, subject to the rest of the CORS rules.

A server might return:

Access-Control-Allow-Origin: *

This allows any origin for requests where wildcard behavior is permitted. However, the wildcard cannot be used to authorize credentialed CORS access.

For credentialed cross-origin requests, the server generally needs to return a specific allowed origin and:

Access-Control-Allow-Credentials: true

The browser’s CORS rules determine whether frontend JavaScript can access the response.

Important: CORS is enforced by browsers. It is not a replacement for backend authentication or authorization.

5.5 Content-Security-Policy

The Content-Security-Policy header lets a server define restrictions on the resources a page can load and the script execution it permits.

For example:

Content-Security-Policy: default-src 'self'

This establishes a default policy allowing resources from the page’s own origin unless a more specific directive applies.

A real production policy often needs additional directives for scripts, styles, images, fonts, API connections, and other resources.

CSP can help reduce the impact of certain Cross-Site Scripting (XSS) attacks, but it isn’t a substitute for preventing injection vulnerabilities.

5.6 X-Content-Type-Options

A commonly used security header is:

X-Content-Type-Options: nosniff

This tells browsers not to perform certain MIME-type sniffing behaviors.

It helps ensure that browsers respect the declared media type in contexts where MIME sniffing could otherwise create security problems.

The server should still return the correct Content-Type.

5.7 Location

The Location header identifies a URL associated with a redirect or a newly created resource.

For example, a redirect response might look like:

HTTP/1.1 302 Found
Location: https://example.com/login

The client can use the provided URL as part of redirect handling.

Another example is a successful resource-creation response:

HTTP/1.1 201 Created
Location: /api/products/101

Here, the header identifies the newly created resource.

The exact behavior depends on the status code and client.

6. A Quick Reference: Common Headers

The following fixed-width table is designed to be pasted into Medium as a code block.

+------------------------------+-------------------------------+
| Header                       | Purpose                       |
+------------------------------+-------------------------------+
| Accept                       | Response types client accepts |
| Content-Type                 | Format of message body        |
| Authorization                | Authentication credentials    |
| Cookie                       | Sends applicable cookies      |
| Set-Cookie                   | Creates or updates cookies    |
| Origin                       | Identifies request origin     |
| Cache-Control                | Defines caching directives    |
| Access-Control-Allow-Origin  | Permitted CORS origin         |
| Access-Control-Allow-Methods | Allowed CORS methods          |
| Access-Control-Allow-Headers | Allowed CORS request headers  |
| Access-Control-Allow-Creds   | Allows credentialed CORS      |
| Content-Security-Policy      | Restricts resource loading    |
| X-Content-Type-Options       | Helps prevent MIME sniffing   |
| Location                     | Redirect or resource URL      |
+------------------------------+-------------------------------+

This is a quick reference, not a complete list of HTTP headers. Also, a header’s presence alone doesn’t guarantee a particular security outcome; the browser, server, and other protocol rules all matter.

7. How to Read Headers Using JavaScript

Let’s make the concepts practical.

Suppose we want to fetch products from an API and inspect the response.

async function getProducts() {
    const response = await fetch(
        "https://api.example.com/products", {
            headers: {
                Accept: "application/json"
            }
        }
    );

    console.log("Status:", response.status);
    console.log(
        "Content-Type:",
        response.headers.get("Content-Type")
    );
    console.log(
        "Cache-Control:",
        response.headers.get("Cache-Control")
    );
    const data = await response.json();
    console.log(data);
}

getProducts();

Let’s understand what’s happening.

First, we send a request with an Accept header:

headers: {
  Accept: "application/json"
}

Then, we inspect the response status:

response.status

This is a status code, not a header.

Finally, we read response headers:

response.headers.get("Content-Type")

The Headers interface lets us retrieve a response header by name.

One important limitation

When calling a cross-origin API, frontend JavaScript can read only response headers that are exposed to it under the applicable CORS rules.

For example, if the backend needs frontend JavaScript to read a custom response header:

X-Total-Count: 250

It may need to send:

Access-Control-Expose-Headers: X-Total-Count

Without the appropriate exposure, the header might appear in browser Developer Tools but still be unavailable through response.headers.get().

This is a common source of confusion when working with third-party APIs.

8. What is a CORS Preflight Request?

You may have seen requests with the HTTP method OPTIONS in the Network tab.

These can be CORS preflight requests.

A browser sends a preflight request when a cross-origin request needs permission checks under the CORS rules.

For example, your frontend might send a JSON POST request with an Authorization header.

The browser may first send:

OPTIONS /products HTTP/1.1
Origin: https://myapp.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: authorization, content-type

The server may respond with:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://myapp.example.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Type

The browser checks whether the response satisfies the preflight requirements.

If the checks pass, it can proceed with the actual request. Otherwise, the browser blocks the cross-origin request from proceeding as requested.

Not every cross-origin request requires a preflight. Some requests qualify as CORS-safelisted requests and can be sent without one.

Understanding preflight requests is especially useful when integrating React applications with APIs hosted on different origins.

9. How to Inspect Headers in Chrome Developer Tools

As a frontend developer, you don’t need to memorize every header. You should know how to inspect them.

Follow these steps:

1. Open your application in Chrome.
2. Right-click the page and select Inspect.
3. Open the Network tab.
4. Reload the page.
5. Click an API request.
6. Open the Headers section.

You’ll typically see:

General

• Request URL
• Request method
• Status code

Request Headers

• Accept
• Authorization, when present
• Content-Type, when applicable
• Origin, when applicable
• Cookie, when applicable

Response Headers

• Content-Type
• Cache-Control
• Set-Cookie, when present
• Access-Control-Allow-Origin, when present

Some headers may be hidden, displayed differently, or unavailable to JavaScript due to browser security rules.

A practical debugging example

Suppose your React application sends a request, but the API returns a 401 Unauthorized response.

Inspect the request and check:

• Was the expected authorization credential sent?
• Is the token expired or invalid?
• Does the backend expect a different authentication scheme?
• Does the response contain a WWW-Authenticate header with additional information?

If the request returns a 415 Unsupported Media Type, inspect the request's Content-Type and verify that the backend accepts the format you're sending.

If JavaScript reports a CORS error, inspect the relevant request and response headers, including any preflight request.

The Network tab is one of the most useful tools for debugging frontend-backend communication.

10. Common Mistakes to Avoid

Mistake 1: Confusing Accept and Content-Type

Remember:

Accept
  → What response format can I accept?

Content-Type
  → What format is this message body?

Mistake 2: Assuming CORS is authentication

CORS controls whether browser JavaScript can access cross-origin responses under certain conditions.

It doesn’t determine whether a user is authenticated or authorized to access a protected resource.

The backend must enforce authentication and authorization independently.

Mistake 3: Assuming no-cache means no storage

Cache-Control: no-cache generally requires validation before reuse.

Cache-Control: no-store tells caches not to store the message.

They are not interchangeable.

Mistake 4: Trying to set restricted headers from frontend JavaScript

Browsers control certain request headers, such as Cookie and Origin, in relevant contexts.

You can’t freely override every HTTP header using fetch.

Mistake 5: Assuming every response header is readable by JavaScript

Cross-origin response headers may need to be explicitly exposed through CORS.

A header visible in Developer Tools isn’t necessarily accessible through the Fetch API.

Mistake 6: Treating headers as a replacement for security controls

Sending an Authorization header doesn't make an endpoint secure by itself.

The server must validate credentials, enforce permissions, validate input, and apply appropriate security controls.

Conclusion

HTTP headers are an essential part of browser-server communication.

They provide metadata that helps clients and servers understand how to interpret messages, authenticate requests, manage caching, handle cookies, and apply security policies.

In this article, we learned that:

• Request headers provide information about outgoing requests.
• Response headers provide information about server responses.
• Accept describes the response formats the client can accept.
• Content-Type describes the format of a message body.
• Authorization carries authentication credentials.
• Cookie and Set-Cookie support browser cookie handling.
• Cache-Control defines caching behavior.
• CORS headers control browser access to cross-origin responses.
• Security headers such as CSP help enforce browser security policies.
• Chrome Developer Tools makes it easy to inspect and debug headers.

The key takeaway is simple:

Don’t treat HTTP headers as random key-value pairs. Understand what each header communicates, who sends it, and how the browser or server uses it.

Once you understand these fundamentals, debugging API requests and working with authentication, caching, and CORS becomes much easier.

What’s Next?

Now that you understand HTTP request and response headers, here are some topics worth exploring next:

• HTTP Status Codes: Understand 200, 201, 301, 400, 401, 403, 404, 409, and 500.
• CORS Explained: Learn how browsers enforce cross-origin access and why preflight requests occur.
• Cookies vs localStorage vs Session IDs: Understand the trade-offs of browser authentication storage.
• HTTP Caching: Explore ETag, Last-Modified, Cache-Control, and conditional requests.
• HTTP vs HTTPS: Understand TLS, certificates, and how secure communication works.
• API Debugging in Chrome DevTools: Learn to investigate network failures, request payloads, headers, and response timing.

Happy coding! ✌️

If you’ve ever worked with file uploads, downloads, or previews in a web application, you’ve probably come across the term Blob. At first glance, it can feel abstract and confusing — but once you understand it, a lot of file-handling logic starts to make perfect sense.

This blog breaks down what a Blob is, why it matters, and how you’ll use it in real-world frontend development.

What is a Blob?

Blob stands for Binary Large Object.

In JavaScript, a Blob is simply a container for raw binary data. That data could represent:

• an image
• a PDF
• a video
• or even plain text

Think of it like this:

A Blob is a box that holds file data in memory — but it’s not necessarily a file yet.

📦 Blob vs File (Important Difference)

A common point of confusion is the difference between a Blob and a File.

Feature                | Blob | File
--------------------- | ---- | ----
Stores binary data    | ✅   | ✅
Has file name         | ❌   | ✅
Has metadata          | ❌   | ✅
Used in file inputs   | ❌   | ✅

👉 In simple terms:

File = Blob + filename + metadata

You can convert a Blob into a File like this:

const blob = new Blob(["Hello world"], { type: "text/plain" });
const file = new File([blob], "hello.txt");

🔄 How Blob Fits into Real Workflows

Most real-world scenarios involving files follow a pattern like this:

fetch → blob → (optional: file) → upload / preview / download

Let’s break that into actual use cases.

📥 1. Downloading Files

You can fetch a file from a URL, convert it into a Blob, and trigger a download.

async function downloadFile(fileUrl) {
  const response = await fetch(fileUrl);
  const blob = await response.blob();
  const url = URL.createObjectURL(blob);
  const a = document.createElement("a");

  a.href = url;
  a.download = "file";
  a.click();
  URL.revokeObjectURL(url);
}

📌 Use cases:

• downloading reports
• saving images
• exporting documents

📤 2. Uploading Files

From file input:

const formData = new FormData();
formData.append("file", file);

fetch("/api/upload", {
  method: "POST",
  body: formData,
});

From a URL (very common in integrations):

const response = await fetch(fileUrl);
const blob = await response.blob();

const file = new File([blob], "file-from-url", {
  type: blob.type,
});
const formData = new FormData();
formData.append("file", file);

📌 This is useful when:

• your app receives file URLs from another API
• you need to re-upload files to your own backend

👁️ 3. Previewing Files

You can convert a Blob into a temporary URL and display it in the browser.

const url = URL.createObjectURL(blob);
image.src = url;

📌 Use cases:

• image preview before upload
• viewing PDFs
• displaying downloaded content

🧾 4. Creating Files on the Fly

You can generate files dynamically in the browser using Blob.

Example: Create a text file

const blob = new Blob(["Hello from Blob!"], {
  type: "text/plain",
});

const url = URL.createObjectURL(blob);
const a = document.createElement("a");
a.href = url;
a.download = "sample.txt";
a.click();
URL.revokeObjectURL(url);

📌 Use cases:

• exporting CSV or Excel
• downloading JSON data
• generating reports on the client side

Important Things to Know

1. Blob is immutable

Once created, you can’t modify a Blob. You must create a new one if needed.

2. Always check Blob size (debugging)

console.log(blob.size);

If size === 0, something is wrong (often a CORS issue).

3. CORS can block Blob data

If you fetch a file from another domain:

• the server must allow CORS
• otherwise the Blob may be empty or the request may fail

4. Memory matters

Large files = large blobs = high memory usage.

👉 Avoid handling very large files in the browser when possible.

5. Clean up object URLs

Always release memory after using:

URL.revokeObjectURL(url);

How Much Should a Frontend Developer Know?

Must Know

• What a Blob is (binary data container)
• How to get it using fetch
• How to convert Blob → File
• How to use it with FormData
• How to preview using URL.createObjectURL

Good to Know

• MIME types (image/png, application/pdf)
• Debugging with blob.size
• File downloads

Advanced (Optional)

• Streams and chunk uploads
• Media processing
• Performance optimization

🚀 Conclusion

A Blob is one of those concepts that seems abstract at first but becomes incredibly useful once you start working with files.

Think of Blob as raw file data in memory that you can transform into anything — a downloadable file, an upload payload, or a preview in the browser.

If you’re building modern web apps, especially ones involving uploads, reports, or media, understanding Blob is not optional — it’s essential.

By practicing simple examples like downloading, uploading, previewing, and creating files, you’ll quickly become comfortable with it — and start using it naturally in your projects.

Happy coding! ✌️

Imagine you’re building an e-commerce application.

Your product listing page fetches products from an API. When the user opens a product details page and then returns to the listing page, should the application fetch the same products again?

What happens when the user adds a new product, updates an existing record, or deletes an item? How do you keep the UI synchronized with the server?

You could manage all of this manually using useEffect, useState, and fetch(). But as your application grows, you'll need to handle loading states, errors, caching, duplicate requests, refetching, and keeping data consistent across components.

This is where RTK Query comes in.

RTK Query is a powerful data-fetching and caching tool included in Redux Toolkit. It simplifies communication with APIs and helps you manage server data without writing repetitive fetching logic.

In this article, we’ll understand RTK Query from scratch, build a small React application, learn how queries and mutations work, and explore caching, tags, and cache invalidation.

If you’ve already read my previous article on Redux Toolkit, you’ll find that RTK Query builds on many of the same concepts.

1. First, Understand the Problem

Let’s start with a common React pattern.

Suppose you want to fetch a list of products from an API.

Without RTK Query, you might write something like this:

import { useEffect, useState } from "react";

function Products() {
  const [products, setProducts] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    async function fetchProducts() {
      try {
        const response = await fetch(
          "https://dummyjson.com/products"
        );
        if (!response.ok) {
          throw new Error("Failed to fetch products");
        }
        const data = await response.json();
        setProducts(data.products);
      } catch (err) {
        setError(err.message);
      } finally {
        setLoading(false);
      }
    }
    fetchProducts();
  }, []);

  if (loading) return <p>Loading products...</p>;

  if (error) return <p>{error}</p>;

  return (
    <div>
      {products.map((product) => (
        <p key={product.id}>{product.title}</p>
      ))}
    </div>
  );
}

export default Products;

This works perfectly well for a simple example.

But imagine using the same approach across dozens of components.

Each component might need to manage:

• Loading states.
• Error handling.
• API requests.
• Response data.
• Caching.
• Refetching.
• Duplicate requests.
• Synchronization after creating, updating, or deleting data.

You can build reusable hooks and utilities to solve these problems yourself, but you’ll need to maintain that infrastructure.

The real challenge isn’t making an API request. It’s managing server data consistently across an application.

RTK Query helps solve this problem.

2. What Is RTK Query?

RTK Query is a data-fetching and caching solution that comes with Redux Toolkit.

It provides utilities to define API endpoints, execute requests, cache responses, manage request status, and refresh data when necessary.

Instead of writing repetitive API logic inside every component, you define your API endpoints in one place and use generated React hooks to interact with them.

Conceptually, the architecture looks like this:

             React Components
                    |
                    v
               RTK Query
                    |
          +---------+---------+
          |                   |
        Queries            Mutations
          |                   |
          v                   v
      Fetch Data          Change Data
          |                   |
          +---------+---------+
                    |
                    v
                API Server
                    |
                    v
             Cached API Data
                    |
                    v
             Updated React UI

For example, you might define these operations:

getProducts     → Fetch all products
getProductById  → Fetch one product
addProduct      → Create a product
updateProduct   → Update a product
deleteProduct   → Delete a product

RTK Query helps manage the lifecycle of these operations.

What does RTK Query provide?

• Automatically generated React hooks.
• Loading, success, and error states.
• Caching of query results.
• Deduplication of equivalent in-flight queries.
• Refetching when configured conditions are met.
• Cache invalidation after mutations.
• Request cancellation and lifecycle management.
• Integration with the Redux store.

The key idea is simple:

You describe what data your application needs and how to fetch or modify it. RTK Query handles much of the repetitive API state management for you.

3. Query vs Mutation

Before writing code, you need to understand two important concepts: queries and mutations.

3.1 What is a Query?

A query is used to retrieve data from an API.

For example:

GET /products
GET /products/1
GET /users
GET /orders

In RTK Query, we define a query using builder.query().

For example:

getProducts: builder.query({
  query: () => "/products"
})

RTK Query uses this endpoint definition to make the request and manage its result.

When you use the generated hook, it provides information such as:

• data — The latest available result.
• isLoading — The initial request is loading and no data is available yet.
• isFetching — A request is currently in progress, including background refetches.
• error — Information about a failed request, when present.

Queries are generally used for reading data.

3.2 What is a Mutation?

A mutation is used for operations that create, update, or delete data.

For example:

POST   /products/add
PUT    /products/1
PATCH  /products/1
DELETE /products/1

In RTK Query, we define a mutation using builder.mutation().

For example:

addProduct: builder.mutation({
  query: (newProduct) => ({
    url: "/products/add",
    method: "POST",
    body: newProduct
  })
})

A mutation generates a hook that you can call when a user performs an action.

For example, clicking an Add Product button can trigger the mutation.

Query vs Mutation

+----------------------+---------------------------+
| Query                | Mutation                  |
+----------------------+---------------------------+
| Reads data           | Changes data              |
| builder.query()      | builder.mutation()        |
| Often runs on mount  | Usually triggered manually|
| Results are cached   | Results aren't query cache|
| Can refetch           | Can invalidate query cache|
+----------------------+---------------------------+

This is a simplified comparison. Queries can also be triggered manually using lazy query hooks, and mutation results can be retained in their own mutation state. Mutations commonly trigger refetching by invalidating related query cache entries.

4. Build Your First RTK Query Application

Let’s build a small product listing application using React and RTK Query.

We’ll use the DummyJSON API:

https://dummyjson.com/products

Our application will:

1. Fetch products.
2. Display a loading message.
3. Handle errors.
4. Display the product list.
5. Add a product using a mutation.
6. Demonstrate cache invalidation.

We’ll use Vite for the React project.

Step 1: Create the React project

Run the following commands:

npm create vite@latest rtk-query-demo -- --template react
cd rtk-query-demo
npm install
npm install @reduxjs/toolkit react-redux
npm run dev

We install two important packages:

@reduxjs/toolkit — Provides RTK Query and Redux Toolkit utilities.

react-redux — Connects React components to the Redux store.

Now let’s build the application.

Step 2: Create the API slice

Create a file named src/services/productsApi.js.

import { createApi, fetchBaseQuery } from "@reduxjs/toolkit/query/react";

export const productsApi = createApi({
  reducerPath: "productsApi",
  baseQuery: fetchBaseQuery({
    baseUrl: "https://dummyjson.com"
  }),
  tagTypes: ["Product"],
  endpoints: (builder) => ({
    getProducts: builder.query({
      query: () => "/products",
      providesTags: (result) =>
        result
          ? [
              ...result.products.map(({ id }) => ({
                type: "Product",
                id
              })),
              { type: "Product", id: "LIST" }
            ]
          : [{ type: "Product", id: "LIST" }]
    }),
    addProduct: builder.mutation({
      query: (newProduct) => ({
        url: "/products/add",
        method: "POST",
        body: newProduct
      }),
      invalidatesTags: [
        { type: "Product", id: "LIST" }
      ]
    })
  })
});

export const {
  useGetProductsQuery,
  useAddProductMutation
} = productsApi;

This is the heart of our RTK Query implementation.

Let’s understand each part.

What is createApi()?

createApi({
  reducerPath: "productsApi",
  baseQuery: fetchBaseQuery({
    baseUrl: "https://dummyjson.com"
  }),
  endpoints: (builder) => ({})
});

createApi() creates an API service that defines how requests are made, how query results are cached, and how endpoints behave.

It also generates hooks for the endpoints you define.

What is reducerPath?

reducerPath: "productsApi"

This specifies the key under which RTK Query’s reducer will be registered in the Redux store.

It also identifies the API slice’s state namespace.

What is fetchBaseQuery()?

baseQuery: fetchBaseQuery({
  baseUrl: "https://dummyjson.com"
})

fetchBaseQuery() is a lightweight wrapper around the browser's Fetch API.

It simplifies common request handling, including constructing URLs and processing responses.

Because we configured a base URL, we can write:

query: () => "/products"

instead of repeating the entire URL in every endpoint.

What are endpoints?

The endpoints property defines the API operations available to our application.

In this example, we define two endpoints:

• getProducts — Fetches the product list.
• addProduct — Sends a request to create a product.

RTK Query generates React hooks from these definitions.

For example:

useGetProductsQuery
useAddProductMutation

These hooks let React components interact with the API.

5. Configure the Redux Store

Creating the API slice isn’t enough. We also need to register its reducer and middleware in the Redux store.

Create src/app/store.js.

import { configureStore } from "@reduxjs/toolkit";
import { productsApi } from "../services/productsApi";

export const store = configureStore({
  reducer: {
    [productsApi.reducerPath]: productsApi.reducer
  },
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware().concat(
      productsApi.middleware
    )
});

Let’s understand the two important pieces.

Registering the API reducer

[productsApi.reducerPath]: productsApi.reducer

This registers the API slice’s reducer under its configured state key.

RTK Query uses this state to maintain query results, request status, and cache information.

Registering the API middleware

middleware: (getDefaultMiddleware) =>
  getDefaultMiddleware().concat(
    productsApi.middleware
  )

The middleware handles important RTK Query behavior, including query subscriptions, cache lifetimes, request lifecycle management, and invalidation.

Both the reducer and middleware are required for the standard RTK Query setup.

6. Provide the Store to React

Open src/main.jsx and update it:

import { StrictMode } from "react";
import { createRoot } from "react-dom/client";
import { Provider } from "react-redux";
import App from "./App";
import { store } from "./app/store";

createRoot(document.getElementById("root")).render(
  <StrictMode>
    <Provider store={store}>
      <App />
    </Provider>
  </StrictMode>
);

The Redux Provider makes the store available to React components.

Since RTK Query is integrated into that store, its generated hooks can now be used in our components.

7. Fetch Products Using useGetProductsQuery()

Now create or update src/App.jsx.

import {
  useGetProductsQuery,
  useAddProductMutation
} from "./services/productsApi";

function App() {
  const { data, error, isLoading, isFetching } = useGetProductsQuery();
  const [ addProduct, { isLoading: isAdding } ] = useAddProductMutation();

  const handleAddProduct = async () => {
    try {
      await addProduct({
        title: "New Keyboard",
        price: 2500
      }).unwrap();
      alert("Product added successfully!");
    } catch (error) {
      alert("Failed to add product");
    }
  };

  if (isLoading) {
    return <p>Loading products...</p>;
  }

  if (error) {
    return <p>Failed to load products.</p>;
  }

  return (
    <div>
      <h1>RTK Query Demo</h1>
      {isFetching && <p>Refreshing products...</p>}
      <button
        onClick={handleAddProduct}
        disabled={isAdding}
      >
        {isAdding ? "Adding..." : "Add Product"}
      </button>
      <h2>Products</h2>
      {data.products.map((product) => (
        <div key={product.id}>
          <h3>{product.title}</h3>
          <p>Price: ${product.price}</p>
        </div>
      ))}
    </div>
  );
}

export default App;

Let’s break this down.

Reading data

const {
  data,
  error,
  isLoading,
  isFetching
} = useGetProductsQuery();

Calling useGetProductsQuery() subscribes the component to the query identified by the endpoint and its arguments.

Because our endpoint doesn’t require an argument, we call the hook without one.

RTK Query starts the request when needed and provides the current query state.

Understanding isLoading and isFetching

These properties are related, but they aren’t identical.

isLoading

Indicates the initial loading state when the query has no data available yet.

isFetching

Indicates that a request is in progress. This can include background refetches when previous data is already available.

For example, you might use isLoading to display a full-page loading indicator and isFetching to display a smaller refreshing message.

Adding a product

await addProduct({
  title: "New Keyboard",
  price: 2500
}).unwrap();

The generated mutation hook provides a trigger function.

Calling addProduct() starts the mutation request.

The .unwrap() method lets us handle the fulfilled result or catch a rejected request using normal try...catch syntax.

One important note: DummyJSON simulates product creation. It returns a sample response but does not permanently save the new product on its server. This example demonstrates the request and mutation workflow, not persistent product creation.

8. How Does RTK Query Caching Work?

Caching is one of the most useful RTK Query features.

Imagine a user opens the product listing page and RTK Query fetches the products.

The results are stored in the Redux store’s API cache.

Later, the user navigates to another page and then returns to the product listing page.

If the same query is still cached and no refetch condition requires a new request, RTK Query can reuse the cached data instead of immediately fetching it again.

Conceptually:

User opens Products Page
          |
          v
RTK Query requests products
          |
          v
Server returns product list
          |
          v
RTK Query caches the result
          |
          v
User navigates away
          |
          v
User returns to Products Page
          |
          v
Cached data may be reused

The exact behavior depends on the query arguments, subscription state, cache lifetime, and refetch configuration.

What identifies a cached query?

RTK Query identifies query cache entries using the endpoint name and its serialized arguments.

For example:

useGetProductByIdQuery(1)

and:

useGetProductByIdQuery(2)

represent different queries because their arguments differ.

But two components using:

useGetProductByIdQuery(1)

can share the same cache entry.

This helps avoid unnecessary duplicate requests and lets multiple components use the same cached result.

How long does cached data stay?

By default, RTK Query keeps unused query data cached for 60 seconds after the last subscriber unsubscribes.

This behavior is controlled by keepUnusedDataFor, which can be configured globally or per endpoint.

For example:

getProducts: builder.query({
  query: () => "/products",
  keepUnusedDataFor: 120
})

This keeps unused cached data for up to 120 seconds after the last subscription ends.

Remember that cache lifetime and data freshness are different concepts. Keeping data in the cache doesn’t automatically mean it will be refetched every time the component mounts.

9. What Are providesTags and invalidatesTags?

Now let’s explore one of RTK Query’s most important features: cache invalidation.

Imagine the product listing page has already fetched and cached the products.

The user then adds a product, updates an existing product, or deletes a product.

The cached list might no longer represent the current server data.

How do we tell RTK Query which cached queries should be refreshed?

This is where tags help.

What is providesTags?

A query can use providesTags to identify the data represented by its cached result.

For example:

getProducts: builder.query({
  query: () => "/products",
  providesTags: [
      { type: "Product", id: "LIST" }
    ]
})

This indicates that the query provides the Product list tag.

Tags are metadata used by RTK Query to track relationships between queries and mutations.

What is invalidatesTags?

A mutation can use invalidatesTags to indicate that some cached data may now be stale.

For example:

addProduct: builder.mutation({
  query: (newProduct) => ({
    url: "/products/add",
    method: "POST",
    body: newProduct
  }),
  invalidatesTags: [
      { type: "Product", id: "LIST" }
    ]
})

When the mutation succeeds, RTK Query invalidates the specified tag.

If an active query provides that tag, RTK Query will normally refetch it so the component can receive updated data.

The flow looks like this:

Product List Query
        |
        v
Provides Product LIST Tag
        |
        v
User Adds a Product
        |
        v
Mutation Succeeds
        |
        v
Product LIST Tag Invalidated
        |
        v
Active Product Query Refetches
        |
        v
UI Receives Updated Data

This is the relationship between providesTags and invalidatesTags.

providesTags connects cached queries to data categories. invalidatesTags tells RTK Query which cached data may need refreshing after a mutation.

A note about our DummyJSON example

Because DummyJSON doesn’t persist the newly created product, refetching its product list won’t necessarily show the simulated new product.

In a real backend that saves the product, the refetched query can return the updated list.

This distinction is important: cache invalidation triggers data synchronization, but it cannot make a backend persist data that it never saved.

10. How Does RTK Query Differ from createAsyncThunk()?

If you’ve read my Redux Toolkit article, you might remember createAsyncThunk().

Both createAsyncThunk() and RTK Query support asynchronous operations, but they solve different problems.

createAsyncThunk()

createAsyncThunk() helps you manage asynchronous workflows.

For example, you can fetch products, dispatch pending/fulfilled/rejected actions, and store the result in a slice.

However, you generally need to implement the surrounding state management yourself, including caching and synchronization when required.

RTK Query

RTK Query is designed specifically for data fetching and caching.

It provides endpoint definitions, generated hooks, query caching, subscription management, and cache invalidation.

Here’s a quick comparison:

+----------------------+-------------------------+
| Feature              | createAsyncThunk        |
+----------------------+-------------------------+
| Main purpose         | Async workflows         |
| Generated API hooks  | No                      |
| Query caching        | Manual implementation   |
| Cache invalidation   | Manual implementation   |
| Request status       | Lifecycle actions       |
| State integration    | Usually slice reducers  |
+----------------------+-------------------------+

+----------------------+-------------------------+
| Feature              | RTK Query               |
+----------------------+-------------------------+
| Main purpose         | API data management     |
| Generated API hooks  | Yes, with React entry   |
| Query caching        | Built in                |
| Cache invalidation   | Tag-based               |
| Request status       | Managed by API slice    |
| State integration    | Built into Redux store  |
+----------------------+-------------------------+

Use createAsyncThunk() when you need a custom asynchronous workflow that doesn't fit naturally into query caching.

Use RTK Query when you’re managing API data that benefits from fetching, caching, refetching, and synchronization.

You can also use both in the same application when their responsibilities are clearly separated.

11. Useful RTK Query Features to Know

Once you’re comfortable with basic queries and mutations, these features are worth exploring.

Refetch on mount or argument change

You can configure a query to refetch when a component subscribes or its arguments change:

useGetProductsQuery(undefined, {
  refetchOnMountOrArgChange: true
});

This tells RTK Query to refetch when the hook mounts or its argument changes, subject to its query subscription behavior.

You can also use a numeric value to refetch when cached data is older than a specified number of seconds.

Refetch on focus

useGetProductsQuery(undefined, {
  refetchOnFocus: true
});

This enables refetching when the browser window regains focus.

To use focus and reconnect refetching, enable listener support once in your application entry point:

import { setupListeners } from "@reduxjs/toolkit/query";

setupListeners(store.dispatch);

Refetch on reconnect

useGetProductsQuery(undefined, {
  refetchOnReconnect: true
});

This enables refetching when the browser regains network connectivity, with listener support configured.

Polling

For data that needs periodic updates, RTK Query supports polling:

useGetProductsQuery(undefined, {
  pollingInterval: 10000
});

This requests fresh data every 10 seconds while the subscription is active, subject to the configured polling behavior.

Polling can be useful for dashboards and status pages, but choose an interval appropriate for the server and application.

For true real-time communication, technologies such as WebSockets or Server-Sent Events may be more suitable.

12. Common Mistakes Beginners Should Avoid

Mistake 1: Forgetting to register the API middleware

Registering only the API reducer isn’t enough.

For the standard RTK Query setup, you need both:

[productsApi.reducerPath]: productsApi.reducer

and:

productsApi.middleware

Mistake 2: Confusing queries and mutations

Queries are primarily for retrieving data, while mutations represent operations that change server data.

Choosing the appropriate endpoint type makes the API behavior easier to understand.

Mistake 3: Expecting cache invalidation to modify the server

Invalidating a tag doesn’t create or update server data.

It marks related cached data as potentially stale and can trigger refetching.

The backend remains responsible for storing and returning the actual data.

Mistake 4: Treating caching as permanent storage

RTK Query’s cache is designed to manage API data during the application’s runtime.

It doesn’t automatically provide permanent storage across browser restarts.

Mistake 5: Refetching everything after every mutation

You don’t always need to invalidate every tag.

Use specific tags when possible so that only the relevant cached queries are refreshed.

For example, updating one product can invalidate that product’s individual tag instead of invalidating the entire product list.

Mistake 6: Forgetting error handling

API requests can fail because of network problems, server errors, invalid credentials, or unexpected responses.

Always design appropriate loading, error, and retry behavior for your application.

Conclusion

RTK Query simplifies API data management in Redux Toolkit applications.

We’ve learned that:

• RTK Query is designed for data fetching and caching.
• createApi() defines API endpoints and generates hooks.
• fetchBaseQuery() provides a lightweight Fetch API wrapper.
• Queries retrieve data.
• Mutations create, update, or delete data.
• The API reducer and middleware must be registered in the Redux store.
• RTK Query caches query results and can share them across components.
• providesTags and invalidatesTags help synchronize cached data after mutations.
• createAsyncThunk() and RTK Query solve different asynchronous data-management problems.

The key takeaway is simple:

RTK Query helps you manage server data without manually rebuilding fetching, caching, loading-state, and cache-invalidation logic for every API endpoint.

Once you understand these concepts, you can use RTK Query to build cleaner and more maintainable React applications.

What’s Next?

Now that you understand RTK Query, here are some topics worth exploring next:

• RTK Query with TypeScript: Type your API responses, query arguments, and mutations.
• Cache Invalidation in Depth: Learn how to invalidate individual records and lists.
• RTK Query Pagination: Fetch data in pages or implement infinite scrolling.
• Optimistic Updates: Update the UI before the server confirms a mutation.
• RTK Query Authentication: Attach access tokens to requests and handle authentication errors.
• RTK Query vs React Query: Compare two popular server-state management solutions.

Happy coding! ✌️

Imagine you’re building an e-commerce application.

The application has a product listing page, a shopping cart, a navigation bar showing the cart count, and a checkout page.

When a user adds a product to the cart, the cart page should update. The navigation bar should also display the updated number of items, and the checkout page should have access to the cart information.

How do you share this data across different components without passing props through multiple layers?

React provides Context API and other state management techniques, but as an application grows, managing shared state can become more complicated.

This is where Redux Toolkit comes in.

Redux Toolkit provides a structured way to manage shared application state in React. It simplifies Redux by providing utilities that reduce boilerplate code and make state updates easier to organize.

In this article, we’ll understand Redux Toolkit from scratch, learn its core concepts, build a working counter application, and then explore how the same approach can be used in a real-world shopping cart.

No prior knowledge of Redux is required.

1. First, Understand the Problem

Let’s start with a simple React application.

Imagine we have the following component structure:

App
 |
 +-- Navbar
 |     |
 |     +-- CartCount
 |
 +-- ProductList
 |     |
 |     +-- ProductCard
 |
 +-- CartPage

Suppose the user clicks the Add to Cart button inside ProductCard.

We want three things to happen:

• The product should be added to the cart.
• The cart count in the navbar should increase.
• The cart page should display the updated cart contents.

Where should we store the cart data?

One option is to maintain the state inside a parent component and pass it down through props.

App
 |
 |-- cart state
 |
 +-- Navbar
 |     |
 |     +-- CartCount (cart count)
 |
 +-- ProductList
 |     |
 |     +-- ProductCard (add to cart)
 |
 +-- CartPage (cart items)

This works, and for small applications, it can be a perfectly reasonable approach.

However, as more components need access to the same data, you may end up passing props through components that don’t actually need that data.

This is commonly called prop drilling.

Another option is React Context, which can help share data without passing props through every intermediate component.

But as an application grows, you may also want a predictable way to organize state updates, manage complex interactions, and inspect how the state changes over time.

Redux Toolkit provides a structured approach to these problems.

2. What Is Redux Toolkit?

Redux Toolkit (RTK) is the official recommended way to write Redux logic.

Redux is a state management library that maintains application state in a centralized store. Redux Toolkit simplifies the process of creating that store, defining state updates, and dispatching actions.

Instead of every component maintaining its own copy of shared data, components can read from a common store.

Conceptually, the architecture looks like this:

React Components
                    |
          +---------+---------+
          |                   |
      Read State          Dispatch Action
      useSelector         useDispatch
          |                   |
          v                   v
             Redux Store
                  |
                  v
          Reducer Processes
               Action
                  |
                  v
            Updated State
                  |
                  v
         React UI Re-renders

Let’s understand the flow in simple terms.

1. A component reads the state it needs from the Redux store.
2. A user performs an action, such as clicking a button.
3. The component dispatches an action.
4. A reducer determines how the state should change.
5. The store updates its state.
6. Components subscribed to the relevant state update and React renders the new UI.

The key idea is that shared application state lives in one central place, and updates follow a predictable pattern.

Redux Toolkit doesn’t replace React’s local state. You can still use useState for component-specific data such as whether a dropdown is open or which input field is being edited.

Redux Toolkit is most useful when state needs to be shared across components or when centralized state management makes the application easier to maintain.

3. Core Concepts You Need to Understand

Before writing code, let’s understand six important concepts.

3.1 Store

The store is the central place where Redux maintains your application’s state.

For example:

{
  counter: {
    value: 10
  },
  cart: {
    items: []
  }
}

The actual structure depends on how you configure your application.

In Redux Toolkit, we commonly create the store using configureStore().

3.2 State

State is the data maintained by the store.

For example:

{
  value: 0
}

If we’re building a counter application, the state might contain a single number.

If we’re building an e-commerce application, it might contain cart items, selected filters, or other shared data.

3.3 Action

An action describes something that happened.

Examples include:

Increment counter
Decrement counter
Add product to cart
Remove product from cart

An action is represented as an object containing a type and, optionally, a payload.

For example:

{
  type: "counter/increment"
}

An action carrying a product might look like this:

{
  type: "cart/addItem",
  payload: {
    id: 1,
    name: "Laptop",
    price: 65000
  }
}

The payload carries additional data needed to process the action.

3.4 Reducer

A reducer is a function that determines how state should change in response to an action.

Conceptually:

Previous State + Action
           |
           v
         Reducer
           |
           v
       Next State

For example, if the current counter value is 5 and an increment action occurs, the next value becomes 6.

With Redux Toolkit, reducers are commonly defined inside createSlice().

3.5 Dispatch

Dispatching means sending an action to the Redux store.

In a React component, we commonly use useDispatch():

const dispatch = useDispatch();

dispatch(increment());

This sends the increment action to the store so the corresponding reducer can process it.

3.6 Selector

A selector reads the state you need from the store.

In React, we commonly use useSelector():

const count = useSelector(
  (state) => state.counter.value
);

The component subscribes to the selected state. When the selected value changes, React Redux can trigger a re-render.

These concepts form the foundation of Redux Toolkit.

4. What Is createSlice()?

One of the most useful Redux Toolkit functions is createSlice().

In traditional Redux, developers often had to write separate action types, action creators, and reducer logic.

For example, incrementing a counter could require several pieces of code:

const INCREMENT = "counter/increment";

function increment() {
  return {
    type: INCREMENT
  };
}

function counterReducer(state = { value: 0 }, action) {
  switch (action.type) {
    case INCREMENT:
      return {
        ...state,
        value: state.value + 1
      };
    default:
      return state;
  }
}

This works, but writing all the pieces manually can introduce repetitive code.

Redux Toolkit simplifies this with createSlice():

import { createSlice } from "@reduxjs/toolkit";

const counterSlice = createSlice({
  name: "counter",
  initialState: {
    value: 0
  },
  reducers: {
    increment: (state) => {
      state.value += 1;
    }
  }
});

Notice that we only define the slice name, initial state, and reducers.

Redux Toolkit automatically generates:

• Action creators.
• Action types.
• The slice reducer.

For example:

counterSlice.actions.increment();

creates the increment action.

And:

counterSlice.reducer;

provides the reducer function that processes the action.

Why can we write state.value += 1?

You may remember that Redux state should not be mutated directly.

So why is this allowed?

Redux Toolkit uses Immer internally to let you write reducer logic using a mutation-like syntax.

Immer tracks the changes and produces the next immutable state.

This means the following is valid inside a Redux Toolkit reducer:

increment: (state) => {
  state.value += 1;
}

However, this does not mean you can mutate Redux state directly inside a React component.

The mutation-like syntax is safe because Redux Toolkit handles it inside its reducer logic.

5. Build a Counter Application Using Redux Toolkit

Let’s build a simple counter application in React.

Our application will support three operations:

• Increment the count.
• Decrement the count.
• Reset the count.

We’ll use Vite for the React project.

Step 1: Create the React project

Run:

npm create vite@latest redux-toolkit-demo -- --template react
cd redux-toolkit-demo
npm install
npm install @reduxjs/toolkit react-redux
npm run dev

We install two important packages:

@reduxjs/toolkit

Provides configureStore(), createSlice(), and other Redux Toolkit utilities.

react-redux

Connects React components to the Redux store through components and hooks such as Provider, useSelector(), and useDispatch().

Step 2: Create the counter slice

Create src/features/counter/counterSlice.js:

import { createSlice } from "@reduxjs/toolkit";

const initialState = {
  value: 0
};

const counterSlice = createSlice({
  name: "counter",
  initialState,
  reducers: {
    increment: (state) => {
      state.value += 1;
    },
    decrement: (state) => {
      state.value -= 1;
    },
    reset: (state) => {
      state.value = 0;
    }
  }
});

export const {
  increment,
  decrement,
  reset
} = counterSlice.actions;

export default counterSlice.reducer;

Let’s understand this file.

name

name: "counter"

Identifies the slice and is used to generate action type prefixes.

For example, the increment action has the type:

counter/increment

initialState

const initialState = {
  value: 0
};

Defines the initial state for the counter.

reducers

reducers: {
  increment: (state) => {
    state.value += 1;
  }
}

Defines how the state changes when the increment action is dispatched.

Exporting actions

export const {
  increment,
  decrement,
  reset
} = counterSlice.actions;

These generated action creators can be imported into React components.

Exporting the reducer

export default counterSlice.reducer;

The reducer will be registered in the Redux store.

Step 3: Create the Redux store

Create src/app/store.js:

import { configureStore } from "@reduxjs/toolkit";
import counterReducer from "../features/counter/counterSlice";

export const store = configureStore({
  reducer: {
    counter: counterReducer
  }
});

Here, configureStore() creates the Redux store.

The reducer object registers our counter reducer under the key counter.

This determines how the state is organized.

For example, the state will look like this:

{
  counter: {
    value: 0
  }
}

This is why we later access the counter using:

state.counter.value

If we register additional slices, they can be added to this reducer object.

Step 4: Provide the store to React

Open src/main.jsx and update it:

import { StrictMode } from "react";
import { createRoot } from "react-dom/client";
import { Provider } from "react-redux";
import App from "./App";
import { store } from "./app/store";

createRoot(document.getElementById("root")).render(
  <StrictMode>
    <Provider store={store}>
      <App />
    </Provider>
  </StrictMode>
);

The important part is:

<Provider store={store}>
  <App />
</Provider>

The Provider makes the Redux store available to React components beneath it.

Without the appropriate Provider, components using React Redux hooks won’t have access to that store.

Think of the Provider as the bridge between React and Redux.

Step 5: Read and update state in the React component

Update src/App.jsx:

import { useSelector, useDispatch } from "react-redux";
import { increment, decrement, reset } from "./features/counter/counterSlice";

function App() {
  const count = useSelector(state => state.counter.value);
  const dispatch = useDispatch();

  return (
    <div>
      <h1>Redux Toolkit Counter</h1>
      <h2>Count: {count}</h2>
      <button onClick={() => dispatch(increment())}>
        Increment
      </button>
      <button onClick={() => dispatch(decrement())}>
        Decrement
      </button>
      <button onClick={() => dispatch(reset())}>
        Reset
      </button>
    </div>
  );
}

export default App;

Congratulations! You’ve built your first Redux Toolkit application.

Let’s understand how the component interacts with the store.

Reading state with useSelector()

const count = useSelector(
  (state) => state.counter.value
);

This reads the counter value from the Redux store.

When the selected value changes, the component updates to display the new count.

Dispatching an action with useDispatch()

dispatch(increment());

This dispatches the action generated by the slice.

Redux processes the action using the counter reducer, updates the state, and notifies subscribed components as appropriate.

What happens when the user clicks Increment?

User clicks Increment
          |
          v
dispatch(increment())
          |
          v
Action: counter/increment
          |
          v
Counter Reducer
          |
          v
value increases by 1
          |
          v
Redux Store updates
          |
          v
useSelector detects
selected value change
          |
          v
React updates the UI

For example, if the current value is 5, clicking Increment makes it 6.

The component doesn’t manually update the displayed number. It reads the current value from the store, and React updates the UI when that value changes.

This is the core Redux Toolkit workflow.

6. Let’s Apply Redux Toolkit to a Real-World Shopping Cart

The counter example helps us understand the basics, but let’s return to our original e-commerce scenario.

Suppose the product listing page contains an Add to Cart button.

When the user clicks it, we want to add the product to the shared cart state.

Let’s create a cart slice.

Example: cartSlice.js

import { createSlice } from "@reduxjs/toolkit";

const initialState = {
  items: []
};

const cartSlice = createSlice({
  name: "cart",
  initialState,
  reducers: {
    addItem: (state, action) => {
      const product = action.payload;
      const existingItem = state.items.find(
        (item) => item.id === product.id
      );
      if (existingItem) {
        existingItem.quantity += 1;
      } else {
        state.items.push({
          ...product,
          quantity: 1
        });
      }
    },
    removeItem: (state, action) => {
      state.items = state.items.filter(
        (item) => item.id !== action.payload
      );
    },
    clearCart: (state) => {
      state.items = [];
    }
  }
});

export const {
  addItem,
  removeItem,
  clearCart
} = cartSlice.actions;

export default cartSlice.reducer;

Let’s understand the important part.

Adding a product

addItem: (state, action) => {
  const product = action.payload;

  const existingItem = state.items.find(
      (item) => item.id === product.id
    );

    if (existingItem) {
      existingItem.quantity += 1;
    } else {
      state.items.push({
        ...product,
        quantity: 1
      });
    }
}

The reducer checks whether the product already exists in the cart.

If it exists, the quantity increases.

Otherwise, a new item is added with a quantity of 1.

For example, a component can dispatch:

dispatch(
  addItem({
    id: 1,
    name: "Laptop",
    price: 65000
  })
);

The product object becomes the action’s payload.

Redux Toolkit processes the action and updates the cart state.

Register the cart reducer

Update src/app/store.js:

import { configureStore } from "@reduxjs/toolkit";
import counterReducer from "../features/counter/counterSlice";
import cartReducer from "../features/cart/cartSlice";

export const store = configureStore({
  reducer: {
    counter: counterReducer,
    cart: cartReducer
  }
});

The state now has two top-level slices:

{
  counter: {
    value: 0
  },
  cart: {
    items: []
  }
}

Each slice manages its own portion of the state.

Read the cart count

In a navbar component, we can calculate the total number of items:

import { useSelector } from "react-redux";

function Navbar() {
  const items = useSelector(
    (state) => state.cart.items
  );
  const cartCount = items.reduce(
    (total, item) => total + item.quantity,
    0
  );
  return (
    <nav>
      <h2>My Store</h2>
      <p>Cart: {cartCount}</p>
    </nav>
  );
}
export default Navbar;

Notice that the navbar doesn’t need to receive the cart count through props from the product listing page.

It reads the shared state directly from Redux.

Likewise, the cart page can read the same state:

const items = useSelector(
  (state) => state.cart.items
);

When a product is added, both components can display updated information based on the shared state.

This is where Redux Toolkit becomes useful: multiple components can work with the same application state without tightly coupling their component hierarchies.

In a production application, you would also need to consider price validation, inventory, persistence, and server-side cart behavior. The frontend cart should not be treated as the authoritative source for checkout prices or stock availability.

7. What Is the Difference Between Redux and Redux Toolkit?

You may hear developers refer to both Redux and Redux Toolkit.

Redux is the underlying state management library and its core principles.

Redux Toolkit is the recommended way to write Redux applications today.

Here’s a compact comparison:

+----------------------+-------------------------+
| Traditional Redux    | Redux Toolkit           |
+----------------------+-------------------------+
| Manual action types  | Generated action types   |
| Manual action creators| Generated action creators|
| Switch-based reducers| createSlice reducers     |
| Manual store setup   | configureStore           |
| More boilerplate     | Less boilerplate         |
| Immutable updates    | Immer-powered reducers   |
+----------------------+-------------------------+

The key point is that Redux Toolkit doesn’t remove Redux’s core principles. It makes those principles easier to implement.

You still have a store, actions, reducers, and predictable state updates.

8. What Is Redux Thunk?

You may have noticed that the previous examples handled synchronous operations.

But real applications frequently need to fetch data from an API.

For example, a product listing page might need to request products from the backend.

What happens when we need asynchronous logic?

Redux Toolkit’s configureStore() includes Redux Thunk middleware by default. Thunk lets you dispatch functions that can perform asynchronous work and dispatch actions as the work progresses.

For example:

import { createAsyncThunk } from "@reduxjs/toolkit";

export const fetchProducts = createAsyncThunk(
  "products/fetchProducts",
  async () => {
    const response = await fetch(
      "https://dummyjson.com/products"
    );
    if (!response.ok) {
      throw new Error("Failed to fetch products");
    }
    const data = await response.json();
    return data.products;
  }
);

This creates an asynchronous thunk action.

Redux Toolkit automatically provides three lifecycle action types:

products/fetchProducts/pending
products/fetchProducts/fulfilled
products/fetchProducts/rejected

These represent the request being started, completed successfully, or rejected.

A slice can handle them using extraReducers:

extraReducers: (builder) => {
  builder
    .addCase(fetchProducts.pending, (state) => {
      state.status = "loading";
    })
    .addCase(fetchProducts.fulfilled, (state, action) => {
      state.status = "succeeded";
      state.items = action.payload;
    })
    .addCase(fetchProducts.rejected, (state) => {
      state.status = "failed";
    });
}

In this example, state is assumed to contain status and items fields, which must be included in the slice's initialState.

A component can then dispatch the thunk:

dispatch(fetchProducts());

This lets the application manage loading, success, and failure states in a structured way.

For applications with more advanced data-fetching requirements, caching, automatic refetching, and request lifecycle management, Redux Toolkit also provides RTK Query. It can reduce the need to write custom fetching thunks for common API operations.

9. When Should You Use Redux Toolkit?

Redux Toolkit is useful when your application has shared state that benefits from centralized management.

Common examples include:

• Shopping cart data shared across pages.
• Authentication and user-related application state.
• Complex multi-step workflows.
• Shared filters and sorting settings.
• Data used by multiple distant components.
• State transitions that need to be easy to inspect and test.

However, you don’t need Redux Toolkit for every state variable.

For example:

const [isModalOpen, setIsModalOpen] = useState(false);

If this state is only used by one component, React’s local state is usually sufficient.

A useful rule of thumb:

Use local React state for local UI behavior, and consider Redux Toolkit when shared state or complex state transitions justify centralized management.

For server data that requires caching and synchronization, also consider whether RTK Query or another data-fetching solution is more appropriate than manually maintaining everything in a global store.

10. Common Mistakes Beginners Should Avoid

Mistake 1: Forgetting to wrap the application in Provider

Without the appropriate Provider, React Redux hooks cannot access the store.

Mistake 2: Registering the wrong reducer key

If the store is configured like this:

reducer: {
  counter: counterReducer
}

Then the selector should use:

state.counter.value

Not:

state.value

The state shape depends on how the reducers are registered.

Mistake 3: Forgetting to dispatch an action

Calling an action creator alone doesn’t update the store.

For example:

increment();

creates an action object, but doesn’t dispatch it.

You need:

dispatch(increment());

Mistake 4: Mutating state outside a reducer

Redux Toolkit supports mutation-like syntax inside its reducer logic because of Immer.

That doesn’t mean you should mutate values returned by useSelector() directly in a component.

Mistake 5: Putting everything into Redux

Not every input value, dropdown state, or temporary UI flag needs to be stored globally.

Use Redux where it provides real value.

Mistake 6: Confusing client state with server state

Redux Toolkit can manage client-side state and API workflows, but the browser’s state isn’t automatically the source of truth for backend data.

For important operations such as payments, stock availability, or order creation, the backend must validate the data independently.

Conclusion

Redux Toolkit provides a structured and predictable way to manage shared state in React applications.

We’ve learned that:

• The Redux store holds application state.
• Actions describe events that should be processed.
• Reducers determine how state changes.
• createSlice() generates action creators and reducers.
• configureStore() sets up the store.
• Provider makes the store available to React components.
• useSelector() reads state.
• useDispatch() dispatches actions.
• createAsyncThunk() supports asynchronous workflows.
• RTK Query can simplify API fetching and caching.

The key takeaway is simple:

Redux Toolkit helps you manage shared application state through a predictable flow of actions, reducers, and store updates.

You don’t need Redux for every React application. But when multiple components depend on the same data and state transitions become complicated, Redux Toolkit can make the codebase easier to understand, maintain, and test.

What’s Next?

Now that you understand Redux Toolkit, here are some topics worth exploring next:

• Redux Toolkit vs Context API: Understand the differences and when to use each.
• Redux Middleware: Learn how middleware intercepts dispatched actions and supports additional behavior.
• Redux Toolkit with TypeScript: Define typed state, actions, and selectors.
• RTK Query: Explore API caching, mutations, loading states, and cache invalidation.
• Redux DevTools: Inspect actions and state changes while debugging.
• Redux Toolkit in a Real E-Commerce App: Combine product fetching, cart management, and API integration.

Happy coding! ✌️

Imagine opening Amazon or Flipkart.

You see a navigation bar, product categories, a search bar, product listings, recommendations, a shopping cart, and a checkout flow.

Now imagine that different teams are responsible for developing these features.

One team works on the product listing page. Another develops the shopping cart. A third manages checkout, while another team handles search.

How can all these teams develop, test, and deploy their features independently while delivering a single, consistent experience to the user?

One possible solution is Micro Frontend Architecture.

Micro Frontends apply the ideas of microservices to frontend development. Instead of building an entire user interface as one tightly coupled application, we divide it into smaller, independently manageable frontend applications.

In this article, we’ll explore the concept from scratch, understand why it is useful, learn about Host and Remote applications, and see how Webpack Module Federation helps different frontend applications work together.

We’ll also build a small conceptual example using React and Webpack.

No prior knowledge of Micro Frontends is required.

1. First, Understand the Problem

Let’s consider an e-commerce application similar to Amazon or Flipkart.

A simplified version might contain these features:

• Header and navigation
• Product search
• Product listing
• Product details
• Shopping cart
• Checkout
• User account

Initially, a company might build all these features inside a single React application.

The project could look something like this:

ecommerce-app/
    src/
        components/
            Header.jsx
            SearchBar.jsx
            ProductCard.jsx
            Cart.jsx
            Checkout.jsx
        pages/
            Home.jsx
            Products.jsx
            ProductDetails.jsx
        App.jsx

This is a perfectly reasonable architecture for many applications.

However, as the application grows, several challenges can emerge.

Problem 1: Multiple teams work on the same codebase

Imagine five teams working on the same frontend application.

The product team modifies product components, the checkout team changes checkout logic, and the cart team updates cart functionality.

Changes can overlap, dependencies can become complicated, and teams may need to coordinate releases.

Problem 2: Independent deployment becomes difficult

Suppose the shopping cart team finishes a feature today.

However, the application contains other features that are still under development.

Depending on how the project is structured and deployed, the cart team may have to wait for the larger application release.

Problem 3: The codebase becomes harder to maintain

As the application grows, shared components, business logic, dependencies, and team responsibilities can become tightly coupled.

This doesn’t mean every large React application will develop these problems. Good modular design can keep a monolithic frontend maintainable for a long time.

But at a certain organizational and technical scale, a different architecture may become useful.

This brings us to Micro Frontends.

2. What Is Micro Frontend Architecture?

Micro Frontend Architecture is an approach in which a large frontend application is divided into smaller frontend applications or independently developed features that work together to deliver a unified user experience.

Instead of one team owning the entire frontend, different teams can own different parts of the application.

For example:

              E-Commerce Application
                       |
        +--------------+--------------+
        |              |              |
     Products         Cart          Checkout
        |              |              |
     Team A          Team B         Team C
        |              |              |
     Frontend       Frontend       Frontend
     Application    Application    Application

Each frontend can have its own:

• Components and business logic
• Development workflow
• Tests and build process
• Team ownership
• Release process, depending on the architecture

The different parts are then composed into a single experience for the user.

The important point is that the user sees one application, even though multiple frontend applications may contribute to it.

A real-world example: An online shopping platform

Imagine an e-commerce platform with the following ownership:

                   Shopping Website
                           |
          +----------------+----------------+
          |                |                |
      Product UI        Cart UI        Checkout UI
          |                |                |
       Team A            Team B           Team C
          |                |                |
      Product data      Cart state       Order flow

The product team can improve product cards without needing to coordinate every small change with the checkout team.

The cart team can work on cart-related features independently, provided the teams maintain compatible integration contracts.

The checkout team can focus on the checkout experience.

This is the basic idea behind Micro Frontends.

3. Why Do We Need Micro Frontends?

Micro Frontends aren’t required for every application. A single React application is often the better choice for small and medium-sized projects.

Micro Frontends become valuable when an organization needs stronger team independence, clearer ownership, and more flexible delivery.

Let’s look at the main reasons.

1. Independent team ownership

Different teams can own different parts of the frontend.

For example:

Product Team → Product listing
Cart Team    → Shopping cart
Checkout Team → Checkout experience

Each team can make decisions within its area without constantly modifying another team’s code.

2. Independent deployment

Suppose the cart team adds a new discount feature.

With a suitable Micro Frontend architecture, the team may be able to build and deploy the cart application independently of the product listing application.

The exact deployment model depends on how the applications are composed.

For example, a runtime-composed architecture can load a newly deployed remote application without requiring the host’s entire bundle to be rebuilt, provided the remote’s integration contract remains compatible.

3. Better ownership of large codebases

Instead of organizing every feature around one enormous frontend repository, teams can establish clearer boundaries.

These boundaries can make it easier to understand who owns a feature, which team handles bugs, and where new functionality belongs.

4. Technology flexibility

In some architectures, individual frontend applications can use different frameworks.

For example, one part might use React while another uses Vue.

However, this flexibility comes with costs. Different frameworks can increase bundle size, create inconsistent user experiences, and complicate integration.

Using the same framework across all Micro Frontends is often simpler.

5. Parallel development

Multiple teams can develop features simultaneously, reducing coordination overhead when their responsibilities and integration contracts are well defined.

Remember: Micro Frontends solve organizational and architectural problems. They don’t automatically make an application faster or its code better.

4. How Do Micro Frontends Work?

There are several ways to implement Micro Frontends.

For example:

• Build-time integration
• Runtime integration
• Web Components
• Client-side routing and separate applications
• Server-side composition

One popular runtime integration approach in the Webpack ecosystem is Module Federation.

Before exploring it, let’s understand two important terms: Host and Remote.

What is a Host application?

The Host is the application that brings together features exposed by other frontend applications.

It may provide:

• The main application shell
• Navigation and routing
• Global layout
• Authentication integration
• Shared application infrastructure

For our example, imagine that the Host is the main shopping website.

Host Application
    |
    +-- Header
    +-- Navigation
    +-- Product Remote
    +-- Cart Remote

The Host can load features from other applications at runtime.

What is a Remote application?

A Remote is an application that exposes selected modules so that another application can consume them.

For example, the Product Remote might expose a product listing component.

Product Remote
    |
    +-- ProductList.jsx
    +-- ProductCard.jsx
    +-- Product-related logic

The Host can load the exposed ProductList component and render it as part of its own user interface.

A Remote doesn’t have to expose its entire application. It can expose specific components, utilities, or other modules.

Host vs Remote

+------------------------+------------------------+---------------------------+
| Feature                | Host                   | Remote                    |
+------------------------+------------------------+---------------------------+
| Main responsibility    | Composes the app       | Exposes modules           |
| Loads remote modules   | Usually yes            | Not necessarily           |
| Exposes modules        | Optional               | Commonly does             |
| Own build config       | Yes                    | Yes                       |
| Independent deployment | Depends on architecture| Often supported           |
| Example                | Shopping website       | Product listing app       |
+------------------------+------------------------+---------------------------+

In simple terms:

• Host: The main application that brings different frontend features together.
• Remote: An application that exposes components or modules for other applications to consume.

5. What Is Webpack Module Federation?

Now that we understand Host and Remote applications, let’s explore the mechanism that connects them.

Webpack Module Federation allows separately built JavaScript applications to share and consume modules at runtime.

It was introduced in Webpack 5.

Traditionally, applications commonly bundle their dependencies during the build process. If one application needs code from another, that code may be imported through a package, shared library, or another integration mechanism.

Module Federation provides a way to expose selected modules from one build and consume those modules from another build at runtime.

For example:

                Host Application
                       |
                       |
               Loads remote module
                       |
                       v
                Remote Application
                       |
                       |
                 ProductList.jsx

The Host doesn’t necessarily need the Remote’s source code in its own repository.

Instead, it can load the Remote’s federation entry file, commonly named remoteEntry.js, and use the modules exposed by that Remote.

Let’s understand the key terms.

1. ModuleFederationPlugin

Webpack provides the ModuleFederationPlugin to configure federation.

It allows an application to define:

• Its federation name
• The remote entry filename
• The modules it exposes
• The remote applications it consumes
• Dependencies shared between applications

2. remoteEntry.js

The Remote build generates a federation entry file, commonly called remoteEntry.js.

This file provides the runtime information needed to access the modules exposed by the Remote.

Think of it as the entry point through which the Host discovers and loads the Remote’s exposed modules.

It is not necessarily the complete application bundle. Additional JavaScript chunks may be downloaded when needed.

3. exposes

The exposes configuration specifies which modules a Remote makes available.

For example:

exposes: {
  "./ProductList": "./src/ProductList.jsx"
}

This means that another application can reference the exposed module using the name ./ProductList.

4. remotes

The remotes configuration tells the Host where to find another application.

For example:

remotes: {
  productApp: "productApp@http://localhost:3001/remoteEntry.js"
}

Here:

• productApp is the local alias used by the Host.
• productApp before @ is the Remote container name.
• The URL points to the Remote’s federation entry file.

5. shared

The shared configuration lets applications share dependencies rather than always loading separate copies.

React is a common example.

shared: {
  react: {
    singleton: true
  },
  "react-dom": {
    singleton: true
  }
}

The singleton option tells the federation runtime to use a single shared instance of that dependency within the relevant sharing scope, subject to the configured versions and runtime negotiation.

This is especially important for React because separate incompatible React instances can cause problems when components and hooks are integrated across application boundaries.

For production applications, dependency versions and sharing requirements should be configured carefully.

6. Let’s Build a Simple Example Using React and Webpack

Let’s create two applications:

1. Host Application — Displays the main page and loads the product component.
2. Product Remote — Exposes a reusable ProductList component.

Our goal is simple:

When a user opens the Host application, it loads the ProductList component from the Remote application.

We’ll use Webpack 5 and React.

Project structure

micro-frontend-demo/
    host/
        src/
            App.jsx
            index.js
        webpack.config.js

    product-remote/
        src/
            ProductList.jsx
            index.js
        webpack.config.js

For simplicity, we’ll focus on the federation configuration and the React components rather than reproducing all the boilerplate required to configure two complete Webpack projects.

Step 1: Create the Product Remote component

Inside product-remote/src/ProductList.jsx:

import React from "react";

const products = [
  { id: 1, name: "Laptop", price: 65000 },
  { id: 2, name: "Headphones", price: 2500 },
  { id: 3, name: "Keyboard", price: 1500 }
];

function ProductList() {
  return (
    <section>
      <h2>Products</h2>
      {products.map((product) => (
        <div key={product.id}>
          <h3>{product.name}</h3>
          <p>Price: ₹{product.price}</p>
        </div>
      ))}
    </section>
  );
}

export default ProductList;

This is a simple React component that displays a list of products.

Normally, we might import this component directly into another React application.

But with Module Federation, we will expose it through the Remote application’s build configuration.

Step 2: Configure the Product Remote

Inside product-remote/webpack.config.js:

const HtmlWebpackPlugin = require("html-webpack-plugin");
const { ModuleFederationPlugin } = require("webpack").container;
const deps = require("./package.json").dependencies;

module.exports = {
  mode: "development",
  entry: "./src/index.js",
  devServer: {
    port: 3001,
    historyApiFallback: true
  },
  output: {
    publicPath: "auto"
  },
  resolve: {
    extensions: [".js", ".jsx"]
  },
  module: {
    rules: [
      {
        test: /\.jsx?$/,
        exclude: /node_modules/,
        use: "babel-loader"
      }
    ]
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: "./public/index.html"
    }),
    new ModuleFederationPlugin({
      name: "productApp",
      filename: "remoteEntry.js",
      exposes: {
        "./ProductList": "./src/ProductList.jsx"
      },
      shared: {
        react: {
          singleton: true,
          requiredVersion: deps.react
        },
        "react-dom": {
          singleton: true,
          requiredVersion: deps["react-dom"]
        }
      }
    })
  ]
};

Let’s understand the important configuration.

name: "productApp"

This identifies the Remote container.

filename: "remoteEntry.js"

This specifies the name of the federation entry file generated by Webpack.

exposes

exposes: {
  "./ProductList": "./src/ProductList.jsx"
}

This exposes the product component so that another application can import it through Module Federation.

shared

We configure React and React DOM as shared dependencies to help avoid unnecessary duplicate framework instances.

publicPath: "auto"

This helps Webpack determine the public path for loading assets and additional chunks. It is useful when a Remote is served from a different location than the Host.

The configuration assumes a standard Webpack project with dependencies such as webpack, webpack-cli, webpack-dev-server, html-webpack-plugin, babel-loader, and the appropriate Babel presets already installed.

Step 3: Configure the Host application

Now let’s configure the main shopping website.

Inside host/webpack.config.js:

const HtmlWebpackPlugin = require("html-webpack-plugin");
const { ModuleFederationPlugin } = require("webpack").container;
const deps = require("./package.json").dependencies;

module.exports = {
  mode: "development",
  entry: "./src/index.js",
  devServer: {
    port: 3000,
    historyApiFallback: true
  },
  output: {
    publicPath: "auto"
  },
  resolve: {
    extensions: [".js", ".jsx"]
  },
  module: {
    rules: [
      {
        test: /\.jsx?$/,
        exclude: /node_modules/,
        use: "babel-loader"
      }
    ]
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: "./public/index.html"
    }),
    new ModuleFederationPlugin({
      name: "hostApp",
      remotes: {
        productApp:
          "productApp@http://localhost:3001/remoteEntry.js"
      },
      shared: {
        react: {
          singleton: true,
          requiredVersion: deps.react
        },
        "react-dom": {
          singleton: true,
          requiredVersion: deps["react-dom"]
        }
      }
    })
  ]
};

The most important part is:

remotes: {
  productApp:
    "productApp@http://localhost:3001/remoteEntry.js"
}

This tells the Host where to find the Product Remote.

The Remote must be running and serving its federation entry file at that URL.

In production, the URL would typically point to a deployed asset location or CDN rather than localhost.

Step 4: Import the Remote component in the Host

Inside host/src/App.jsx:

import React, { Suspense, lazy } from "react";

const ProductList = lazy(
  () => import("productApp/ProductList")
);

function App() {
  return (
    <div>
      <h1>My Shopping Website</h1>
      <nav>
        <a href="/">Home</a>
        {" | "}
        <a href="/cart">Cart</a>
      </nav>
      <Suspense fallback={<p>Loading products...</p>}>
        <ProductList />
      </Suspense>
    </div>
  );
}

export default App;

Let’s break this down.

import("productApp/ProductList")

This references the exposed component from the Remote application.

It isn’t a normal relative import such as:

import ProductList from "./ProductList";

Instead, Webpack resolves it through the configured federation relationship.

React.lazy()

This lets React load the component asynchronously.

Suspense

While the component is being loaded, React displays the fallback UI.

For example:

My Shopping Website

Loading products...

Once the component loads successfully, the product list appears.

Remember that React.lazy() and Suspense handle the component's loading state, but you should also design explicit error handling for failed Remote downloads or incompatible integrations.

Step 5: What happens when the application runs?

Assume both applications are running:

Host:
http://localhost:3000

Product Remote:
http://localhost:3001

The browser opens the Host application.

The Host discovers that ProductList comes from productApp.

It loads the Remote’s federation entry file, resolves the exposed module, and loads the required code.

The result looks like this:

Browser
   |
   v
Host Application :3000
   |
   | Loads remoteEntry.js
   v
Product Remote :3001
   |
   | Provides ProductList
   v
Host renders ProductList
   |
   v
User sees one shopping website

The user doesn’t need to know that the product component originated from another application.

The Host provides the surrounding page, and the Remote provides the product listing feature.

Important: This example illustrates runtime integration. To run it, both applications need valid Webpack configurations, React dependencies, entry files, HTML templates, Babel configuration, and scripts to start their development servers. The Remote must be available at the configured URL.

7. How Does Independent Deployment Work?

One of the major attractions of Micro Frontends is the ability to deploy different frontend features independently.

Imagine the following deployment setup:

                 Production Website
                         |
                         v
                  Host Application
                         |
                         v
                  Remote Entry URL
                         |
                         v
                  Product Remote

Suppose the product team changes the product card design.

The team builds and deploys a new version of the Product Remote.

If the Host continues loading the same stable Remote entry URL, it can load the updated implementation without rebuilding the Host, provided the Remote remains compatible with the Host’s expectations.

This is an important benefit, but it requires good release management.

For example, teams need to consider:

• Backward-compatible exposed module APIs.
• Remote availability and fallback behavior.
• Dependency compatibility.
• Cache invalidation for remote assets.
• Versioning and rollback strategies.
• Testing integration between the Host and Remote.

Independent deployment doesn’t mean there are no dependencies. It means teams can manage and release their parts more independently when those dependencies are well controlled.

8. Advantages of Micro Frontend Architecture

Let’s summarize the major benefits.

1. Independent development

Different teams can own different frontend features and work in parallel.

2. Independent deployment

A Remote can often be deployed separately from the Host in a runtime-composed architecture.

3. Clear ownership

Teams can maintain responsibility for their components, functionality, and release processes.

4. Incremental modernization

Organizations can gradually replace or modernize parts of a legacy frontend instead of rewriting the entire application at once.

5. Organizational scalability

As teams grow, clearer boundaries can reduce coordination overhead and allow teams to move more independently.

These benefits are most valuable when the application and organization are large enough to justify the extra architecture.

9. Disadvantages of Micro Frontend Architecture

Micro Frontends are not a free improvement.

They introduce complexity that a well-structured monolithic frontend may not need.

1. Increased architectural complexity

Instead of managing one frontend build, you may need to manage multiple builds, deployment pipelines, runtime dependencies, and integration contracts.

2. Dependency management

Different applications may use incompatible versions of React or other libraries.

Module Federation’s shared dependency configuration helps, but version negotiation and compatibility still require careful planning.

3. Performance overhead

Multiple frontend applications may introduce additional JavaScript, network requests, and runtime overhead.

Poorly designed Micro Frontends can make an application slower rather than faster.

4. Shared state becomes more complicated

Suppose the cart count appears in the global header, product pages, and checkout.

How should these parts share cart information?

Possible approaches include:

• A shared backend API.
• Explicit props and callbacks where appropriate.
• A carefully designed shared state layer.
• Custom browser events.
• A shared state library, when the architecture justifies it.

There is no universal solution. The important thing is to define clear ownership and avoid creating tightly coupled global state across all frontend applications.

5. Inconsistent user experience

Different teams might implement different button styles, spacing, loading states, or accessibility behavior.

A shared design system and consistent interface guidelines can help maintain a unified experience.

6. Debugging becomes harder

An issue might originate in the Host, a Remote, a shared dependency, a network request, or an integration contract.

Teams need good logging, source maps, monitoring, and clear ownership to troubleshoot effectively.

7. Operational overhead

Multiple independently deployed applications mean more pipelines, monitoring, release coordination, and potentially more infrastructure to maintain.

For a small application, this overhead may outweigh the benefits.

10. When Should You Use Micro Frontends?

Micro Frontends are worth considering when:

• Multiple teams own distinct frontend domains.
• Teams need to release features independently.
• The application is large and has clear domain boundaries.
• A gradual migration from a legacy frontend is necessary.
• The organization can support the added operational complexity.

They may be unnecessary when:

• The application is small.
• One team owns the entire frontend.
• Features are tightly coupled.
• A modular monolithic React application already meets the requirements.
• Independent deployment offers little practical benefit.

A modular monolith is often an excellent starting point.

You can organize a React application into well-defined feature modules without immediately splitting it into independently deployed applications.

The goal isn’t to use the most advanced architecture. The goal is to choose the simplest architecture that meets the application’s actual needs.

Conclusion

Micro Frontend Architecture provides a way to divide a large frontend into smaller applications that can be developed and, in suitable architectures, deployed independently.

We’ve learned that:

• Micro Frontends help organize large frontend applications around independently owned features.
• The Host composes the overall experience.
• Remote applications expose modules that other applications can consume.
• Webpack Module Federation enables runtime sharing and loading of modules across separate builds.
• exposes defines the modules a Remote makes available.
• remotes tells the Host where to find other applications.
• shared configures dependencies that can be reused across application boundaries.
• Independent deployment requires stable contracts, compatibility, and reliable release processes.
• Micro Frontends introduce trade-offs in performance, testing, state management, and operational complexity.

The key takeaway is simple:

Micro Frontends aren’t just about splitting frontend code into multiple projects. They’re about creating clear boundaries that allow teams to build and deliver frontend features more independently.

Before adopting this architecture, understand the problem you’re trying to solve. If a modular monolith is enough, keep things simple. If independent ownership and deployment are becoming genuine challenges, Micro Frontends may be worth exploring.

What’s Next?

Now that you understand the basics, consider exploring these topics next:

• Module Federation in Depth: Understand runtime module loading, shared dependency negotiation, and version compatibility.
• Micro Frontend Communication: Learn how independent applications exchange data using props, custom events, APIs, or shared state.
• Micro Frontend Routing: Explore how the Host and Remote applications coordinate navigation.
• Error Boundaries and Fallback UI: Handle failures when a Remote application cannot load.
• Micro Frontend Performance: Learn about bundle splitting, caching, shared dependencies, and Core Web Vitals.
• Micro Frontend vs Monolithic Frontend: Understand when each architecture makes sense.

Happy coding! ✌️

Have you ever used a chat application where messages appear instantly without refreshing the page?

Or visited a dashboard where stock prices, notifications, or live order statuses update automatically?

How does the browser receive new information from the server when the user hasn’t clicked anything?

One common solution is WebSockets.

WebSockets allow the browser and server to establish a persistent connection through which they can exchange messages in both directions. Once the connection is established, either side can send data without creating a new HTTP request for every message.

In this article, we’ll understand WebSockets from scratch, learn how messages travel between the browser and server, build a small example using HTML and JavaScript, and then implement the same functionality in React.

We’ll also explore why we store the WebSocket instance in useRef, how to manage its lifecycle, and what happens when the connection closes.

No prior knowledge of WebSockets is required.

1. First, Understand the Problem

Let’s start with a simple scenario.

Imagine you’re building a chat application.

User A sends a message to User B. Ideally, User B should receive that message immediately, without refreshing the page.

But how does the application know when a new message arrives?

With a traditional HTTP request-response flow, the browser sends a request and the server responds.

For example:

Browser                 Server
   |                        |
   |------ Request -------->|
   |                        |
   |<------ Response -------|
   |                        |
   |   Connection ends      |

This works perfectly for many operations, such as fetching a user profile or loading a product list.

But consider a real-time application where the server needs to send new information whenever something happens.

One simple approach is polling.

What is polling?

Polling means the browser periodically asks the server whether anything has changed.

For example:

setInterval(async () => {
  const response = await fetch("/api/messages");
  const messages = await response.json();

  console.log(messages);
}, 3000);

This sends an HTTP request every three seconds.

The flow looks like this:

Browser                  Server
   |                         |
   |---- Any new messages? ->|
   |<---- No new messages ---|
   |                         |
   |---- Any new messages? ->|
   |<---- New messages ------|
   |                         |
   |---- Any new messages? ->|
   |<---- No new messages ---|

Polling is simple, but it has disadvantages:

• It generates repeated HTTP requests.
• The server receives requests even when nothing has changed.
• Updates may be delayed until the next polling interval.
• Short polling intervals can create unnecessary traffic.

What if the browser and server could maintain an open connection and send messages whenever needed?

That’s where WebSockets come in.

2. What Is a WebSocket?

A WebSocket is a communication protocol that provides a persistent, two-way communication channel between a client and a server.

Instead of repeatedly creating requests to check for updates, the browser establishes a connection that can remain open.

Once connected:

• The browser can send messages to the server.
• The server can send messages to the browser.
• Either side can initiate a message.
• The connection remains open until it is closed or interrupted.

This is called full-duplex communication.

Let’s visualize it:

WebSocket Connection

Browser  <==========================>  Server
          Message              Message
          Message              Message
          Message              Message

          Persistent connection

Unlike ordinary HTTP request-response communication, the server doesn’t need to wait for a new browser request before sending a WebSocket message.

How is the connection established?

WebSockets typically begin with an HTTP-based handshake.

The browser requests an upgrade from HTTP to WebSocket. If the server accepts, the connection switches to the WebSocket protocol.

Conceptually:

Browser                         Server
   |                                |
   |--- HTTP Upgrade Request ------>|
   |                                |
   |<------ Upgrade Accepted -------|
   |                                |
   |====== WebSocket Connection ====|
   |                                |
   |------ Message ---------------->|
   |<----- Message -----------------|
   |------ Message ---------------->|

After the handshake succeeds, the connection can carry WebSocket messages in both directions.

WebSocket URLs typically use these schemes:

• ws:// — WebSocket without transport encryption.
• wss:// — WebSocket protected by TLS encryption.

For production applications, use wss:// over a secure connection.

3. How Does WebSocket Communication Work?

Before writing code, let’s understand the main concepts.

1. WebSocket

The browser provides a built-in WebSocket API.

You create a connection like this:

const socket = new WebSocket("wss://example.com/socket");

This initiates a connection to the specified WebSocket server.

2. onopen

This event fires when the connection has been established.

socket.onopen = () => {
  console.log("Connected to server");
};

You can use this event to update the UI or enable messaging.

3. send()

The send() method sends data through the WebSocket connection.

socket.send("Hello Server!");

You can send strings, and the API also supports other types of data, including binary data.

For JSON messages, convert the object into a string:

socket.send(
  JSON.stringify({
    type: "chat",
    message: "Hello!"
  })
);

4. onmessage

This event fires when a message arrives from the server.

socket.onmessage = (event) => {
  console.log("Received:", event.data);
};

For a JSON message, parse the string:

socket.onmessage = (event) => {
  const data = JSON.parse(event.data);

  console.log(data.message);
};

5. onclose

This event fires when the connection closes.

socket.onclose = () => {
  console.log("Connection closed");
};

You can use it to update the connection status or initiate a reconnection strategy.

6. onerror

This event reports certain connection errors.

socket.onerror = (error) => {
  console.error("WebSocket error:", error);
};

An error doesn’t necessarily tell you the precise reason for a failure. In practice, you should also inspect the close event and handle reconnection when appropriate.

These six concepts are enough to build our first WebSocket application.

4. Build Your First WebSocket Application Using HTML and JavaScript

Let’s build a small application where the browser sends a message to a server, and the server responds with that message.

For example:

Browser: Hello Server!
Server:  Server received: Hello Server!

We’ll create four files:

websocket-demo/
    server.js
    package.json
    index.html
    main.js

One important point: a WebSocket client needs a WebSocket server to communicate with. The browser’s WebSocket API alone isn’t enough.

For this example, we’ll use Node.js and the ws package to create a small server.

Step 1: Set up the project

Install Node.js if it isn’t already installed.

Create a project folder and run:

npm init -y
npm install ws

The ws package provides a WebSocket server implementation for Node.js.

Step 2: Create the WebSocket server

Create server.js:

const WebSocket = require("ws");

const wss = new WebSocket.Server({
  port: 8080
});

wss.on("connection", (socket) => {
  console.log("Client connected");
  socket.on("message", (message) => {
    const text = message.toString();
    console.log("Received:", text);
    socket.send(`Server received: ${text}`);
  });
  socket.on("close", () => {
    console.log("Client disconnected");
  });
});

console.log("WebSocket server running on port 8080");

Let’s understand what happens here.

First, we create a WebSocket server:

const wss = new WebSocket.Server({
  port: 8080
});

The server listens on port 8080.

Next, we listen for new connections:

wss.on("connection", (socket) => {
  // Handle this client's connection
});

When a browser connects, the callback receives a socket representing that particular client's connection.

We then listen for messages from that client:

socket.on("message", (message) => {
  const text = message.toString();

  socket.send(`Server received: ${text}`);
});

When a message arrives, the server sends a response through the same connection.

Notice that we’re using socket.send() on the server. The browser also has a send() method, but each one sends data in the opposite direction.

Step 3: Create the HTML file

Create index.html:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>WebSocket Demo</title>
</head>
<body>
  <h1>WebSocket Demo</h1>
  <p id="status">Connecting...</p>
  <input
    id="messageInput"
    type="text"
    placeholder="Enter your message"
  />
  <button id="sendBtn">Send Message</button>
  <h3>Messages</h3>
  <ul id="messages"></ul>
  <script src="./main.js"></script>
</body>
</html>

This page contains an input field, a button, a connection status, and a list where messages will appear.

Step 4: Create the browser-side JavaScript

Create main.js:

const status = document.getElementById("status");
const input = document.getElementById("messageInput");
const sendBtn = document.getElementById("sendBtn");
const messages = document.getElementById("messages");

const socket = new WebSocket("ws://localhost:8080");
socket.onopen = () => {
    status.textContent = "Connected";
};
socket.onmessage = (event) => {
    const li = document.createElement("li");
    li.textContent = event.data;
    messages.appendChild(li);
};
socket.onclose = () => {
    status.textContent = "Disconnected";
};
socket.onerror = (error) => {
    console.error("WebSocket error:", error);
    status.textContent = "Connection error";
};
sendBtn.addEventListener("click", () => {
    const message = input.value.trim();
    if (!message) return;
    if (socket.readyState !== WebSocket.OPEN) {
        status.textContent = "Not connected";
        return;
    }
    socket.send(message);
    input.value = "";
});

Let’s break down the important parts.

Creating the connection:

const socket = new WebSocket("ws://localhost:8080");

This initiates the WebSocket handshake with our Node.js server.

Waiting for the connection:

socket.onopen = () => {
  status.textContent = "Connected";
};

The browser should send messages only when the connection is open.

Sending a message:

socket.send(message);

The message travels to the server through the established connection.

Receiving the server response:

socket.onmessage = (event) => {
  const li = document.createElement("li");

  li.textContent = event.data;
  messages.appendChild(li);
};

The browser receives the response and displays it on the page.

Step 5: Run the application

Start the WebSocket server:

node server.js

Then open index.html through a local development server, such as VS Code Live Server.

Type a message and click Send Message.

You’ll see the server’s response appear in the list.

For example:

Browser sends:
Hello Server!

Server responds:
Server received: Hello Server!

What happens behind the scenes?

Let’s put everything together:

1. The browser creates a WebSocket connection.
2. The server accepts the connection.
3. The browser sends a message using socket.send().
4. The server receives the message through its message event.
5. The server sends a response using socket.send().
6. The browser receives the response through onmessage.
7. The UI displays the response without a page refresh.

This is the basic request-and-response pattern using WebSockets.

Although our example echoes messages back to the same client, a chat application can use the same connection to send messages to other connected users. The server would need to manage clients, authenticate them, and route messages to the appropriate recipients.

5. Implement the Same Example in React

Now let’s implement the same application using React.

The communication protocol doesn’t change. We still create a WebSocket connection, send messages, and receive responses.

What changes is how we manage the connection and update the UI.

Assume we’re using React with Vite.

Our project structure will look like this:

src/
    App.jsx

We’ll use the same Node.js WebSocket server from the previous example.

Step 1: Create the React component

Create App.jsx:

import { useEffect, useRef, useState } from "react";

function App() {
  const socketRef = useRef(null);
  const [message, setMessage] = useState("");
  const [messages, setMessages] = useState([]);
  const [status, setStatus] = useState("Connecting...");

  useEffect(() => {
    const socket = new WebSocket("ws://localhost:8080");
    socketRef.current = socket;
    socket.onopen = () => {
      setStatus("Connected");
    };
    socket.onmessage = (event) => {
      setMessages((prevMessages) => [...prevMessages, event.data]);
    };
    socket.onclose = () => {
      setStatus("Disconnected");
    };
    socket.onerror = (error) => {
      console.error("WebSocket error:", error);
      setStatus("Connection error");
    };
    return () => {
      socket.close();
      socketRef.current = null;
    };
  }, []);

  const handleSend = () => {
    const trimmedMessage = message.trim();
    const socket = socketRef.current;
    if (!trimmedMessage) return;
    if (!socket || socket.readyState !== WebSocket.OPEN) {
      setStatus("Not connected");
      return;
    }
    socket.send(trimmedMessage);
    setMessage("");
  };

  return (
    <div>
      <h1>WebSocket in React</h1>
      <p>Status: {status}</p>
      <input
        value={message}
        onChange={(event) => setMessage(event.target.value)}
        placeholder="Enter your message"
      />
      <button onClick={handleSend}>Send Message</button>
      <h3>Messages</h3>
      <ul>
        {messages.map((item, index) => (
          <li key={index}>{item}</li>
        ))}
      </ul>
    </div>
  );
}

export default App;

That’s it! We’ve implemented the same WebSocket communication flow in React.

Let’s understand the two most important concepts in this implementation.

6. Why Do We Store the WebSocket Instance in useRef?

This is a common question in React interviews.

Look at this line:

const socketRef = useRef(null);

We use useRef to store a reference to the WebSocket instance.

Later, when we create the connection, we assign it:

const socket = new WebSocket("ws://localhost:8080");

socketRef.current = socket;

When the user clicks the Send Message button, we access the same instance:

const socket = socketRef.current;

if (socket?.readyState === WebSocket.OPEN) {
  socket.send(message);
}

But why don’t we create a new WebSocket directly inside the component?

What happens if we create a WebSocket during every render?

Consider this incorrect approach:

function App() {
  const socket = new WebSocket("ws://localhost:8080");

  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

Every time React renders this component, the component function runs again.

That means a new WebSocket connection is initiated on each render.

Imagine the following sequence:

Initial Render
      |
      v
WebSocket A created

User clicks button
      |
      v
State changes
      |
      v
Component renders again
      |
      v
WebSocket B created

User clicks again
      |
      v
Component renders again
      |
      v
WebSocket C created

The previous connections aren’t automatically closed just because React rendered again.

This can result in multiple unnecessary connections, duplicated messages, wasted resources, and difficult-to-debug behavior.

A React component can render many times, but we generally want to maintain one connection for its intended lifetime.

How does useRef solve the problem?

A ref provides a stable object whose .current property persists across renders.

const socketRef = useRef(null);

React preserves that ref object between renders. Updating .current doesn't trigger a re-render.

We create the WebSocket inside useEffect:

useEffect(() => {
  const socket = new WebSocket("ws://localhost:8080");

  socketRef.current = socket;
    return () => {
      socket.close();
      socketRef.current = null;
    };
}, []);

The empty dependency array means the Effect doesn’t rerun after every ordinary re-render. It sets up the connection after mounting and cleans it up when the component unmounts.

In development, React Strict Mode can perform an additional setup-and-cleanup cycle. This is intentional and helps reveal lifecycle bugs.

The resulting flow is:

Component mounts
       |
       v
Effect creates WebSocket
       |
       v
socketRef.current = Socket A
       |
       v
User sends a message
       |
       v
State updates
       |
       v
Component re-renders
       |
       v
Same ref object
       |
       v
Same WebSocket A

We don’t initiate a new connection on every render.

Why not use useState for the WebSocket?

You technically can store a WebSocket instance in state, but it usually isn’t necessary.

useState

• Stores data that affects the UI.
• Updating state triggers a re-render.
• The WebSocket instance itself doesn’t usually need to be rendered.

useRef

• Stores a mutable reference across renders.
• Updating .current doesn't trigger a re-render.
• Works well for imperative objects such as WebSockets, Web Workers, and DOM references.

The WebSocket instance is an external resource that we need to interact with. It isn’t UI data.

That’s why useRef is a natural choice.

Meanwhile, messages and connection status belong in state:

const [messages, setMessages] = useState([]);
const [status, setStatus] = useState("Connecting...");

When a message arrives, we update state:

socket.onmessage = (event) => {
  setMessages((prevMessages) => [
    ...prevMessages,
    event.data
  ]);
};

React then renders the updated messages.

The key distinction is:

useRef manages the connection; useState manages the UI.

One nuance worth remembering: useRef by itself doesn't prevent a new WebSocket from being created on every render. The important part is creating the connection inside a lifecycle-managed Effect and using the ref to retain access to that instance.

7. What Happens When the WebSocket Disconnects?

Real-world connections aren’t permanent.

A connection can close because of:

• Network interruptions.
• Server restarts.
• Browser or device connectivity changes.
• Server-side idle timeouts.
• Application shutdown.

In our example, we handle a close event:

socket.onclose = () => {
  setStatus("Disconnected");
};

But displaying a disconnected status isn’t enough for a production application.

A chat application, for example, may need to reconnect automatically.

A basic reconnection strategy

Conceptually, the flow might look like this:

WebSocket disconnects
         |
         v
Wait before reconnecting
         |
         v
Attempt a new connection
         |
    +----+----+
    |         |
 Success    Failure
    |         |
    v         v
Connected   Wait longer
              |
              v
        Retry connection

A common technique is exponential backoff, where the delay increases after consecutive failures.

For example:

Attempt 1 → Wait 1 second
Attempt 2 → Wait 2 seconds
Attempt 3 → Wait 4 seconds
Attempt 4 → Wait 8 seconds

In production, you’d typically cap the delay and add jitter to avoid many clients reconnecting simultaneously.

You should also consider:

• Cleaning up pending timers.
• Avoiding duplicate connections.
• Detecting when the user is intentionally disconnecting.
• Re-authenticating if necessary.
• Resubscribing to the required channels or topics.
• Handling messages that were missed while disconnected.

Our beginner example intentionally doesn’t implement reconnection logic so that the core communication flow remains easy to understand.

8. When Should You Use WebSockets?

WebSockets are especially useful when an application requires ongoing, low-latency communication between the browser and server.

Common examples include:

1. Chat applications

Messages can be delivered to connected users without repeated polling.

2. Live notifications

Applications can push new notifications when events occur.

3. Real-time dashboards

Monitoring dashboards can receive live updates from the backend.

4. Multiplayer games

Players can exchange frequent state updates with a game server.

5. Collaborative applications

Multiple users can exchange editing or presence updates in near real time.

6. Live order tracking

A delivery or order-status page can receive updates as the backend reports new events.

However, WebSockets aren’t necessary for every API interaction.

If a page simply needs to fetch a product list once, a normal HTTP request is usually sufficient.

If the server needs to stream updates in one direction, Server-Sent Events (SSE) may be a simpler option.

The correct choice depends on how frequently data changes, which direction messages need to travel, and how the application handles connections.

9. WebSockets vs HTTP vs Server-Sent Events

It’s useful to understand how these technologies differ.

HTTP request-response

Client → Request → Server
Client ← Response ← Server

Best suited for fetching data, submitting forms, and ordinary API operations.

WebSockets

Client ⇄ Server

Supports two-way communication over a persistent connection.

Best suited for chat, interactive real-time features, and frequent bidirectional messaging.

Server-Sent Events (SSE)

Client → Establish connection → Server
Client ← Updates ← Server

Provides a persistent connection for server-to-client event streaming. The client normally uses HTTP to establish the stream, and the server sends events over it.

Best suited for live feeds, progress updates, and notifications when the client doesn’t need a bidirectional messaging channel.

Remember: WebSockets don’t automatically guarantee delivery of every message across disconnections. If your application needs reliable message history, acknowledgements, or recovery after reconnecting, you’ll need to design those features at the application or protocol level.

10. Important Security Considerations

A persistent connection still needs the same careful security thinking as other network communication.

Keep these points in mind:

• Use wss:// in production. This encrypts communication using TLS.
• Authenticate connections. Establish how the server identifies the user.
• Authorize messages. Being connected doesn’t mean the user can perform every action.
• Validate incoming data. Never blindly trust client messages.
• Consider Cross-Site WebSocket Hijacking. Validate the Origin header and use appropriate authentication and CSRF-related protections for cookie-authenticated connections.
• Handle connection limits. A server must be prepared to manage large numbers of concurrent clients.
• Avoid logging sensitive data. Authentication tokens, private messages, and personal information should not be exposed in logs.

WebSockets provide the communication channel, but the application remains responsible for security, permissions, validation, and business logic.

Conclusion

WebSockets are a powerful browser technology for building real-time applications.

We’ve learned that:

• Traditional HTTP request-response communication is useful for ordinary API operations.
• Polling repeatedly asks the server whether new information is available.
• WebSockets establish a persistent, bidirectional communication channel.
• send() transmits messages, while onmessage receives them.
• A WebSocket application needs both a client and a server.
• In React, useRef stores the connection instance across renders.
• useEffect manages the connection lifecycle and cleanup.
• useState updates the UI when messages or connection status change.
• Real-world applications need to consider reconnection, authentication, authorization, and error handling.

The key takeaway is simple:

Use HTTP when you need ordinary request-response communication, and consider WebSockets when your application needs ongoing, bidirectional communication with the server.

Once you understand this pattern, you can apply it to chat applications, live dashboards, collaborative tools, and other real-time experiences.

What’s Next?

Now that you understand the basics of WebSockets, here are some topics worth exploring next:

• WebSockets vs SSE vs Long Polling: Understand which communication strategy fits different use cases.
• WebSocket Reconnection: Implement exponential backoff, retry limits, and connection recovery.
• WebSockets in React: Build a reusable custom hook that manages connection setup, messages, and cleanup.
• WebSocket Authentication: Learn how to authenticate connections and authorize messages securely.
• Scaling WebSocket Applications: Explore how multiple backend instances coordinate events using a shared messaging system.
• WebSocket vs Web Worker: Understand the difference between background computation and real-time network communication.

Happy coding! ✌️

WebSockets in JavaScript: A Beginner’s Guide to Real-Time Communication was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Have you ever clicked a button on a website and noticed that the entire page becomes unresponsive for a few seconds?

Maybe the application is processing a large dataset, performing complex calculations, filtering thousands of records, or parsing a huge JSON file.

The browser feels frozen. Animations stop, buttons stop responding, and the user has to wait until the operation finishes.

Why does this happen, and how can we prevent it?

One solution is to use Web Workers.

Web Workers allow JavaScript to execute tasks in a background thread, separate from the main thread that handles the user interface. This helps keep the UI responsive while computationally expensive work is running.

In this article, we’ll understand Web Workers from scratch, learn how they communicate with the main thread, build a simple example using HTML and JavaScript, and then implement the same example in React.

No prior knowledge of Web Workers is required.

1. First, Understand the Problem

Before learning about Web Workers, let’s understand how JavaScript typically executes code in a browser.

JavaScript running on the main thread is responsible for executing application code and coordinating UI-related work, including DOM updates, event handlers, and rendering-related tasks.

Consider this example:

console.log("Start");

let sum = 0;
for (let i = 0; i < 1000000000; i++) {
  sum += i;
}

console.log("Calculation completed");

The loop performs a large number of calculations synchronously.

While this loop is running, the browser’s main thread cannot process other JavaScript tasks normally. As a result, the UI may become unresponsive.

Imagine this happening in a React application while a user is typing in a search box or clicking a button.

That’s a poor user experience.

The problem isn’t that JavaScript cannot perform calculations. The problem is where those calculations are running.

2. What Is a Web Worker?

A Web Worker is a browser API that allows JavaScript code to run in a separate background thread.

Instead of performing a computationally expensive operation on the main thread, we can move that operation into a separate JavaScript file and execute it inside a Worker.

Conceptually, the architecture looks like this:

Browser
                    |
          +---------+---------+
          |                   |
      Main Thread         Worker Thread
          |                   |
     UI and DOM            Heavy work
     Event handlers        Calculations
     User interactions     Data processing
          |                   |
          +---- Messages -----+

The main thread remains responsible for the user interface, while the Worker performs its assigned task.

For example, suppose your application needs to process a large dataset.

Without a Worker:

Main Thread
    |
    | Process 10 million records
    |
    | UI may become unresponsive
    |
    v
Calculation completed

With a Worker:

Main Thread                 Worker Thread
     |                            |
     | Send data ---------------->|
     |                            | Process records
     | UI remains responsive      | Perform calculation
     |                            |
     |<---------------- Send result
     |
     v
Update UI

This is the basic idea behind Web Workers.

Important things to know

• A Worker runs separately from the page’s main JavaScript thread.
• A Worker cannot directly access the page’s DOM.
• A Worker communicates with the main thread through messages.
• A Worker has its own JavaScript execution context.
• Workers are useful for CPU-intensive tasks, not for making every asynchronous operation faster.

One important distinction: Web Workers don’t automatically make a calculation faster. Their primary benefit is that the work no longer blocks the main thread. They can also use additional CPU resources, depending on the task and available hardware.

3. How Does a Web Worker Exchange Data?

This is one of the most important concepts to understand.

The main thread and the Worker do not normally share ordinary JavaScript variables.

For example, this variable in your main JavaScript file:

let count = 10;

isn’t automatically available inside your Worker.

Instead, the two communicate using a message-passing mechanism.

There are four important concepts:

new Worker() — Creates a Worker instance.

postMessage() — Sends a message to the other side.

onmessage — Receives messages from the other side.

terminate() — Immediately stops a Worker when you no longer need it.

The communication flow looks like this:

Main Thread                      Worker
     |                              |
     | new Worker("worker.js")      |
     |----------------------------->|
     |                              |
     | postMessage(input)           |
     |----------------------------->|
     |                              |
     |                         onmessage
     |                         Process input
     |                              |
     |<-----------------------------|
     |         postMessage(result)  |
     |                              |
     | onmessage                    |
     | Receive result               |

How is data transferred?

When you call postMessage(), the browser generally uses the structured clone algorithm to copy supported data into the receiving context.

For example:

worker.postMessage({
  type: "calculate",
  number: 100
});

The Worker receives a corresponding message:

self.onmessage = (event) => {
  console.log(event.data.number); // 100
};

The Worker can then send a response:

self.postMessage({
  result: 5050
});

And the main thread receives it:

worker.onmessage = (event) => {
  console.log(event.data.result); // 5050
};

You can send supported objects, arrays, strings, numbers, and other structured-cloneable values.

Some values, such as functions and DOM nodes, cannot be cloned this way.

For large binary data, transferable objects such as ArrayBuffer can be useful because ownership can be transferred instead of copying the underlying data. We'll leave that advanced topic for another article.

Now let’s build something practical.

4. Build Your First Web Worker Using HTML and JavaScript

We’ll create a small application that calculates the sum of numbers from 1 to 50 million.

The user clicks a button, the Worker performs the calculation, and the result appears on the page.

Our project contains three files:

web-worker-demo/
    index.html
    main.js
    worker.js

Step 1: Create the HTML file

Create index.html:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>Web Worker Demo</title>
</head>
<body>
  <h1>Web Worker Demo</h1>
  <button id="calculateBtn">
    Calculate Sum
  </button>
  <p id="status">Ready</p>
  <p id="result"></p>
  <script src="./main.js"></script>
</body>
</html>

The page contains a button, a status message, and a place to display the result.

Step 2: Create the Worker file

Create worker.js:

self.onmessage = (event) => {
  const number = event.data;
  let sum = 0;

  for (let i = 1; i <= number; i++) {
    sum += i;
  }
  self.postMessage(sum);
};

Let’s understand what happens here.

self refers to the Worker's global scope.

self.onmessage listens for messages sent from the main thread.

When a message arrives, the Worker reads the number from event.data and performs the calculation.

Finally:

self.postMessage(sum);

sends the calculated result back to the main thread.

Notice that the Worker doesn’t access document.getElementById() or update the HTML. It only performs the calculation and sends back the result.

Step 3: Connect the Worker to the main thread

Create main.js:

const calculateBtn = document.getElementById("calculateBtn");
const status = document.getElementById("status");
const result = document.getElementById("result");
const worker = new Worker("./worker.js");
calculateBtn.addEventListener("click", () => {
    status.textContent = "Calculating...";
    result.textContent = "";
    worker.postMessage(50000000);
});
worker.onmessage = (event) => {
    result.textContent = `Result: ${event.data}`;
    status.textContent = "Calculation completed!";
};
worker.onerror = (event) => {
    status.textContent = "Something went wrong.";
    console.error(event.message);
};

Step 4: Run the application

Run the project using a local development server. For example, you can use the Live Server extension in VS Code.

Avoid opening the HTML file directly through a file:// URL, because browser security restrictions can interfere with Worker loading.

Click Calculate Sum.

The application sends 50000000 to the Worker. The Worker performs the calculation and sends the result back.

The result will be:

1250000025000000

While the calculation is running, try clicking other parts of the page or selecting text. The page should remain responsive because the calculation is running outside the main thread.

The exact calculation time depends on your device and browser.

What did we accomplish?

Let’s summarize the flow:

1. The main thread creates a Worker.
2. The user clicks the button.
3. The main thread sends a number using postMessage().
4. The Worker receives the number through onmessage.
5. The Worker calculates the sum.
6. The Worker sends the result back using postMessage().
7. The main thread receives the result and updates the UI.

That’s a complete, working example of Web Worker communication.

5. Implement the Same Example in React

Now let’s implement the same functionality in React.

The calculation remains exactly the same. The difference is how we manage the Worker instance and update the UI.

For this example, assume you’re using React with Vite.

Our files will look like this:

src/
    App.jsx
    sum.worker.js

Step 1: Create the Worker

Create sum.worker.js:

self.onmessage = (event) => {
  const number = event.data;
  let sum = 0;

  for (let i = 1; i <= number; i++) {
    sum += i;
  }
  self.postMessage(sum);
};

This is the same Worker we created earlier.

The Worker doesn’t need to know whether the main thread belongs to a plain JavaScript application or a React application.

It only needs to receive a message, perform its work, and return the result.

Step 2: Create the React component

Create App.jsx:

import { useEffect, useRef, useState } from "react";

function App() {
  const workerRef = useRef(null);
  const [result, setResult] = useState(null);
  const [status, setStatus] = useState("Ready");

  useEffect(() => {
    const worker = new Worker(
      new URL("./sum.worker.js", import.meta.url),
      { type: "module" }
    );
    workerRef.current = worker;
    worker.onmessage = (event) => {
      setResult(event.data);
      setStatus("Calculation completed!");
    };
    worker.onerror = (event) => {
      setStatus("Something went wrong.");
      console.error(event.message);
    };
    return () => {
      worker.terminate();
      workerRef.current = null;
    };
  }, []);

  const handleCalculate = () => {
    setStatus("Calculating...");
    setResult(null);
    workerRef.current?.postMessage(50000000);
  };

  return (
    <div>
      <h1>Web Worker in React</h1>
      <button onClick={handleCalculate}>
        Calculate Sum
      </button>
      <p>{status}</p>
      {result !== null && (
        <p>Result: {result}</p>
      )}
    </div>
  );
}

export default App;

The example uses Vite’s Worker-friendly URL pattern so the bundler can resolve the Worker file correctly.

Let’s focus on the most important part of this implementation.

6. Why Do We Store the Worker Instance in useRef?

This is a common interview question, and understanding the reason is more important than memorizing the code.

Look at this line:

const workerRef = useRef(null);

We use useRef to store a reference to the Worker instance.

Later, we assign the instance:

workerRef.current = worker;

And when the user clicks the button, we access it:

workerRef.current?.postMessage(50000000);

But why not simply create the Worker inside the component?

What happens if we create a Worker during every render?

Consider this incorrect approach:

function App() {
  const worker = new Worker(
    new URL("./sum.worker.js", import.meta.url),
    { type: "module" }
  );

  const [count, setCount] = useState(0);
  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

Every time the component renders, JavaScript executes the component function again.

That means a new Worker is created each time.

For example:

Initial Render
      |
      v
Worker A created

User clicks button
      |
      v
State changes
      |
      v
Component renders again
      |
      v
Worker B created

User clicks button again
      |
      v
Component renders again
      |
      v
Worker C created

The previous Workers aren’t automatically terminated just because React rendered again.

This can cause unnecessary resource consumption and leave multiple Workers running.

The important point is that React components can render many times, but we usually want one Worker instance for the component’s lifetime.

How does useRef help?

A ref provides a stable object whose .current property persists across renders.

const workerRef = useRef(null);

React retains that ref object between renders. Updating workerRef.current does not trigger a new render.

In our implementation, we create the Worker inside useEffect:

useEffect(() => {
    const worker = new Worker(
        new URL("./sum.worker.js", import.meta.url), {
            type: "module"
        }
    );

    workerRef.current = worker;
    return () => {
        worker.terminate();
        workerRef.current = null;
    };
}, []);

The empty dependency array means the Effect doesn’t rerun after every ordinary re-render. React runs the Effect after mounting and performs cleanup when the component unmounts.

In development, React Strict Mode may run an extra setup-and-cleanup cycle to help detect bugs. That’s expected; the cleanup ensures that the temporary Worker is terminated.

Now the flow looks like this:

Component mounts
       |
       v
Effect creates Worker
       |
       v
workerRef.current = Worker A
       |
       v
User clicks button
       |
       v
State updates
       |
       v
Component re-renders
       |
       v
Same ref object
       |
       v
Same Worker A

We don’t create a new Worker on every render.

Why not use useState instead?

You technically can store an object in state, but it’s usually unnecessary for a Worker instance.

Compare the two:

useState

• Designed to store values that affect rendering.
• Updating state triggers a re-render.
• A Worker instance itself generally doesn’t need to be rendered.

useRef

• Stores a mutable reference across renders.
• Updating .current does not trigger a re-render.
• Useful for imperative objects such as Workers, DOM references, and WebSocket instances.

The Worker instance is an imperative resource, not UI data. That’s why useRef is a natural fit.

Meanwhile, the result and status belong in state:

const [result, setResult] = useState(null);
const [status, setStatus] = useState("Ready");

When the Worker returns a result, we call setResult(), which tells React to update the UI.

This gives us a useful separation:

useRef manages the Worker instance; useState manages the UI.

One nuance: useRef alone doesn't prevent Worker creation on every render. The real solution is to create the Worker inside an Effect (or another appropriate lifecycle-managed setup) and use the ref to retain access to that instance.

7. When Should You Use Web Workers?

Web Workers are especially useful when the main thread needs to stay responsive while performing CPU-intensive operations.

Common examples include:

• Processing large datasets.
• Performing complex calculations.
• Parsing large files or JSON payloads.
• Processing images or other binary data.
• Running computationally intensive algorithms.
• Performing client-side data transformations.
• Supporting certain AI or machine-learning workloads in the browser.

However, not every asynchronous operation needs a Worker.

For example, fetching data with fetch() is already asynchronous. You usually don't need a Worker simply to make an API request.

Similarly, small calculations that finish quickly may not justify the additional complexity of Worker creation and message passing.

Use a Worker when the work is sufficiently expensive to block the main thread.

8. Important Limitations to Remember

Before using Web Workers in a real application, keep these points in mind:

1. Workers cannot directly manipulate the DOM.

The Worker should send data back to the main thread, and the main thread should update the UI.

2. Communication has a cost.

Messages containing large objects can require significant copying and memory. Transferable objects can help with certain types of data.

3. Workers need lifecycle management.

Create them at the appropriate time and terminate them when they’re no longer needed.

4. Error handling matters.

Handle Worker errors and consider how the UI should respond if processing fails.

5. Workers don’t replace good algorithms.

An inefficient algorithm remains inefficient inside a Worker. Improve the algorithm when possible, and use a Worker to prevent expensive work from blocking the UI.

Conclusion

Web Workers are a useful browser feature for running JavaScript outside the main UI thread.

We’ve learned that:

• The main thread manages the UI.
• A Worker performs background computation.
• postMessage() and onmessage enable communication.
• The Worker can return results to the main thread.
• In React, useRef provides a stable reference to the Worker instance.
• useEffect is used to create the Worker and clean it up when appropriate.
• useState updates the UI when the result arrives.

The key takeaway is simple:

Keep UI rendering and interaction on the main thread, and move suitable CPU-intensive work into a Web Worker.

Once you understand this pattern, you can apply it to data processing, large-file handling, image processing, and other tasks that would otherwise make a web application feel slow.

What’s Next?

Now that you understand the basics of Web Workers, here are some topics worth exploring next:

• Web Workers vs Service Workers: Understand how background computation differs from caching, offline support, and network interception.
• Transferable Objects: Learn how to transfer ownership of an ArrayBuffer without copying its underlying data.
• Worker Communication: Explore request IDs, multiple concurrent tasks, and structured message formats.
• Web Worker Cleanup in React: Learn how to handle pending tasks, errors, cancellation, and component unmounting.
• Comlink: Explore a library that makes communicating with Web Workers feel more like calling ordinary functions.

Happy coding! ✌️

Web Workers in JavaScript: A Beginner’s Guide to Background Processing was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Authentication is one of those topics that every frontend developer eventually encounters.

You log in, the backend validates your credentials, and somehow the application needs to remember:

“This user is authenticated.”

But where should that authentication information be stored?

You will commonly come across three approaches:

1. Store a token in localstorage
2. Store a token in an httpOnly cookie
3. Use a server-side session with a Session ID

All three approaches can work. The important question is when should we use each one, and what security trade-offs do they introduce?

Let’s break them down from a frontend developer’s perspective.

First: What Are We Actually Storing?

Before comparing the three approaches, we need to understand one important distinction.

There are two common authentication models:

Token-based authentication

The server generates a token after successful login.

For example:

User → Login
        ↓
Backend validates credentials
        ↓
Backend generates token
        ↓
Browser stores token
        ↓
Browser uses token for future requests

The token could be a JWT:

eyJhbGciOiJIUzI1NiIs...

The backend can verify the token and determine who the user is.

Session-based authentication

Instead of putting all authentication information into a token, the server creates a session.

For example:

Session ID: abc123xyz

The server maintains something like:

abc123xyz → {
    userId: 101,
    role: "admin"
}

The browser only needs to send the Session ID.

This distinction becomes important when we compare the three approaches.

1. Storing a Token in localStorage

This is probably the easiest approach to understand.

After login, the backend returns a token:

{
  "accessToken": "abc123xyz"
}

The frontend stores it:

localStorage.setItem("accessToken", data.accessToken);

For future API requests:

const token = localStorage.getItem("accessToken");

fetch("/api/profile", {
  headers: {
    Authorization: `Bearer ${token}`
  }
});

The request looks conceptually like:

GET /api/profile
Authorization: Bearer abc123xyz

The backend reads the Authorization header and validates the token.

How the Flow Works

            Login
Browser ───────────────→ Backend
                          │
                          │ Validate credentials
                          │ Generate token
                          ↓
Browser ←─────────────── Token

        ↓

localStorage
accessToken = abc123xyz

        ↓

API Request
Authorization: Bearer abc123xyz

        ↓

Backend validates token

Advantages of localStorage

1. Simple to implement

It is very straightforward:

localStorage.setItem("token", token);

And later:

const token = localStorage.getItem("token");

2. Useful for APIs

You can explicitly attach the token to requests:

headers: {
  Authorization: `Bearer ${token}`
}

This is particularly convenient for applications communicating with APIs.

3. The browser doesn’t automatically send it

Unlike cookies, localStorage data isn't automatically attached to every HTTP request.

Your JavaScript code decides when to send it.

Disadvantages of localStorage

The biggest concern is XSS — Cross-Site Scripting.

JavaScript running on your page can access localStorage.

For example:

const token = localStorage.getItem("accessToken");

So if an attacker manages to execute malicious JavaScript in your application, that script may be able to read the token.

Conceptually:

// Malicious script
const token = localStorage.getItem("accessToken");

// Attacker could potentially send the token somewhere

That’s why storing sensitive authentication tokens in localStorage requires careful consideration of XSS protections.

Other considerations include:

• JavaScript can read the token.
• You have to manually attach the token to requests.
• You have to manually remove it during logout.
• Token theft can allow an attacker to impersonate the user until the token expires or is revoked.

When might we use localStorage?

You may encounter this approach in:

• Simple SPA applications
• Internal applications
• Learning projects
• Some API-driven frontend applications
• Applications where the team has consciously accepted the security trade-off

For security-sensitive production applications, you should carefully evaluate whether JavaScript-accessible token storage is appropriate.

2. Storing a Token in an HttpOnly Cookie

Now let’s look at cookies.

Instead of JavaScript storing the token:

localStorage.setItem("token", token);

the backend can instruct the browser to store it in a cookie.

For example, conceptually:

Set-Cookie: accessToken=abc123xyz;

A more secure authentication cookie would commonly look something like:

Set-Cookie:
  accessToken=abc123xyz;
  HttpOnly;
  Secure;
  SameSite=Lax;

The important part here is:

HttpOnly

An HttpOnly cookie cannot be accessed through JavaScript.

So this won’t work:

document.cookie

for retrieving that HttpOnly authentication cookie.

But the browser can still send it with applicable requests.

How the Flow Works

Login
Browser ───────────────→ Backend
                          │
                          │ Validate credentials
                          │ Generate token
                          ↓
Browser ←─────────────── Set-Cookie

        ↓

Browser stores cookie

        ↓

API Request
Cookie: accessToken=abc123xyz

        ↓

Backend reads cookie

        ↓

Validates token

The frontend doesn’t need to manually do:

Authorization: Bearer ...

The browser handles the cookie according to its cookie rules.

Conceptual Backend Code

For example, with Express:

res.cookie("accessToken", token, {
  httpOnly: true,
  secure: true,
  sameSite: "lax"
});

res.json({
  message: "Login successful"
});

The frontend simply makes the request.

For cross-origin requests where cookies need to be included, the client may need:

fetch("/api/profile", {
  credentials: "include"
});

The exact CORS and cookie configuration depends on how the frontend and backend are hosted.

Advantages of HttpOnly Cookies

1. JavaScript cannot read the authentication cookie

This is the biggest advantage.

If the cookie is:

HttpOnly

JavaScript cannot retrieve its value through normal browser APIs.

That makes token theft through a straightforward localStorage read much harder.

2. Browser handles the cookie

The application doesn’t have to manually retrieve the token and add:

Authorization: Bearer ...

to every request.

3. Secure cookies can be combined with additional protections

Common cookie attributes include:

HttpOnly
Secure
SameSite

Each serves a different purpose.

• HttpOnly → prevents JavaScript from reading the cookie.
• Secure → sends the cookie only over HTTPS.
• SameSite → controls when the browser sends the cookie in cross-site contexts.

Disadvantages of HttpOnly Cookies

Cookies introduce an important security consideration:

CSRF

Because the browser automatically sends applicable cookies with requests, an attacker may try to trick a user’s browser into making an unwanted authenticated request.

This is where protections such as:

SameSite
CSRF tokens
Origin/Referer validation

can become important, depending on the application’s architecture.

So:

HttpOnly does not mean “completely secure.”

It primarily protects the cookie from being directly read by JavaScript.

You still need to think about CSRF, XSS, HTTPS, cookie configuration, authorization, and other security controls.

When might we use HttpOnly Cookies?

This approach is commonly suitable for:

• Traditional web applications
• React/Vue/Angular applications with a backend
• Applications where strong browser-based authentication security is important
• Applications using JWT access/refresh tokens with cookie-based transport
• Applications where you don’t want JavaScript to directly access authentication credentials

A common modern pattern is:

Short-lived access token
        +
HttpOnly Secure refresh-token cookie

Although the exact architecture depends on the application’s requirements.

3. Session ID

Now let’s look at a different approach.

With a session-based authentication system, the server doesn’t necessarily send a JWT containing the user’s information.

Instead, after successful login, the server creates a session.

For example:

Session ID: abc123

The server stores something like:

abc123 → {
    userId: 101,
    role: "Admin"
}

The browser receives the Session ID, usually through a cookie:

Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax

The browser sends that cookie with subsequent requests.

How the Flow Works

Login
Browser ─────────────────────────→ Backend
                                    │
                                    │ Validate credentials
                                    │
                                    │ Create session
                                    ↓
                              Session Store
                              abc123 → user 101
                                    │
Browser ←───────────────────────────┘
        sessionId=abc123

        ↓

Next API request
Cookie: sessionId=abc123

        ↓

Backend

        ↓

Find abc123 in session store

        ↓

userId = 101

        ↓

Authorize request

Notice something important:

The browser doesn’t have the actual user session data.

It only has:

abc123

The actual session information lives on the server.

Conceptual Backend Code

With Express, you might use a session middleware:

app.use(
  session({
    secret: "my-secret",
    resave: false,
    saveUninitialized: false
  })
);

After login:

req.session.userId = user.id;

res.json({
  message: "Login successful"
});

Later:

app.get("/profile", (req, res) => {
  const userId = req.session.userId;

  // Fetch user and return profile
});

The session middleware handles the Session ID cookie and session lookup.

In a production system, the session store would typically be something designed for shared/server-side session storage rather than relying on the default in-memory store.

Advantages of Session-Based Authentication

1. Server has control over sessions

The server can invalidate a session immediately.

For example:

Session abc123 → deleted

The next request using that Session ID can be rejected.

2. Sensitive session information stays server-side

The browser only stores:

sessionId=abc123

The actual session data remains on the server.

3. Logout is straightforward

The backend can destroy the session:

req.session.destroy();

After that, the Session ID is no longer associated with an authenticated session.

Disadvantages of Session-Based Authentication

1. Server-side storage is required

The server needs to maintain session information.

For example:

abc123 → user 101
def456 → user 205
xyz789 → user 301

With a large application, this becomes an infrastructure consideration.

2. Scaling requires planning

Suppose you have:

Load Balancer
      ↓
 ┌────┴────┐
Server A  Server B

A user’s session might have been created on Server A.

If the next request goes to Server B, Server B needs access to the same session data.

This is why distributed session stores such as Redis are commonly used.

3. Session management becomes the server’s responsibility

You need to think about:

• Session expiration
• Idle timeout
• Session invalidation
• Session storage
• Session cleanup
• Scaling

Token vs Cookie vs Session — An Important Clarification

There is a common misconception that these are three completely independent technologies.

They aren’t.

localStorage, cookies, and Session IDs describe different parts of the authentication architecture.

For example:

JWT + localStorage

JWT
 ↓
localStorage
 ↓
Authorization header

JWT + HttpOnly cookie

JWT
 ↓
HttpOnly cookie
 ↓
Cookie header

Session ID + cookie

Session ID
 ↓
HttpOnly cookie
 ↓
Cookie header
 ↓
Server-side session store

So:

A cookie is a storage/transport mechanism. A Session ID is an identifier for server-side session state. A JWT is a token format.

This distinction is extremely important in interviews.

Side-by-Side Comparison

+----------------------------------+-------------------------+---------------------------+----------------------------+
| Feature                          | Token in localStorage   | Token in HttpOnly Cookie | Session ID                 |
+----------------------------------+-------------------------+---------------------------+----------------------------+
| Authentication model             | Token-based             | Token-based               | Session-based              |
| Stored in                        | localStorage            | Cookie                    | Usually cookie             |
| JavaScript can read credential?  | Yes                     | No, if HttpOnly            | No, if HttpOnly             |
| Automatically sent?              | No                      | Yes, when rules allow      | Yes, when rules allow       |
| Server-side session required?    | Usually no              | Usually no for JWT        | Yes                        |
| XSS credential exposure          | Higher                  | Reduced                   | Reduced                    |
| CSRF consideration               | Less direct             | Important                 | Important                  |
| Server can invalidate?           | Not inherently          | Depends on token design   | Yes                        |
| Scaling                          | Easier for stateless    | Easier for stateless JWTs | Requires shared storage    |
| Typical use                      | SPAs / API applications | Web applications          | Server-backed applications |
+----------------------------------+-------------------------+---------------------------+----------------------------+

So Which One Should You Choose?

There isn’t a universal answer.

The right choice depends on the application architecture and its security requirements.

Scenario 1: Simple SPA + API

You might see:

React
   ↓
REST API
   ↓
Backend

A token-based approach can work well.

Historically, many applications have stored access tokens in localStorage, but this comes with an increased XSS exposure because JavaScript can read the token.

Scenario 2: Production web application

For a browser-based application where you want authentication credentials protected from JavaScript access, an HttpOnly, Secure cookie is often a strong choice.

You still need to handle:

XSS
CSRF
SameSite
CORS
HTTPS
Authorization
Token/session expiration

Security is never achieved by one setting alone.

Scenario 3: Traditional backend application

If your application is heavily server-backed and you want the server to maintain authentication state:

Browser
   ↓
Session ID
   ↓
Server
   ↓
Session Store

Session-based authentication can be a very good fit.

What About Refresh Tokens?

You may have heard another pattern:

Access Token
+
Refresh Token

A common architecture is:

Access Token
    ↓
Short lifetime
    ↓
Used for API access
    ↓
Refresh Token
    ↓
Longer lifetime
    ↓
Stored in HttpOnly Secure cookie
    ↓
Used to obtain a new access token

For example:

Login
  ↓
Access Token + Refresh Token
  ↓
Access token used for API calls
  ↓
Access token expires
  ↓
Refresh token sent to refresh endpoint
  ↓
Backend validates refresh token
  ↓
New access token generated

This is another layer of the authentication architecture rather than a completely separate storage method.

A Simple Mental Model

If you struggle to remember all of this during an interview, remember these three questions:

Question 1: Where is the credential stored?

localStorage?
Cookie?

Question 2: Can JavaScript access it?

localStorage → Yes

HttpOnly cookie → No

Question 3: Is authentication state stored on the server?

JWT → Usually noSession ID → Yes

That gives you a very simple mental model:

Authentication
                         │
          ┌──────────────┴──────────────┐
          │                             │
       Token                         Session
          │                             │
     ┌────┴────┐                        │
     │         │                        │
localStorage  Cookie              Session ID
     │         │                        │
     │      HttpOnly                 Cookie
     │
JavaScript
accessible

What I Would Say in an Interview

If an interviewer asks:

“Where would you store an authentication token?”

Don’t immediately answer:

“localStorage.”

Instead, explain the trade-off.

A strong answer would be:

“It depends on the application’s security and architecture requirements. Storing a token in localStorage is simple, but JavaScript can access it, so an XSS vulnerability could expose the token. For browser-based applications, I would generally consider Secure, HttpOnly cookies because JavaScript cannot directly read the authentication credential. However, cookie-based authentication introduces CSRF considerations, so I would configure SameSite appropriately and use additional CSRF protections when required. If the application uses server-side sessions, the browser can store only an opaque Session ID while the actual authentication state remains on the server.”

That answer demonstrates much more understanding than simply saying:

“Use cookies because they’re secure.”

Final Takeaway

There is no magical authentication storage mechanism that makes an application automatically secure.

Each approach has trade-offs.

localStorage
    ↓
Simple
    ↓
JavaScript can access credential
    ↓
Greater XSS exposure

HttpOnly Cookie
    ↓
JavaScript cannot directly access credential
    ↓
Browser automatically sends cookie
    ↓
Need to consider CSRF

Session ID
    ↓
Browser stores only an identifier
    ↓
Actual session state lives on server
    ↓
Requires session management and shared storage when scaling

The key is to understand what is being stored, who can access it, how it reaches the server, and what happens if an attacker gets hold of it.

That’s the real authentication discussion.

Happy coding! ✌️

Where Should You Store Authentication Credentials? localStorage vs HttpOnly Cookies vs Session IDs was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Adding Temperature Controls and Multi-Model Support to My AI Chat Application 🚀

Over the past few weeks, my AI Chat application has evolved from a simple chat interface into a more configurable AI platform. After implementing voice preferences and a complete theme system, today’s focus was on giving users more control over how the AI behaves and which model powers their conversations.

The two major features implemented today were:

1. Temperature Settings
2. GPT-4o Model Integration

Both of these features were added through the Settings system that was built during previous weeks.

Why Temperature Matters

Most users interact with AI without realizing that the same model can behave very differently depending on a parameter called temperature.

Temperature controls how deterministic or creative the model’s responses are.

Lower values make responses more predictable and consistent, while higher values increase creativity and variation.

To expose this control to users, I introduced the following options inside the Settings modal:

const TEMPERATURE_OPTIONS = [
  { value: 0, label: '0.0 — Deterministic' },
  { value: 0.3, label: '0.3 — Focused' },
  { value: 0.5, label: '0.5 — Balanced' },
  { value: 0.7, label: '0.7 — Creative' },
  { value: 1, label: '1.0 — Very Creative' },
]

Understanding Temperature Levels

+-------------+-------------------------------+
| Temperature | Behaviour                     |
+-------------+-------------------------------+
| 0.0         | Highly predictable            |
| 0.3         | Focused and factual           |
| 0.5         | Balanced responses            |
| 0.7         | More creative                 |
| 1.0         | Highly creative and diverse   |
+-------------+-------------------------------+

For most users, 0.5 provides the best balance between creativity and accuracy.

Where Temperature Is Applied

One important architectural decision was determining where temperature should actually be used.

Initially, I considered applying it everywhere, including:

• Chat conversations
• Chat title generation
• Conversation summarization

However, after analyzing the use cases, I decided against it.

Chat Conversations

Temperature should affect the main AI conversation because users directly experience those responses.

Example:

User Question
      ↓
Temperature Applied
      ↓
AI Response

Chat Title Generation

Titles should be short, consistent, and predictable.

For example:

How to Learn React Efficiently?

should always become something similar to:

React Learning Roadmap

and not vary wildly based on creativity settings.

Conversation Summaries

Summaries should remain factual and deterministic.

A summary feature exists to preserve context, not generate creative interpretations.

Applying high temperature here could introduce unnecessary variation or inaccuracies.

Because of this, temperature is currently applied only to the main chat flow.

Adding GPT-4o Support

Until now, the application exclusively used:

GPT-4o Mini

which provides an excellent balance between performance, cost, and response quality.

Today’s goal was to give users a second option:

GPT-4o

Why GPT-4o?

Before integrating additional models, I evaluated the complexity involved.

GPT-4o was selected because:

+----------------------+----------------------------+
| Reason               | Benefit                    |
+----------------------+----------------------------+
| Same OpenAI SDK      | Minimal implementation     |
| Same Response Format | No architecture changes    |
| Same Streaming API   | Existing logic reusable    |
| Same Tool Calling    | Existing tools work        |
| Same Vision Support  | Existing image flow works  |
+----------------------+----------------------------+

Since GPT-4o and GPT-4o Mini share the same API structure, the implementation was surprisingly straightforward.

Previously:

model: "gpt-4o-mini"

Now:

model: settings.model

The rest of the backend logic remains unchanged.

Model Selection Options

Users can now select between:

const MODEL_OPTIONS = [
  {
    value: "gpt-4o-mini",
    label: "⚡ GPT-4o Mini",
  },
  {
    value: "gpt-4o",
    label: "🧠 GPT-4o",
  },
];

This selection is stored in the user-specific Settings API and automatically loaded when the user returns to the application.

Why We Didn’t Add Gemini or Claude Yet

At first glance, adding Gemini or Claude may seem similar to adding GPT-4o.

However, the reality is much more complicated.

Different AI providers expose different APIs.

For example:

OpenAI

response.choices[0].message.content

Gemini

response.candidates[0]
        .content.parts[0].text

Claude

response.content[0].text

Although all three models produce text, the response structures differ significantly.

Additional Complexity Introduced by Multiple Providers

Integrating models from multiple companies would impact:

+----------------------+----------------------------+
| System               | Additional Complexity      |
+----------------------+----------------------------+
| Streaming            | Different APIs             |
| Tool Calling         | Different formats          |
| Vision               | Different payloads         |
| Error Handling       | Different responses        |
| Rate Limits          | Different restrictions     |
| SDK Management       | Multiple SDKs             |
+----------------------+----------------------------+

If implemented naively, the chat controller would quickly become difficult to maintain.

Future Architecture Plan

Instead of rushing into multi-provider support, I want to build a scalable foundation first.

The long-term architecture will likely look like this:

providers/
├── openai.js
├── gemini.js
├── claude.js
services/
├── llmService.js

Each provider will expose a common interface while internally handling provider-specific differences.

This approach keeps the main chat controller clean and maintainable.

Current Model Strategy

For now, the application follows this approach:

+----------------------+----------------+
| Feature              | Model          |
+----------------------+----------------+
| Main Chat            | User Selected  |
| Generate Chat Title  | GPT-4o Mini    |
| Chat Summarization   | GPT-4o Mini    |
+----------------------+----------------+

This ensures that expensive models are only used where users directly benefit from them.

Key Takeaways

Today’s work was less about adding flashy features and more about improving configurability and future scalability.

By introducing temperature controls, users can now customize how the AI behaves.

By integrating GPT-4o support, the application takes its first step toward becoming a true multi-model AI platform.

Most importantly, instead of immediately integrating models from multiple providers and creating architectural chaos, I chose to first build a foundation that can support such expansion cleanly in the future.

🔗 Live Demo & Code

👉 Live App:
https://ai-chat-app-learning.netlify.app

👉 GitHub Repo:
https://github.com/RohitKuwar/ai-chat-app/tree/feature/settings-temperature-models

🚀 What’s Next

Today I implemented user-controlled temperature settings and added GPT-4o as a second model option while keeping the architecture simple and maintainable.

Next, I’ll continue expanding the AI platform by strengthening the model management architecture, improving file handling with cloud storage, and preparing the codebase for future support of providers like Gemini and Claude through a scalable adapter-based design.

I’ll be posting here daily as I learn. Let’s grow together and stay ahead in the AI era 🚀

Happy learning ✌️

Implementing a Complete Theme System for My AI Chat Application 🎨

One of the most noticeable aspects of any application is its visual appearance. Users spend hours interacting with interfaces, and a well-designed theme can significantly improve usability, readability, and overall experience.

Today I worked on implementing a scalable theme system for my AI Chat application. Instead of hardcoding colors throughout the codebase, I centralized all color definitions using CSS custom properties (variables), making the application easier to maintain and extend.

Why Refactor the Existing Styling?

Initially, most UI colors were directly hardcoded inside component styles and CSS classes.

Example:

background: #020617;
color: #f1f5f9;
border: rgba(255, 255, 255, 0.1);

While this works for a single theme, it quickly becomes difficult to manage when introducing multiple themes.

Problems with this approach:

• Color values get repeated throughout the project.
• Updating a color requires searching multiple files.
• Supporting additional themes becomes cumbersome.
• Maintaining visual consistency becomes difficult.

To solve this, I moved all theme-related colors into centralized CSS variables.

Creating a Theme Foundation with CSS Variables

I introduced a global theme configuration using CSS custom properties.

Default Theme (Dark Navy)

:root {
  /* ── Backgrounds ── */
  --bg-gradient:        linear-gradient(135deg, #020617, #0f172a);
  --bg-deep:            #020617;
  --bg-secondary:       #0f172a;
  --bg-sidebar:         #171717;
  --bg-chat-box:        #111827;
  --bg-surface:         #1e293b;
  --bg-message-ai:      #1e293b;
  --bg-message-ai-alt:  #1f2937;
  --bg-message-user:    linear-gradient(135deg, #2563eb, #1d4ed8);
  --bg-input:           #020617;
  --bg-dropdown:        #1a2035;
  --bg-modal:           #1c202f;
  --bg-modal-alpha:     rgba(15, 18, 32, 0.95);
  --bg-modal-sticky:    rgba(15, 18, 32, 0.98);

  /* ── Text ── */
  --text-primary:       #f1f5f9;
  --text-primary-soft:  #e2e8f0;
  --text-secondary:     #cbd5e1;
  --text-muted:         #9b9b9b;
  --text-dim:           #64748b;
  --text-faint:         #5e5e5e;

  /* ── Accent (Indigo) ── */
  --accent:             #818cf8;
  --accent-hover:       #4f46e5;
  --accent-light:       #a5b4fc;
  --accent-blue:        #3b82f6;
  --accent-soft:        rgba(99, 102, 241, 0.12);
  --accent-soft-2:      rgba(99, 102, 241, 0.08);
  --accent-soft-3:      rgba(99, 102, 241, 0.15);
  --accent-border:      rgba(99, 102, 241, 0.2);
  --accent-border-mid:  rgba(99, 102, 241, 0.4);

  /* ── Borders ── */
  --border:             rgba(255, 255, 255, 0.1);
  --border-soft:        rgba(255, 255, 255, 0.08);
  --border-subtle:      rgba(255, 255, 255, 0.06);
  --border-faint:       rgba(255, 255, 255, 0.04);
  --border-input:       #334155;
  --border-code:        #1f2937;

  /* ── Semantic ── */
  --danger:             #f87171;
  --danger-light:       #fca5a5;
  --success:            #22c55e;
  --success-light:      #4ade80;

  /* ── Scrollbars ── */
  --scrollbar:          #2e2e2e;
  --scrollbar-mid:      #374151;
  --scrollbar-dark:     #1e2240;
}

Now UI components no longer depend on hardcoded colors.

Instead of:

background: #020617;

I can simply use:

background: var(--bg-deep);

This creates a single source of truth for all design tokens.

Implementing Light Mode

Once the foundation was in place, adding new themes became much easier.

For Light Mode, I only needed to override the variables:

[data-theme="light"] {
  /* ── Backgrounds ── */
  --bg-gradient:        linear-gradient(135deg, #eef2f7, #e8edf5);
  --bg-deep:            #eef2f7;
  --bg-secondary:       #e2e8f2;
  --bg-sidebar:         #dde3ee;
  --bg-chat-box:        #eef2f7;
  --bg-surface:         #d6dce8;
  --bg-message-ai:      #e8edf5;
  --bg-message-ai-alt:  #dde3ee;
  --bg-message-user:    linear-gradient(135deg, #2563eb, #1d4ed8);
  --bg-input:           #e2e8f2;
  --bg-dropdown:        #dde3ee;
  --bg-modal:           #eef2f7;
  --bg-modal-alpha:     rgba(238, 242, 247, 0.97);
  --bg-modal-sticky:    rgba(238, 242, 247, 0.98);

  /* ── Text ── */
  --text-primary:       #1a2035;
  --text-primary-soft:  #2d3a52;
  --text-secondary:     #3d4f6e;
  --text-muted:         #5a6e8c;
  --text-dim:           #7a8faa;
  --text-faint:         #a0b0c4;

  /* ── Accent (Indigo) ── */
  --accent:             #4f46e5;
  --accent-hover:       #3730a3;
  --accent-light:       #6366f1;
  --accent-blue:        #2563eb;
  --accent-soft:        rgba(79, 70, 229, 0.1);
  --accent-soft-2:      rgba(79, 70, 229, 0.07);
  --accent-soft-3:      rgba(79, 70, 229, 0.13);
  --accent-border:      rgba(79, 70, 229, 0.3);
  --accent-border-mid:  rgba(79, 70, 229, 0.5);

  /* ── Borders — visible on light bg ── */
  --border:             rgba(100, 116, 139, 0.25);
  --border-soft:        rgba(100, 116, 139, 0.18);
  --border-subtle:      rgba(100, 116, 139, 0.15);
  --border-faint:       rgba(100, 116, 139, 0.1);
  --border-input:       rgba(100, 116, 139, 0.35);
  --border-code:        rgba(100, 116, 139, 0.2);

  /* ── Semantic ── */
  --danger:             #dc2626;
  --danger-light:       #ef4444;
  --success:            #16a34a;
  --success-light:      #22c55e;

  /* ── Scrollbars ── */
  --scrollbar:          #b0bdd0;
  --scrollbar-mid:      #94a3b8;
  --scrollbar-dark:     #cbd5e1;
}

The entire application instantly adapts to the selected theme because every component references variables instead of hardcoded values.

Themes Added

After implementing the theme architecture, I expanded the application with multiple theme options.

Dark Themes

🌑 Custom Dark Navy
⚫ Pure Black
🩶 Slate Gray
🟤 Dark Mocha
🔥 Obsidian Warm
🌿 Midnight Green

Light Themes

☀️ Light Mode
🤍 Soft White
📄 Paper
🌸 Cherry Blossom
🩵 Sky
🌿 Fresh Mint
🍊 Peach

Special Themes

🟣 Cyberpunk
⚡ Hacker

Benefits of This Approach

Moving colors into theme variables provided several advantages:

+----------------------+--------------------------------------------+
| Benefit              | Description                                |
+----------------------+--------------------------------------------+
| Scalability          | Easy to add new themes                     |
| Maintainability      | Colors managed from one location           |
| Consistency          | Same design tokens across the app          |
| Flexibility          | Instant theme switching                    |
| Cleaner CSS          | Less duplication and hardcoded values      |
+----------------------+--------------------------------------------+

Most importantly, future themes can now be added with minimal effort by simply defining a new theme block and overriding the required variables.

Settings Integration

Since I already built a dedicated Settings modal during Week 10, theme selection naturally fits into that architecture.

The selected theme is stored in user settings and automatically applied when the user returns to the application, providing a personalized and consistent experience across sessions.

Conclusion

Today’s work was less about adding a visible feature and more about improving the application’s architecture. Refactoring hardcoded colors into centralized CSS variables created a scalable foundation that now supports multiple themes with minimal complexity.

With this system in place, future visual customizations can be implemented much faster while keeping the codebase clean and maintainable.

🔗 Live Demo & Code

👉 Live App:
https://ai-chat-app-learning.netlify.app

👉 GitHub Repo:
https://github.com/RohitKuwar/ai-chat-app/tree/feature/theme

🚀 What’s Next

Today I implemented a scalable theme architecture by moving hardcoded colors into centralized CSS variables and introducing multiple dark, light, and special themes.

Next week, I’ll continue expanding the settings system by integrating more LLM model options, temperature controls to make the AI experience even more personalized.

I’ll be posting here daily as I learn. Let’s grow together and stay ahead in the AI era 🚀

Happy learning ✌️