Best Web Performance tools

It's kind of like a sibling to REST API or GraphQL, enabling communication with the server in a unique way. RPC stands for **Remote Procedure Call**, and the "g" in gRPC stands for **Google**, as it was created by Google.

Let's understand it now:

Suppose there are two machines—one is the client (any machine) and the other is the server (another machine). In the end, when we call an API, it executes a function on the server. With RPC, instead of making a traditional API request, the client can directly call a function on the server. Below is the architecture diagram, and we will discuss each terminology in detail.

![image.png](/public/images/blogs/grpc_2.jpg)

In REST APIs, data is transferred in **JSON** format, but in gRPC, it happens using **Protocol Buffers (Protobuf)**, which is an **IDL (Interface Definition Language)**. To use gRPC, we need **HTTP/2**.

Just like REST APIs send **serialized data** over the network, gRPC also transmits **protocol-serialized data**. However, gRPC maintains a **single long-lived connection** and supports **bidirectional streaming**.

![image.png](/public/images/blogs/grpc_3.jpg)

So, referring to the screenshot above, once an **HTTP/2 request** is made using gRPC, **bidirectional data flow** happens. Each time we call a **server function**, a **bidirectional data flow** occurs, and the connection ends after the response.

We already discussed that gRPC uses **Protocol Buffers (Protobuf)** instead of **JSON**. Now, let’s understand **Protocol Buffers** and how **encoding and decoding** take place.

![image.png](/public/images/blogs/grpoc_4.jpg)

**Protocol Buffer (ProtoBuf)** is developed by Google.

* ProtoBuf is an **IDL (Interface Definition Language)** and also provides **serialization and deserialization**.
* It supports **binary data transfer**, unlike REST APIs, where we use `.json()`, in gRPC, we use `.proto` (also called **proto3**).
* The **.proto file** defines the request and response structure. This file enables **code conversion**, making it compatible with multiple languages.
* The response can be **deserialized in any language**, which makes gRPC highly flexible.

Honestly, this concept is a bit confusing, but we’ll explore it further to understand it better.

### **Benefits of gRPC**

* Requires **less CPU resources**.
* **Faster** on mobile devices due to efficient serialization.

gRPC is **mainly used for server-to-server communication**, but we will also see how to use it in a **browser**. Since a browser acts as a **client machine**, we need a **gRPC client** that interacts with a **gRPC server** to call functions.

![image.png](/public/images/blogs/grpc_5.jpg)

### **Let's Code**

Here is the repo link: [gRPC-first-setup](https://github.com/ashumsd7/gRPC-first-setup)

You can either **clone the repo** or **follow the documentation** to set up the client and server. If you haven’t used gRPC before, it might feel a bit **complex** at first, but at least **try it once**, as I did. **Something is better than nothing** 🙂

- - -

### **Comparison with REST API**

* In **REST API**, we use **HTTP/HTTPS**, but in **gRPC**, we use **HTTP/2** as the default transport protocol.
* REST APIs use **JSON**, whereas gRPC uses **Protocol Buffers**.
* **No standard language** is required for REST APIs, but gRPC enforces **ProtoBuf IDL** as a standard.
* REST APIs transfer data in **JSON/XML/Text**, while gRPC uses **binary serialization** for efficiency.
* **JSON is more flexible**, but **ProtoBuf ensures a strict contract** between the client and server.
* REST APIs often rely on **third-party code generation tools**, whereas gRPC provides **automatic code generation**.

- - -

### **Advantages and Disadvantages**

### **Advantages**

✅ **10x faster** compared to REST API calls

✅ **Better security** since it uses **HTTP/2**

✅ **Bidirectional streaming** support

✅ **Automatic code generation**

✅ **Language-agnostic** (Define proto once and use it in any language)

✅ **Service discovery support**

✅ **More secure communication**

### **Disadvantages**

❌ **Not human-readable** (Uses binary data instead of JSON)

❌ **Limited browser support**

❌ **No edge caching** (Due to the use of POST requests)

❌ **Steeper learning curve** compared to REST APIs


A quick overview of gRPC

**If something works on my system, it doesn't mean it's good for all. So, to know whether it's good or not up to the mark for everyone, we need some tools to test our website. So, let's talk about those.**

There are three personas while discussing web pages and their construction:

1. Developer mode
2. Simulated Environment
3. Real user data

### For Real-Time Users

For real user data, we can use **CRUX** of Chrome. Read here: **[Overview of CrUX](https://developer.chrome.com/docs/crux)**. It's basically Chrome’s user experience report, showing how real Chrome users experience a website. PageSpeed.web also comes under that, which can be used to analyze all web vitals for a web page: https://pagespeed.web.dev/.

Other tools:

* [Request Metrics](https://app.requestmetrics.com/app/) – You can use Request Metrics by injecting the script provided by them into your system to check performance.
* **Microsoft Clarity** – Another tool that can be used to check page-wise core vitals, error tracking, and much more.
* **New Relic**
* **Sentry**
* **Google Analytics**

### For Simulated Data

To test simulated data, there are many tools available to analyze your website:

* **[WebPageTest](https://www.webpagetest.org/)** – A great tool to get detailed data from different locations far from you.

![image.png](/public/images/blogs/performance-testing_2.jpg)

### For Developer mode

\-Lighthouse

![image.png](/public/images/blogs/performance-testing_3.jpg)

\-Netwrok tab
In **Dev Tools**, under the **Network** tab, you can see what is loading and when.

![image.png](/public/images/blogs/performance-testing_4.jpg)

\-Performance tab
We can also tweak the **Performance** tab to check things in detail.

![image.png](/public/images/blogs/performance-testing_5.jpg)

**Note:** Please test your web apps in **incognito mode**.

Always **dock out** your dev tools to test in full viewport.


Cookies are also a storage mechanism for persistent data. The data stored in cookies travels with requests from the client to the server, meaning it is automatically transferred via HTTP calls.

Whatever is saved on the client can always be read by the server. However, data set by the server is not necessarily accessible by the client.

![image.png](/public/images/blogs/cookie_2.png)

There are two types of cookies:

### **Session Cookie**

* Expires when the browser is closed.

### **Persistent Cookie**

* Remains stored until the set expiry time is reached. If no expiry time is set, it persists until the browser is closed.

**Key Points:**

* **Size Limit**: 4KB per domain. Since cookies travel with every request, excessive use can slow down performance.
* **Persistence**: Controlled by expiry date/time. It either expires when the browser closes or when the set expiry time is met.
* **Data Structure**: Stores stringified data.

Below, I have demonstrated how to save a single cookie. For multiple cookies, proper handling is required.

```jsx
// Set a cookie
document.cookie = "name=heyahsu-cookie; path=/; expires=Fri, 31 Dec 9999 23:59:59 GMT";
console.log("Cookie after setting:", document.cookie);

// Get a cookie
function getCookie(name) {
  const cookiePair = document.cookie.split(";").find(cookie => cookie.trim().startsWith(name + "="));
  return cookiePair ? decodeURIComponent(cookiePair.split("=")[1]) : null;
}
console.log("Retrieved cookie:", getCookie("name"));

// Update a cookie
document.cookie = "name=updated-heyahsu-cookie; path=/; expires=Fri, 31 Dec 9999 23:59:59 GMT";
console.log("Cookie after updating:", document.cookie);

// To delete a cookie, set its expiration date to a past date
document.cookie = "name=; expires=Thu, 01 Jan 1970 00:00:00 UTC; path=/;";
console.log("Cookie after deleting:", document.cookie);
```

Authorization purposes are served when we need to store lightweight data that the server can use.

* **Do not use it for large datasets.**
* It is mainly used to store user preferences.
* Helps customize the user experience based on previous selections.


Browser Cookie Storage

### **Caching Levels**

When data is received in the frontend, caching helps optimize performance. Caching happens at different levels:

1. **HTTP Cache**
2. **Service Worker**
3. **API Caching**
4. **Application-Level Caching** (State Management using Redux, etc.)

### **Browser Databases for Caching**

1. **Local Storage**
2. **Session Storage**
3. **Cookies**
4. **IndexedDB**

These storage options can also be used for caching data efficiently.


Browser Database and Caching Overview

IndexedDB is a large-scale, NoSQL storage system that allows storage of just about anything in the user's browser. In addition to the usual search, get, and put actions, IndexedDB also supports transactions, and it's well suited for storing large amounts of structured data.

IndexedDB is a large-scale NoSQL storage system that allows storing almost anything in the user's browser.

* Supports **search, get, put, and transactions.**
* Ideal for **storing large structured data** like Google Docs and Teams messages.
* **Asynchronous operations** (non-blocking).
* **Persists across browser sessions.**
* **Stores data as key-value pairs** and maintains indexes for faster lookups.

### When to Use

* Large data caching
* History storage
* Handling a large dataset

### When Not to Use

* Sensitive and secure data
* Small database operations
* Complex data structures (use only for caching)

**Security Considerations**

* Use authentication and encryption
* Avoid storing sensitive data

### Third-Party Library for IndexedDB

There is a third-party library that makes IndexedDB usage easier:

🔹 **Dexie.js** - A Minimalistic Wrapper for IndexedDB

🔗 [Dexie.org](https://dexie.org/)

It simplifies working with IndexedDB by providing a **Promise-based API, better error handling, and easy queries.**

### Code

```jsx
<script>
    document.addEventListener('DOMContentLoaded', function () {
      const db = new Dexie('todoDB');
      db.version(1).stores({ todos: '++id,task' });

      const todoForm = document.getElementById('todoForm');
      const todoInput = document.getElementById('todoInput');
      const todoList = document.getElementById('todoList');

      function addTodo() {
        db.todos.add({ task: todoInput.value }).then(displayTodos);
        todoInput.value = '';
      }

      function displayTodos() {
        db.todos.toArray().then(todos => {
          while (todoList.firstChild) {
            todoList.removeChild(todoList.firstChild);
          }

          todos.forEach(todo => {
            const listItem = document.createElement('li');
            listItem.textContent = todo.task;
            todoList.appendChild(listItem);
          });
        });
      }

      todoForm.addEventListener('submit', function (event) {
        event.preventDefault();
        addTodo();
      });

      // Initial display
      displayTodos();
    });
  </script>
```

[NFSD Github repo](https://github.com/namastedev/namaste-frontend-system-design/blob/master/Databases%26Caching/indexedDb/index.html) 

A live app : https://mdn.github.io/dom-examples/to-do-notifications/


Browser Indexed DB

This is **storage** where we keep some data **persistently** on the user's device. **Persistent** means the data does not get erased even if the user reloads, exits the window, or closes the tab.

You can check this storage in **Inspect Mode** → Switch to the **Application** tab (next to the Network tab) to view **Local Storage**.

![image.png](/public/images/blogs/ls_2.png)

### What is allowed

```jsx
localStorage.setItem('name', 'heyahsu');  // only string allowed
localStorage.getItem('name');  // gives heyashu
localStorage.removeItem('name');
localStorage.clear();
```

* **Size Limit:** 5MB per domain (maximum data storage allowed).
* **Local Storage operations are synchronous.**
* **Persistent Storage:** Data remains even after closing the tab or window, except in **Incognito Mode**.
* **Only serialized data (strings) are allowed** in Local Storage.
* **Security Considerations:** Do not store sensitive data. Be cautious of **CORS** and **XSS attacks**.
* **Use Cases:** Store user preferences, selected themes, usernames, and basic settings—but **never passwords**.
* **Asset Storage** can also be done.
* LocalStorage is not **reactive**.


Browser Local Storage

Session storage is similar to local storage with some basic differences, and it retains data even after a reload.

![image.png](/public/images/blogs/session_1.png)

Similarly, there are some methods we can use to perform actions and take advantage of them.

```jsx
sessionStorage.setItem('name', 'heyahsu');
sessionStorage.getItem('name');
sessionStorage.removeItem('name');
sessionStorage.clear();
```

It has the same 5MB data limit as local storage and is synchronous.

Just remember: It gets cleared when the browser session ends, such as when you close a tab or window. That’s the key difference from local storage.

Structurally, it uses serialized data for storage.

**Important:** If you switch tabs within the same domain, you won’t get the stored data. However, if you reload the same tab, the data remains. If you duplicate the tab, session storage initializes as a fresh state for that tab and does not sync with the original.

Be mindful of what to store and what not to. Avoid storing sensitive data.

Session storage is best for temporary data related to the current session.

Avoid storing large datasets, asynchronous operations (since it’s synchronous), or data that needs to persist long-term.


Browser Session Storage

Build optimization comes into the picture when we develop our app. To deploy our app, we build it, and the building process is done by a bundler. So, we'll talk about different bundling techniques here.

We develop in different files like TypeScript, CSS, Tailwind, React, Angular, Vue.js, but at the end, the browser needs a file that it can understand. That’s the work of the bundler. A bundler is a tool that takes input and gives an optimized and compatible output that the browser can understand.

For example, browsers can’t understand SCSS, but we write SCSS code. The bundler converts SCSS and bundles it into CSS.

The responsibilities of a bundler include:

* Module management
* Optimization
* Development enhancement (HMR)
* Cross-browser compatibility
* Asset management

There are multiple bundlers in the market.

![image.png](/public/images/blogs/bund_1.png)

When comparing bundlers, you can use a site like [npmtrends.com](https://npmtrends.com/) to analyze and choose trendy bundlers. But before selecting one, let's first understand the core bundlers and how they optimize the build process.

Build time optimization impacts two aspects:

* **Customer Experience** (faster page loads, reduced waiting times)
* **Developer Experience** (faster build times, better tools)

### Code Splitting

Bundlers typically deliver code in a single final JS file. However, web apps often have dynamic features and page-specific code. To improve performance, bundlers can split the code into multiple smaller JavaScript files, which is known as **code splitting**. This approach allows only the necessary code for a specific page or feature to load, improving load times and performance.

Code splitting enables a more efficient delivery of content, as the browser only fetches the code it needs for the page being visited, instead of loading everything upfront.

![image.png](/public/images/blogs/bund2.png)

### Tree Shaking

Tree Shaking is a technique used to eliminate dead code from the final bundle. It removes unused code from the application, helping reduce the size of the JavaScript bundle. This technique is helpful when there are libraries or functions not used in the app. The bundler shakes the tree and removes the branches (unused code), ensuring that only the necessary code is included.

![image.png](/public/images/blogs/bund_3.png)

### Minification

Minification is the process of removing unnecessary spaces, line breaks, comments, and other non-essential parts of the code that are not required for execution. This reduces the file size, making it faster to load and improving performance. Minification helps in optimizing JavaScript, CSS, and HTML files.

4o mini

![image.png](/public/images/blogs/bund_4.png)

### Code Obfuscation

Code obfuscation is a technique used to make the source code difficult to understand and reverse engineer. This is done by altering the code's structure and naming conventions, making it harder for someone to decipher the logic, especially in the browser. The goal is to protect the code from tampering or copying by obscuring its real meaning.

![image.png](/public/images/blogs/bund_5.png)

### Pruning & Optimizing CSS

Pruning and optimizing CSS involves removing unnecessary CSS rules and selectors that are not used in the final rendered page, reducing the overall size of the CSS file.

### Compression

Compression is a technique that reduces the size of code using algorithms, ensuring quicker loading times and better performance by decreasing the size of JavaScript, CSS, or HTML files.

### Optimizing Images & Assets

Optimizing images and assets involves converting them into the best possible formats to reduce their size while maintaining quality. This happens during the build process to improve performance.

### Remove Source Maps

Removing source maps from the production build reduces the file size and ensures that the source code is not exposed to the public, making it more secure.

### Profiling and Analyzing Bundles

Profiling and analyzing bundles involves measuring and evaluating the size and performance of bundled files to ensure efficient and optimized builds. It helps identify unnecessary dependencies and large files.

### Pre-rendering SSG

In Static Site Generation (SSG), pages are pre-rendered at build time, so the content is ready to be served directly to the client without additional computation on the server, improving speed.

### Cache Using Asset Hashing

Asset hashing refers to adding unique hashes to filenames (e.g., chunk.js, bundle.js) to ensure that the browser caches files efficiently and re-fetches them only when the file has changed.

### Vendor Chunk Splitting

In applications, third-party libraries are often used only on specific pages. Vendor chunk splitting helps isolate these libraries into separate bundles, ensuring they are only loaded when needed, optimizing loading time.

### Faster Builds

Faster builds allow developers to iterate and test changes quickly, reducing the time spent waiting for the build process and enhancing the development experience.

### Parallelization

Parallelization is the process of running multiple tasks or processes simultaneously during the build, which speeds up the overall process and improves development efficiency.

### Cache Management

Cache management ensures that previously built assets or modules are stored in the cache and reused when possible, reducing build time and improving performance.

### Incremental Compilation

Incremental compilation is a technique where only the parts of the code that have changed are recompiled, rather than recompiling the entire project. This speeds up the build process.

### Hot Module Replacement (HMR)

Hot Module Replacement (HMR) allows developers to see changes in the application immediately without a full reload. When a code change is made, only the modified parts are reloaded, making development faster and more efficient.

### Mono Repo with Tools like Lerna or NX

Mono repo is a project structure where multiple related projects are stored in a single repository. Tools like Lerna or NX help manage dependencies, automate tasks, and improve the development process in large-scale projects.


Build Optimization Techniques

### HTTP (Hypertext Transfer Protocol)

Used in web browsers for transferring hypertext documents. It involves establishing a TCP connection followed by HTTP Request and HTTP Response messages. This protocol is fundamental to web browsing and allows clients to communicate with servers.

### TCP (Transmission Control Protocol)

Uses a three-way handshake to establish connections. TCP guarantees that no data packets will be lost during transmission. It's commonly used for web browsing and email protocols, providing reliable data delivery between applications.

### UDP (User Datagram Protocol)

A fast protocol that operates without establishing handshakes. It sends and receives data immediately, making it ideal for video conferencing where speed is more important than guaranteed delivery.

### HTTP/3 QUIC (Quick UDP Internet Connections)

A modern protocol built on UDP, designed for Internet of Things (IoT) and Virtual Reality applications. It features header compression and improved network connection handling. HTTP/3 offers better performance while maintaining speed similar to UDP.

### HTTPS (Hypertext Transfer Protocol Secure)

An extension of HTTP that includes Transport Layer Security (TLS). The server sends a public key to the client, and a session key is exchanged for encrypted communication. This is now the standard protocol for secure web browsing.

### WebSocket

A protocol that starts with an HTTP connection and upgrades to a full-duplex connection. Commonly used for chat applications and real-time data transfer, allowing continuous two-way communication between client and server.

### SMTP (Simple Mail Transfer Protocol)

Email protocol that uses intermediate SMTP servers to receive and transfer messages to their endpoints. This protocol manages the routing and delivery of email messages across networks.

### FTP (File Transfer Protocol)

Designed for transferring large files between systems. It provides a dedicated protocol for moving data from one computer to another over a network.


Communication Protocols

High-Level Design (HLD) for a frontend application is **an overview of the application's architecture and structure**. It focuses on the big picture without detailing the implementation of each component.

HLD is a phase in the Software Development Life Cycle (SDLC) where the overall architecture and structure of a software system or application are planned and documented. It bridges the gap between requirement specifications and actual implementation. The goal is to provide a blueprint or roadmap for how the system will function and how its various components will interact.

From requirement gathering to understanding users, architecture design, development, and delivery—everything is planned in HLD to ensure a smooth process without issues. In HLD, you also consider stakeholders, deployment, and third-party services.

### Key Aspects of HLD

1. Requirement Analysis
2. System Architecture: Server, client, components, database, etc.
3. Component/Module Design
4. Data Design / Interfaces / API Schema
5. Technology Selection
6. Functional Requirements: Interaction flow
7. Non-Functional Requirements: Performance, responsiveness, accessibility, SEO, offline support, caching, etc.

📌 **Watch this:** [Cracking Frontend System Design Interview | Front-end](https://www.youtube.com/watch?v=QemIfzcEeMM)

### Remember in Interviews

- Ask questions
- Don't assume—always ask for clarifications
- Drive the interview based on the interviewer’s intent
- System design is more than just drawing boxes
- Understand functional vs. non-functional requirements


HLD High Level Design Overview

### Functional vs. Non-Functional Requirements

### **Functional Requirements**

1. Feeds
2. Create Post
3. List Post
4. Reels, Create Reels
5. Story, Create Story
6. Browse, Filter
7. Messaging
8. Like, Comments
9. Edit Features
10. Profile & Followers

### **Non-Functional Requirements**

1. Security & Privacy Features
2. Desktop vs. Mobile: Device Support
3. Authentication
4. SEO
5. Optimization
6. Accessibility
7. Offline Support
8. Testing
9. i18n / l10n (Internationalization & Localization)
10. Deployment

### **Architecture Design**

Architecture is not about folder or component structure. Start with a high-level **server and client design** and overall system architecture.

🚫 **Avoid framework or language-specific discussions.**

✅ **Focus on concepts like MVC, client-server interactions, and data flow** 

![image.png](/public/images/blogs/insta_1.png)

![image.png](/public/images/blogs/insta_2.png)

### **Component Architecture**

1. **Feed List**: Comment Section, Add Comments
2. **Feed Creation**: Comment, Caption, User Details, Post Body
3. **Media**: Image or Video Component

### **Data Models**

* **Post Data**: `id`, `caption`, `createdAt`, `updatedAt`, `userId`, `mediaIds[]`
* **Feed List**: `postIds[]`, `totalPosts`
* **User Data**: `id`, `name`, `profilePhotoUrl`
* **Media**: `id`, `type` (image/video)

### **API Endpoints**

* **`/feedList`**: `pageNo`, `size` (GET) → Response structure & frontend data usage discussion
* **`/create-post`**: Create post, upload media

### **Optimization**

### **Asset Optimization**

* Image formats: WebP/SVGs
* `srcset`, `userAgent`, `DPR` (Device Pixel Ratio)
* Device connectivity, prefetch images

### **Feed Optimization**

* **SSR** (Above-the-fold strategies)
* **Lazy Loading**
* **Infinite Scroll** (Virtualization, Intersection Observer)
* **Code Splitting**
* **Loading Shimmers**
* **Preserving Feed State**
* **Web Workers**
* **Optimistic Updates**

### **Implementation**

### **Image Editing**

* Crop, Resizing, Filters using **Canvas API** or **CSS Filters**
* Try **online CSS filter tools** for testing and familiarity

### **File Upload**

* **HTTPS POST**

  * `multipart/form-data`
  * **Base64 encoding**
  * **Multi-selection**
  * **File Chunking**


HLD Photo Sharing App Instagram

Network is a core part of software, as the frontend needs data and the backend sends it. All of this happens through the network. How is data transferred over the internet? How does it reach the client, and what protocols are required? These are essential concepts for software development.

We need to understand what happens when we type "[google.com](http://google.com/)," what DNS is, and its role in the process.

We commonly use REST APIs, but we'll also explore how the web works, including GraphQL, gRPC protocols, and more. We'll dive into networking fundamentals, how the internet works, frontend-backend interactions, REST concepts, HTTP methods, headers, CORS, and other key aspects.

### How the Web Works

To understand this, we need to know the client-server model. A client is the entity requesting information, while a server is the entity providing it. Essentially, the client asks for something, and the server serves it. This is the basic definition of client-server architecture.

[Read more about client-server](https://heyashu.in/digital-garden/notes/namaste-node-js/e2-js-on-server)

### IP Address

Each system on the internet has an IP address.

**IP Address**: An IP address is like a home address for devices on the internet. It uniquely identifies devices (like computers or phones) so they can find and communicate with each other.

Examples:

* IPv4: `192.168.1.1`
* IPv6: `2001:0db8:85a3...

### Domain Name

A domain is a human-readable address linked to a unique IP address.

![image.png](/public/images/blogs/web_works_2.jpg)

### Domain Name Parts

When you say `https://www.google.com`, there are specific parts, each with its own significance:

1. **Root Level Domain**:

   The last dot represents the root level domain.
2. **Top-Level Domain (TLD)**:

   Examples: `.edu`, `.org`, `.gov`, `.com`, `.au`.
3. **Second-Level Domain**:

   Examples:

   * [openoffice.org](http://openoffice.org)
   * [expedia.gov](http://expedia.gov)
   * [microsoft.com](http://microsoft.com)
   * [congress.au](http://congress.au)
4. **Third-Level Domain**:

   Examples:

   * `[www.example.com](http://www.example.com)`
   * `download.microsoft.com`
   * `sales.microsoft.com`

### Data Centers

A **data center** is a physical facility that stores computing equipment and digital data for companies. It's like a server, but without displays—only CPUs and hardware managing incoming requests.

**Where are data centers located?**

Data centers can exist in multiple physical locations worldwide, all interconnected through optical fibers. These fibers connect across oceans and land, forming a global network. (You can learn more about optical fibers later.)

![image.png](/public/images/blogs/web_works_3.jpg)

Similarly, everything is interconnected, and we get internet connectivity. Data centers provide the data we request via the internet through our browsers. In India, we use internet providers like Jio, VI, and Airtel. These are **ISPs (Internet Service Providers)**. When you relocate to a new city, you may get broadband services like "ABC Internet Broadband" offering speeds like 100 Mbps. These are also ISPs. Let’s explore more about ISPs and how they work.

### ISP (Internet Service Provider)

An **ISP (Internet Service Provider)** is **a company that provides internet access to individuals and businesses.**

ISPs connect users to the internet backbone, assign IP addresses, and route data requests to the correct servers. They manage the local infrastructure and provide bandwidth for internet use.

![image.png](/public/images/blogs/web_works_4.jpg)

So we have local ISPs connected to the internet, governed by the country’s regulatory organizations. There are local, regional, and global ISPs, and these follow specific rules and regulations.

- - -

### Summary So Far

Whenever you type [google.com](http://google.com/), the request goes through the router to the ISP via the internet. Then it hits a DNS server, which provides the IP of the domain. Using that IP, the server is contacted, and it responds with HTML, CSS, and JS files.

Now, let’s dig deeper: what happens when you hit a URL like `google.com`?

- - -

### What Happens When You Hit a URL?

When you type a URL, it doesn’t directly go to the router. First, the browser performs some internal operations:

1. **Cache Check**: The browser checks if the requested resource is available in its cache.
2. **Service Workers**: If a service worker is registered, it intercepts the request and decides how to handle it. (More on this later.)
3. **Router Communication**: After these checks, the request is sent to the router. Some smart routers may cache resources to speed up responses.

The router then communicates with the ISP, which handles the rest of the process.

To observe how service workers and network requests work:

1. Open this site in your browser: https://service-worker-stale-while-revalidate.glitch.me/.
2. Open **Inspect Mode** in the browser and go to the **Network** tab.
3. Make a request and observe the timing for responses (e.g., `200` for success, `304` for cached responses).

We will discuss HTTP status codes (`200`, `304`, etc.) and other details later, or you can explore them online.

![image.png](/public/images/blogs/web_works_5.jpg)

So, when you're getting data from the server, in some cases, the server does not serve the request directly. Instead, a **service worker** plays a role in providing the data. Let’s look at this scenario.

I reloaded the page and clicked on a request with a status code `200`. I noticed the **service worker** responded faster. It's not just about speed; the service worker also provides **caching** and **offline support** in the browser.

![image.png](/public/images/blogs/web_works_6.jpg)

### Service Workers

Service workers enhance the performance of requests made by the browser. Now we understand that before reaching the ISP, caching occurs, and service workers may play a role. Let’s now focus on the ISP layer.

- - -

### ISP Layer

What we currently know is that ISPs deal with the internet, but that’s not entirely true.

When you request data via an IP, it often passes through multiple layers of ISPs:

1. **Local ISPs**
2. **Regional ISPs**
3. **Global ISPs**

Then, it reaches the server in the respective country.

However, this is not always the case. Big companies like Netflix and Google optimize their systems by deploying **data centers** in multiple countries. This minimizes cross-region requests and ensures faster access to data. For example, Netflix stores data at the **regional ISP level**, so users experience minimal latency.

To check details related to any domain, visit https://www.whois.com/.

- - -

### ISP to Servers

Let’s discuss what happens when a request goes from the ISP to the server.

### Three-Way Handshake

If you’ve studied computer networks, you might know this already. If not, let’s review:

1. **SYN (Synchronize)**: The client sends a synchronization request to the server.
2. **ACK (Acknowledge)**: The server responds, acknowledging the request.

- - -

### Steps from ISP to Server

1. **DNS Lookup**:

   This step resolves the domain name to the correct IP address. You can learn more about DNS lookups separately. For now, think of it as finding the correct IP for the given domain name.
2. **TCP Handshake**:

   Before any data transfer, the client checks the availability of the server through a **TCP handshake** (SYN and ACK).
3. **SSL Handshake** (for HTTPS):

   If the URL uses HTTPS, an SSL handshake ensures encrypted communication between the client and server, enhancing security.
4. **HTTP GET Request**:

   After the handshake, the browser sends the HTTP GET request, and the server responds with the requested data.

This process ensures a secure and efficient connection between the client and the server.

![image.png](/public/images/blogs/we_works_7.jpg)

### SSL: **Secure Sockets Layer**

An SSL handshake is **a series of communications between a client and a server that establishes a connection and verifies the security of both parties.**

During this process:

1. **Certificate Exchange**: Certificates are exchanged to ensure that the communication is secure and cannot be hijacked.
2. **Encryption**: A secure, encrypted channel is established between the client and server.

Finally, you receive **HTML, CSS, JS**, and other resources like images, which are rendered in the browser.

![image.png](/public/images/blogs/web_works_77.jpg)

### Lets discuss how browser handles and renders

![image.png](/public/images/blogs/web_works_8.jpg)

### How the Browser Processes a Web Page

When a page is requested, we receive **HTML, CSS, and JS**.

* **HTML**: Used to build the **DOM tree** (Document Object Model).
* **CSS**: Parsed to create the **CSSOM** (CSS Object Model).

  * **Note**: CSS is **render-blocking**, which means it can delay the rendering of the page until it is fully loaded and processed.
* **JS**: JS is **parser-blocking**, meaning it pauses HTML parsing while the script is being executed.

- - -

For more detailed insights, you can refer to [this article](https://medium.com/a-layman/how-browser-works-when-rendering-a-web-page-f49c09bec475).

![image.png](/public/images/blogs/web_works_9.jpg)

### Document Object Model (DOM)

The **Document Object Model (DOM)** is a programming interface that represents the structure of a web document as objects and nodes. This allows programs to interact with and manipulate web documents dynamically.

- - -

### CSS Object Model (CSSOM)

After parsing CSS, the **CSS Object Model (CSSOM)** is created.

**CSSOM** stands for **CSS Object Model**. It is a set of APIs that enables reading and modifying a document's CSS information. While the DOM is for HTML, the CSSOM serves the same purpose for CSS.

![image.png](/public/images/blogs/web_works_10.jpg)

### Execute JS

Next comes the phase where **JS execution** takes place. The loading of the script happens, followed by **AST internalization**, **compilation**, and **bytecode conversion**. Finally, the code is executed. By now, **HTML**, **CSS**, and **JS** have been processed, and we are in the **Rendering Phase**.

- - -

### Rendering and Painting

In the **Rendering Phase**, **layouting** happens. Layouting means merging the **DOM** and **CSSOM** into the **Render Tree**. It's like creating the layout of a home and organizing the materials needed to build a villa. This process uses computer graphics and C++ code to draw the content on the browser.

### How Scripts Load

To learn more about how scripts load, check this [video](https://www.youtube.com/watch?v=IrHmpdORLu8).

### Parsing Behavior

* **CSS**: **Blocks rendering** (renders only after parsing is complete).
* **JavaScript**: **Blocks parsing** until it finishes execution.

  * **defer**: Waits until the HTML parser is finished.
  * **async**: Executes as soon as the script loads.

### DOMContentLoaded and window.load

* **DOMContentLoaded**: This event is triggered when all **synchronous** content is loaded. You can use this as a hook to interact with the page.
* **window.load**: This event is fired when **all** content, including images and other resources, has been fully loaded.

Finally, remember that the **DOM tree** and **CSSOM** get merged, and **rendering** and **layouting** occur to paint the content on the screen.

So that's all for this article. Let's meet in the next one.  Take care, bye-bye!



How the Web Works

As we know, we can check website performance using different tools. If you're not aware, I highly recommend checking these notes: **[Best Web Performance Tools](https://heyashu.in/digital-garden/notes/front-end-design-system/best-web-performance-tools)**.

In this blog, we will cover:

1. **Critical Rendering Path**
2. **Minimizing HTTP Requests**
3. **Sync, Async, and Defer for Loading JavaScript**
4. **Avoiding Redirections**
5. **Resource Hinting**
6. **Fetch Priority**
7. **Early Hints**
8. **HTTP Upgrades (HTTP/1.1 vs. HTTP/2 vs. HTTP/3)**
9. **Compression: Brotli/Gzip**
10. **HTTP Caching & Cache Control**
11. **Caching Using Service Workers**

### **Critical Rendering Path**

![image.png](/public/images/blogs/nw_2.png)

you know the **client-server architecture**, where the client sends a request to the server, and the server responds. Now, let’s understand how **HTML is displayed in the browser** when the server sends it.

📄 **Official Document:** **[Understand the Critical Path | web.dev](https://www.notion.so/14-Network-Optimization-1994a3ba7f7d807dad76d1bb8312ddb1?pvs=21)**

When the server sends HTML, the browser processes it step by step:

1. **DOM Creation** – The HTML is parsed, and a **DOM tree** is created.
2. **CSSOM Creation** – The browser checks for CSS, processes it, and builds the **CSSOM (CSS Object Model)**.
3. **JavaScript Execution** – JavaScript interacts with the page, often modifying the DOM or delaying rendering.
4. **Rendering & Painting** – The browser combines the **DOM + CSSOM**, applies styles, and renders the page.

🚨 **Important Notes:**

* **CSS is render-blocking** – It delays the page from being displayed until it's fully loaded.
* **JavaScript is parsing-blocking** – It can pause HTML processing while being executed.
* The **first packet** received from the server is **14KB** in size.

![image.png](/public/images/blogs/nw_3.png)

When someone asks **what is CRP (Critical Rendering Path)**, just say:

**The critical rendering path refers to the steps involved until a web page starts rendering in the browser.** To render pages, browsers need the **HTML document** along with all critical resources required for rendering.

For example, you can write an **HTML document** with scripts, CSS, and HTML, render it in the **Network tab**, and observe what gets loaded.

### **Minimize Network/HTTP Requests**

When we make a request from the client to the server, it takes time to resolve, affecting the web page. So, we should focus on reducing it.

### **Key Factors:**

* **Connection Time**
* **Browser Limits** (Max **6 to 10** parallel requests)

### **Solutions:**

To optimize performance:

* Keep some **inline JS and CSS** in the **first request** to render the page (LCP).
* Use **Base64 images**.
* Prefer **SVG** for images.

We wrote an **HTML code**, linked an **external CSS file**, and rendered a few cards. Images are imported from a **PNG file stored locally**.

**GitHub repo link:** [Github repo](https://github.com/ashumsd7/network-optimization-web)

![image.png](/public/images/blogs/nw_4.png)

The **Network tab** shows data where styles and images take time to load. You can check how each resource (HTML, CSS, JS, images) loads and impacts performance.

![image.png](/public/images/blogs/nw_5.png)

Now, let's change **images to SVGs** and use **internal CSS** instead of an external file.

Check the screenshots below—see how fast it loaded. If you observe in **Lighthouse**, **FCP and LCP times are the same** because everything was loaded in a single file at the same tim

![image.png](/public/images/blogs/lowww.png)

### **Loading JavaScript: Sync / Async / Defer**

Let's talk about how to load **JavaScript** in an optimized way.

JavaScript can be loaded in two ways:

1. **Inline (inside the HTML file)**
2. **External file (linked in the HTML)**

External scripts can be placed **inside** or **at the end of the body** for better performance.

![image.png](/public/images/blogs/nw_6.png)

### **Before Discussing This, Know That JavaScript is Parsing-Blocking**

### **Case 1: Default Script Loading**

* When a `<script>` tag is encountered, **HTML parsing stops**.
* The script **downloads**, then **executes**, and only after that does **HTML parsing resume**.
* This delays **FCP (First Contentful Paint) and LCP (Largest Contentful Paint)**.

### **Case 2: `async` Attribute**

* While **HTML is parsing**, the script **downloads simultaneously**.
* Once downloaded, **execution starts immediately**, **blocking further HTML parsing**.
* **FCP and LCP can be affected**, depending on the script size.

### **Case 3: `defer` Attribute**

* The script **downloads in parallel**, like `async`.
* **Execution happens only after HTML parsing is complete**.
* Unlike `async`, it **does not block HTML parsing** and ensures scripts run in order.

### **Avoid Redirection**

Sometimes, users try to load a website without the **secure protocol** (HTTP instead of HTTPS). If the site is hosted on HTTPS, it **automatically redirects** to the secure version.

When a user makes an **HTTP request**, a middleware ensures the request doesn't reach the server and **switches the protocol to HTTPS**. This happens using **HSTS Preloading**: https://hstspreload.org/.

### **What is HSTS Preloading?**

HSTS (**HTTP Strict Transport Security**) is a security mechanism that forces browsers to always use **HTTPS** instead of **HTTP** when connecting to a website.

To **avoid redirection delays**, websites should **enforce HSTS**. For example, when you type `http://google.com`, it automatically redirects to `https://google.com`. See the screenshot below.

![image.png](/public/images/blogs/nw_7.png)

### **Resource Hinting**

On a website, we load:

* **Same-origin resources** (CSS, JS)
* **Cross-origin resources** (CDN-hosted JS, fonts, images)

These resources load in different phases, often after an API response. To optimize this, we use **resource hinting** techniques like **preload, preconnect, and dns-prefetch** to fetch them earlier.

![image.png](/public/images/blogs/nw_8.png)

### **Preconnect**

When a request is made, a connection is set up, DNS lookup happens, and SSL/TLS handshake occurs. This process happens each time you load a resource from an external domain.

Using **preconnect**, we avoid making the connection repeatedly when accessing resources from the same external endpoint.

The `preconnect` hint tells the browser to open a connection to a domain or subdomain in advance. This is useful when you can’t self-host critical resources.

Example:

```jsx
 
<link rel="preconnect" href="https://xyz.com" crossorigin />
```

Check this link for more examples: [Resource Hints](https://learn-performance-resource-hints.glitch.me/)

- - -

### **DNS-prefetch**

**DNS Prefetch** checks the availability of the domain before a request is made. It performs a DNS lookup in advance, reducing latency during future requests to the same domain.

Example:

```jsx
 
<link rel="dns-prefetch" href="https://xyz.com" crossorigin />
```

- - -

### **Preload**

Preload allows the browser to download extra resources in advance before they're actually needed. It speeds up resource fetching and improves rendering time.

Example:

```jsx
 
<link rel="preload" href="image-url" as="image" crossorigin />
```

Check how preload works with images here: [Preload Example](https://learn-performance-resource-hints.glitch.me/3)

- - -

### **Prefetch**

Prefetch is used to load resources that will be needed in the near future, with low priority, to speed up future navigation.

- - -

### **Prerender**

Prerender downloads the next page and its dependencies, caching them for faster future loading. It uses a hidden frame for this technique.

- - -

### **Resource Hint Priority**

Resource hint priority helps determine which hints to use first. The `fetchpriority` attribute can be added to image tags or other resources to control loading order.

Example:

```jsx
 
<link rel="preload" href="image-url" as="image" fetchpriority="low" crossorigin />
```

Documentation: [Fetch Priority](https://web.dev/articles/fetch-priority)

- - -

### **Early Hints**

Sometimes, servers take time to give a response. **Early Hints** is an HTTP status code (`103 Early Hints`) that allows servers to send hints about critical subresources before the final response. This allows the browser to fetch these resources (like stylesheets or JavaScript) while the server is still generating the main resource.

Documentation: [Early Hints](https://developer.chrome.com/docs/web-platform/early-hints)

![image.png](/public/images/blogs/nw_9.png)

### HTTP Upgrade http1.1/  2 and 3

![image.png](/public/images/blogs/nw_10.png)

In **HTTP/1** and **HTTP/1.1**, the process started with establishing a connection, followed by **TCP** and **TLS** handshakes, and then other operations occurred. However, **HTTP/1.1** lacked **multiplexing** and **streaming capabilities**, which created issues in efficiently handling multiple requests.

**HTTP/2** introduced **multiplexing**, allowing multiple requests and responses to be sent simultaneously over a single connection. It also offered **data prioritization** and **stream control** to optimize data packet handling.

**HTTP/3** uses **UDP** instead of **TCP** and skips the traditional 3-way handshake. Instead of TLS, **HTTP/3** uses **QUIC** for encryption and transport. Both **HTTP/2** and **HTTP/3** operate over **HTTPS**, not **HTTP**.

![image.png](/public/images/blogs/nw_11.png)

So, the server can use HTTP/2, so the browser can make multiple requests, and the server can handle them to reduce LCP and FCP time.

### Copression

So server send the dat to the client but we need to send the dtaa in compressed fasion to aovid extar load to do som there are tehxniues can be sued techbnique ar eusid are brotl and gzip, brotli is mre p[owerfull ,s o severred send copressed ata amnd brwser encod the data fdrom server we can user diff packegs to do the same 

Docs: https://web.dev/articles/codelab-text-compression-brotli

### **Caching**

To optimize caching, we can use cache policies like **Cache-Control**, **Expires**, **ETag**, and **Last-Modified** headers. These can help avoid repeated requests by caching the data, thus improving performance and reducing server load. By using these headers, the server can instruct the browser to store data and reuse it for repeated requests.

Service workers do play a key role in caching and improving performance, which we’ll cover in another note.

Thank you for your time and patience! You're doing awesome. Don’t forget to attempt the quiz to check your knowledge. Take care and see you next time! Bye!


Mastering Network Optimization: A Comprehensive Guide

How to do Network Optimization in web

HTTP Headers Methods Status Codes and Rest API Deep Dive

We have seen multiple platforms like **Swiggy, Zomato, and even social media apps** with a feature where we keep scrolling, and **content never ends**, right?

That’s **infinite scroll**—instead of a scrollbar, content keeps getting added dynamically.

### How It Works

1. First, we fetch a **block of data** and render it.
2. Detect when the user has **scrolled** **80% or 100%** of the page.
3. Load and append **more data** dynamically.

### Problem

Let's identify when the **user reaches the bottom** of the screen.

```jsx
// view port height
window.innerHeight
919
// length of the rendered page ( height )
document.body.scrollHeight
5307
// scroll by : how much you have scrolled in y axis
window.scrollY
600
```

So, we need a **formula** that tells us whether we have reached the **bottom of the page** or not, correct?

If that **formula returns `true`**, it means we have reached the bottom and should **call the API** to load more data.

### **Formula to Check if We Have Reached the Bottom**

If my **window scrollY** (whatever we have scrolled) **+ window.innerHeight** is **around or equal** to the **scrollHeight** of the page:

```jsx
  useEffect(() => {
    const handleScroll = () => {
      const scrolledArea = window.scrollY;
      const pageScrollableArea = document.body.clientHeight;
      const windowSize = window.innerHeight;
      // return true or false
      console.log(scrolledArea+windowSize>=pageScrollableArea)
      // call the api and append the data  
    };

    window.addEventListener('scroll', handleScroll);
    return () => {
      window.removeEventListener('scroll', handleScroll);
    };
  }, []);
```

There is one **substitute** for this, which is **pagination**, and we will discuss its implementation in the next lecture.

### 🔗 **Links**

📌 **[Component Full Code](https://github.dev/ashumsd7/react-playground-2025/blob/main/src/pages/InfiniteScroll.jsx)**

🚀 **[See App in Live Action](https://heyashu-react.netlify.app/infinite-scroll)**


LLD: Infinite scroll

infinite scroll

Accordion is a kind of controlled input used to show data.
So, after confirming where the data comes from and knowing the requirements, we start the development.\

🔗 Links


[📌 GitHub Code Link:](https://github.com/ashumsd7/react-playground-2025/blob/main/src/pages/Accordion.jsx)

[](https://github.com/ashumsd7/react-playground-2025/blob/main/src/pages/Accordion.jsx)
[🚀 Live Deployed Link: ](https://heyashu-react.netlify.app/accordion)

[](https://heyashu-react.netlify.app/accordion)
Approach
Here, we have accordion items and children. Since siblings are sharing data and using the same state to track which one is opened and which is not, it's better to use state lifting.
That's why the parent component will keep all the state, and children will receive props based on which item is opened. This ensures that the accordion works properly.
After checking the code, you will also see state lifting in action.

```jsx
function Accordion() {

  const [open, setOpen] = useState(null);
  return (
    <div>
      <h1 className="text-2xl font-bold mb-4">Accordion</h1>

      {jsonData?.map((item)=>(
        <AccordionItem key={item.id} item={item} open={open} setOpen={setOpen}/>
      ))}
      

      
    </div>
  )
}

export default Accordion

function AccordionItem({item,open, setOpen}){
  return (
    <>
      <div className="border-b border-gray-200">
        <div className='flex justify-between bg-gray-200 p-2 font-bold border-b border-gray-300'>
          {item.title}
          <button onClick={() => setOpen(open==item.id ? null : item.id)}>
            {open==item.id ? <span>&#9650;</span> : <span>&#9660;</span>}
          </button>
        </div>
        {open==item.id  && <div className='my-2'>{item.body}</div>}
      </div>
    </>
  )

}
```


LLD:  Accordion Component

LLD Accrodion Component

[Live Deployed Link](https://heyashu-react.netlify.app/autocomplete)

[Github Code Link](https://github.com/ashumsd7/react-playground-2025/blob/main/src/pages/AutoComplete.jsx)

```
import { useEffect, useRef, useState } from 'react';
let timeoutId;
const AutoComplete = () => {
  const [search, setSearch] = useState('');
  const [list, setList] = useState([]);
  const [isVisible, setIsVisible] = useState(false);

  const fetchData = (query) => {
    console.log('get called', query);
    if (!query) return;
    console.log(query);
    fetch(`https://www.google.com/complete/search?client=firefox&q=${query}`)
      .then((res) => res.json())
      .then((data) => {
        console.log(data[1]);
        setIsVisible(true);
        setList(data[1]);
      });
  };
  console.log('New');

  const debounce = (func, delay) => {
    if (timeoutId) clearTimeout(timeoutId);

    // if (timeoutId) clearTimeout(timeoutId);
    timeoutId = setTimeout(() => {
      func(search);
    }, delay);
  };

  // const debouncedFetchData = debounce(fetchData, 2000);

  useEffect(() => {
    debounce(fetchData, 400);
  }, [search]);
  return (
    <div>
      <h1 className='mb-2 text-2xl font-bold'>Auto Complete</h1>

      <input
        type='text'
        value={search}
        onFocus={() => setIsVisible(true)}
        onBlur={() => setIsVisible(false)}
        onChange={(e) => {
          console.log(e.target.value);
          setSearch(e.target.value);
        }}
        className='w-full rounded-md border p-2'
        placeholder='Search...'
      />
      {isVisible && (
        <ul className='mt-2 flex flex-col justify-center rounded-md border p-1 shadow-md'>
  
            <>
              {list?.map((item, index) => (
                <li key={index} className='cursor-pointer p-2 hover:bg-gray-200'>
                  {item}
                </li>
              ))}

              {list?.length == 0 && <li className='mt-4 opacity-30'>No Results</li>}
            </>
     
        </ul>
      )}
    </div>
  );
};

export default AutoComplete;

```


LLD Auto Complete Searchbar

If you get this problem in an **interview**, first **query the image data** properly. Once you have the **image URLs**, then start the development.

### **Requirements**

1️⃣ Render an **image** from an **array of image URLs**.

2️⃣ Have **two buttons** to change the **source** of the image in the `<img>` tag.

And that's it!

👇 **See the code below:**

```jsx
import React, { useState, useEffect } from 'react'
const data = [
  'https://picsum.photos/600/300',
  'https://picsum.photos/601/300',
  'https://picsum.photos/602/300',
  'https://picsum.photos/603/300',
  'https://picsum.photos/604/300',
];
function ImageSlider() {

  const [activeImageIndex, setActiveImageIndex] = useState(0);

  useEffect(() => {
    const interval = setInterval(() => {
      setActiveImageIndex((prevIndex) => (prevIndex + 1) % data.length);
    }, 3000);
    return () => {
      clearInterval(interval);
    };
  }, []);
  return (
    <div>
      <h1>ImageSlider</h1>
      <div className='w-[600px] mx-auto'>
      <p className='text-center text-2xl font-bold'>{activeImageIndex + 1} / {data.length}</p>
        <img src={data[activeImageIndex]} alt="slider" className="shadow-lg" />
      </div>
      <div>
        <div className='w-[600px] mx-auto mt-6' style={{ display: 'flex', justifyContent: 'space-between' }}>
          <button 
            onClick={() => {
              if(activeImageIndex > 0){
                setActiveImageIndex(activeImageIndex - 1);
              } else {
                alert('You are at the first image.');
              }
            }}
            className="px-4 py-2 bg-blue-500 text-white rounded hover:bg-blue-700"
          >
            Previous
          </button>  
          <button 
            onClick={() => {
              if(activeImageIndex < data.length - 1){
                setActiveImageIndex(activeImageIndex + 1);
              } else {
                alert('You are at the last image.');
              }
            }}
            className="px-4 py-2 bg-blue-500 text-white rounded hover:bg-blue-700"
          >
            Next
          </button>
        </div>
      </div>
    </div>
  )
}

export default ImageSlide
```

[Github Code Link](https://github.com/ashumsd7/react-playground-2025/blob/main/src/pages/ImageSlider.jsx)
[Live Deployed Link](https://heyashu-react.netlify.app/image-slider)


LLD: Image Slider Component

LLD Image Slider Component

### **Nested Comments**

**Nested comments** are where **multiple people comment** on a comment, creating a **hierarchical structure**. This helps provide **clear context** on who is participating and in what way.

Different platforms like **Reddit, Instagram,** etc., have implemented this **deep comment UI** feature. **Reddit** is one of the best examples of this.

Some platforms, like **YouTube**, **restrict the level of replies**. On YouTube, you can only see **one level of replies**, meaning no one can reply to a **replied comment**—only the **parent comment** can have replies.

But **Reddit allows deep nesting**, so we will implement **that**.

### **Approach**

We **render a comment**, and based on its **replies**, we **call the same component recursively**. This ensures that **all comments are displayed hierarchically**, with **each level slightly indented** to indicate depth.

Let me show you how the **data structure** looks like.

```jsx
const commentsData = [
  {
    id: 1,
    user: 'Rahul Sharma',
    text: 'Exploring the beauty of nested comments!',
    replies: [
      {
        id: 1,
        user: 'Priya Verma',
        text: 'Indeed, it adds depth to discussions.',
        replies: [
          {
            id: 1,
            user: 'Amit Patel',
            text: 'Absolutely! It’s like a conversation within a conversation.',
            replies: [
              {
                id: 1,
                user: 'Sneha Kapoor',
                text: 'Nested comments are a great way to keep track of replies.',
                replies: [
                  {
                    id: 1,
                    user: 'Vikram Singh',
                    text: 'I agree, it keeps the thread organized.',
                    replies: [],
                  },
                  {
                    id: 2,
                    user: 'Anjali Mehta',
                    text: 'Yes, it’s very user-friendly.',
                    replies: [],
                  },
                ],
              },
              {
                id: 2,
                user: 'Rohit Gupta',
                text: 'It’s like a tree of thoughts!',
                replies: [],
              },
            ],
          },
        ],
      },
      {
        id: 2,
        user: 'Neha Joshi',
        text: 'This feature is really helpful for discussions.',
        replies: [],
      },
    ],
  },
  {
    id: 4,
    user: 'Ashutosh',
    text: 'Loving the nested comment feature!',
    replies: [.......
```

[Live Deployment Link](https://heyashu-react.netlify.app/accordion)

[Code link](https://github.com/ashumsd7/react-playground-2025/blob/main/src/pages/NestedComments.jsx)


LLD Nested Comments UI

### **Pagination: Offset & Cursor**

If the backend has too much data, loading everything at once is not possible. That’s why we use **pagination** or **infinite scroll** for better access.

- **Infinite Scroll:** The user doesn't know when the data will end. If data is sorted alphabetically (A to Z), you can’t directly jump to "Z." It has no footer and is best for live or addictive content.
- **Pagination:** You can go to a specific page, making it ideal for admin panels. Infinite scroll is mobile-friendly, while pagination is better for structured navigation.

### **Offset Pagination**

Pagination can be:

1. **Server-Side Pagination**
2. **Frontend Pagination**

In **server-side pagination**, data is loaded page-wise. Example: If you request `?page=1`, you get 25 records. Clicking `?page=2` fetches the next 25, and so on. This is called **offset pagination**. If `?page=2&count=20`, it skips 40 records and fetches 41-60.

- **Faster initial load** than frontend pagination.
- Each page change requires an API call.
- Example API:This fetches **10 products** while skipping the first **10 records**.
    
    ```
    https://dummyjson.com/products?limit=10&skip=10&select=title,price
    ```
    

In **frontend pagination**, API is called **once**, and data is stored locally.

- No extra API calls, faster access after load.
- Easy to implement, no backend logic needed.
- **Cons:** High initial load time, heavy on the browser.

### **Cursor Pagination**

Google introduced **cursor pagination** to solve offset pagination issues.

### **Offset Pagination Problem**

- Suppose there are **12 users**, and each page shows **4 users**.
- After fetching page **2**, new users register on page **1**.
- This shifts data, causing **missing records** or **duplicates**.

### **How Cursor Pagination Solves It**

- Instead of page numbers, it uses a **cursor** (like a timestamp or ID) to fetch data.
- Example:
    - Cursor = **7**, Limit = **4** → Fetches **4 records after 7**.
    - Cursor = **9**, Limit = **6** → Fetches **6 records after 9**.
- **Advantages:**
    - No duplicate or missing data.
    - Faster and better for real-time updates.

Use **offset pagination** for structured data and **cursor pagination** for real-time updates like social media feeds.

Cursor pagination **does not track pages**, making it a good fit for **infinite scroll**, where pages don’t matter. It is useful when sorting is **not required**. In social media feeds, for example, we don’t have the option to sort posts normally, so cursor pagination works best.

I have written a pagination component. Check it out!

[**Code Link:**](https://github.com/ashumsd7/react-playground-2025/commit/cd4ec8d8ea2c8dd33628edefc8dbd558fcf09f9e#diff-8634a1a959c7500599eed378cd04b1f9cfeacc95de0ec134bd1d1ca99b78d8d5)

[**Deployed Link:**](https://heyashu-react.netlify.app/pagination)


LLD:  Offset and Cursor Pagination 

LLD Offset and Cursor Pagination 

**I have already covered these topics please refer below links**\
\
**[What is short polling! Learn with example](https://heyashu.in/digital-garden/notes/front-end-design-system/what-is-short-polling-learn-with-example)
[Practical Guide Long Polling](https://heyashu.in/digital-garden/notes/front-end-design-system/practical-guide-long-polling)**

**[Web Socket Lets Chat](https://heyashu.in/digital-garden/notes/front-end-design-system/web-socket-lets-chat)**

**[Server Sent Events: A Real time communication](https://heyashu.in/digital-garden/notes/front-end-design-system/what-are-server-sent-events-a-real-time-communication)**

**[Introduction to Web hooks](https://heyashu.in/digital-garden/notes/front-end-design-system/what-are-web-hooks)**


LLD Real time updates

\
[Github Code Link](https://github.com/ashumsd7/react-playground-2025/blob/main/src/pages/YoutubeChat.jsx)\
[Live Deployed Link](https://heyashu-react.netlify.app/yt-chat)

```
import React, { useEffect, useState,useRef } from 'react';

const COMMENTS = [
  {
    id: 1,
    name: 'John Doe',
    comment: 'Lorem ipsum dolor sit amet consectetur adipisicing elit. Quisquam, quos.',
    avatar: 'https://avatar.iran.liara.run/public'
  },
  {
    id: 2,
    name: 'Jane Doe',
    comment: 'Lorem ipsum dolor sit amet consectetur adipisicing elit. Quisquam, quos.',
    avatar: 'https://avatar.iran.liara.run/public'
  },
  {
    id: 3,
    name: 'Alice Smith',
    comment: 'Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium.',
    avatar: 'https://avatar.iran.liara.run/public'
  },
  {
    id: 4,
    name: 'Bob Johnson',
    comment: 'At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium.',
    avatar: 'https://avatar.iran.liara.run/public'
  },
  {
    id: 5,
    name: 'Charlie Brown',
    comment: 'Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio.',
    avatar: 'https://avatar.iran.liara.run/public'
  },
  {
    id: 6,
    name: 'David Wilson',
    comment: 'Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet ut et voluptates repudiandae sint et molestiae non recusandae.',
    avatar: 'https://avatar.iran.liara.run/public'
  },
  {
    id: 7,
    name: 'Eve Davis',
    comment: 'Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat.',
    avatar: 'https://avatar.iran.liara.run/public'
  },
  {
    id: 8,
    name: 'Frank Miller',
    comment: 'Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt.',
    avatar: 'https://avatar.iran.liara.run/public'
  },
  {
    id: 9,
    name: 'Grace Lee',
    comment: 'Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem.',
    avatar: 'https://avatar.iran.liara.run/public'
  },
  {
    id: 10,
    name: 'Hank Green',
    comment: 'Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur?',
    avatar: 'https://avatar.iran.liara.run/public'
  }
];


function generateRandomName() {
  const names = [
    'Alice Smith', 'Bob Johnson', 'Charlie Brown', 'David Wilson', 
    'Eve Davis', 'Frank Miller', 'Grace Lee', 'Hank Green', 
    'Ivy White', 'Jack Black', 'Karen Hill', 'Larry King', 
    'Mona Lisa', 'Nina Simone', 'Oscar Wilde', 'Paul Newman', 
    'Quincy Jones', 'Rachel Green', 'Steve Jobs', 'Tina Turner'
  ];
  const randomIndex = Math.floor(Math.random() * names.length);
  return names[randomIndex];
}


function YoutubeChat() {
  const [comments, setComments] = useState(COMMENTS);
  const myRef= useRef()

 async function fetchData(){
   //make API call
   const response = await fetch('https://jsonplaceholder.typicode.com/comments/1');
   const data = await response.json();
   console.log(data);
   const newComment={
    id:1,
    name:generateRandomName(),
    comment:data.body,
    avatar:'https://avatar.iran.liara.run/public'
   }
   setComments(prev=>{

    let  oldData=[...prev]
    if(oldData?.length>5){
      console.log("Yes more than 5")
      oldData = oldData.slice(-5);
      console.log("oldData",oldData)
    }
    return [...oldData,newComment]
   })

  if (myRef.current) {
    myRef.current.scrollTop = myRef.current.scrollHeight;
  }

 
  }


  useEffect(() => {
    const s = setInterval(() => {
      fetchData()
    }, 5000);
    return () => clearInterval(s);
  }, []);
  return (
    <div>
      <h2 className='mb-2 text-3xl font-bold text-red-600'>Youtube </h2>
      <div className='flex gap-4 flex-wrap'>
        <iframe
          className='h-[600px] md:w-2/3 w-full'
          src='https://www.youtube.com/embed/dQw4w9WgXcQ'
          title='Youtube'
        />
        <div className='h-[600px] md:w-1/3 w-full flex gap-4   border p-5 mx-h-[600px] overflow-y-auto  flex-col' ref={myRef}>
          {comments?.map((item) => (
            <SingleComment key={item.id} {...item} />
          ))}
        </div>
      </div>
    </div>
  );
}

export default YoutubeChat;

function SingleComment({ name, comment, avatar }) {
  return (
    <div className='flex gap-2 '>
      <img src={avatar} alt='user' className='h-10 w-10 rounded-full' />
      <div className='flex flex-col'>
        <span className='text-sm font-bold'>{name}</span>
        <span className='text-sm'>{comment}</span>
      </div>
    </div>
  );
}

```


 LLD: Youtube live chat UI

### Low-Level Design in Frontend

In React, everything is a component. Even on a web page, whatever we see is an element, and a collection of elements forms a component—like an image component or a logo component. A composition of multiple components forms a complete web page. Components are the **building blocks** of a web page.

### Low-Level Design in Frontend

**Front-end low-level design** refers to **the detailed, component-level design process** within a web application's user interface. It focuses on the **specific implementation of individual features** like buttons, forms, or modals, their interactions, rendering patterns, and performance considerations.

So, it’s all about **how code is written** and **how components are structured**.

If you are asked to design a web page with a **navbar and some cards**, it will look like this:

![image.png](/public/images/blogs/lld_compo_2.png)

Code wise it will look like this

```jsx
<AppCOmponent>
  <Header>
     <left>
       <logo>
           <img>
       </logo>
      </left>
      <right>
         <nav elements/>
      </right> 
   <Header/>         
```

### Low-Level Design in Frontend

In an interview, you need to **explain everything clearly** to show that you have proper knowledge of **how to structure and design** an entire web application.

You should be able to **talk about**:

* **Scrollbars** (horizontal, vertical) and how they work.
* **Which libraries** you will use to enhance user experience.
* **How to design platforms** like **YouTube**—where components will be placed, how many components will be there, and how they will interact.

Your code should be:

✅ **Modular**

✅ **Reusable**

✅ **Readable**

✅ **Testable**

✅ **Scalable**

### Design a Sidebar

If an interviewer asks you to **design a sidebar with a toggle state**, you need to **explain**:

* **Where** to place your components.
* **How** to manage state properly.
* **How** to structure the component for efficiency.

[Check out my **portfolio** where I have written notes on this! ](https://github.com/ashumsd7/heyashu/)🚀

![image.png](/public/images/blogs/lld_compo_3.png)

### Component Hierarchy

**Before writing code**, focusing on **component hierarchy** is **a must**. It helps in:

✅ **Better structure**

✅ **Easier maintenance**

✅ **Less refactoring in the future**

**Always plan** your components on **digital notes or a notebook** before writing code. This ensures **efficient design** and **scalability** in your project.

- - -

### SOLID Principle

**S: Single Responsibility Principle (SRP)**

* This applies to **components** as well.
* **A component should have a single responsibility**—don't write **500-600 lines of code** in one component.
* If a file is too big, **break it down into smaller reusable components**.

📌 We will discuss **other SOLID principles** later—stay tuned!

- - -

### Higher-Order Components (HOC)

A **Higher-Order Component (HOC)** is a component that **wraps another component** to **add extra features**.

Example:

* Suppose you have a **Card** component.
* You want to **add a "Pro" tag** for premium users.
* Instead of **modifying the existing Card component**, create a new **PromotedCard** component that **wraps** the Card component and adds the "Pro" tag.

  ![](/public/images/blogs/lld_compoi_4.png)

➡️ **HOC takes a component as input and returns a new enhanced component.**


Low Level Design : Component Design

As the name suggests, **Long Polling** means something is long, delayed, or not happening instantly.

First, if you haven't checked what **Short Polling** is, read this blog—it will take just 2 minutes to learn: **[[Read Here](https://heyashu.in/digital-garden/notes/front-end-design-system/what-is-short-polling-learn-with-example)]**

### Quick Recap of Short Polling

In **short polling**, the system checks for data at regular intervals, useful for chat notifications or small applications where data is light, and backend or database operations are minimal.

### What’s Different in Long Polling?

Everything is the same, except for one key difference—you don’t get a response immediately after one request. Instead, the server **waits** until the requested data **changes** before responding.

### What if the data never changes?

Good question! If no change happens within a set **timeout**, the server responds with whatever data is available, even if unchanged.

So, in **long polling**, the connection stays open until new data arrives or the timeout occurs. 🚀

4o

![image.png](/public/images/blogs/lp_2.png)

### Characteristics of Long Polling

* Single long-lived connection
* Connection stays open until new data arrives or a timeout occurs
* Reduces the number of API calls, lowering latency
* Puts load on the server due to persistent connections, leading to scaling issues

### Use Cases

* Real-time collaboration
* When data updates every few minutes or hours, not in seconds

### How It Works

When the frontend (client) makes a request, it also sends an identifier (like the last updated data ID). The backend checks this against the current data.

* If new data is available, the server responds immediately.
* If no change is found, the connection stays open and waits.
* When the server detects a change (from any request), it sends the updated data to all waiting clients.

### Let's Code!

Now, it's time to code! Clone this repo if you want to see it live:

**[GitHub Repo](https://github.com/ashumsd7/web-communication-techniques)** 🚀

```jsx
git clone https://github.com/ashumsd7/web-communication-techniques.git
cd web-communication-techniques
npm i
npm run long-polling
-------------------
Open browser and type
http://localhost:3000/ // Observe API Calls in network tab
```

![image.png](/public/images/blogs/lp_3.png)

### Let's Understand the Code

### 1. Server

If you look at the code below, we have an endpoint `/getData`. When someone hits **[localhost:3000/getData](http://localhost:3000/getData)**, the frontend calls this API with an **empty string** the first time.

* The server **checks for changes** and responds with `"2013 Congress Government"`.
* The frontend **receives this data**, prints it, and then **calls `fetchData` again**, sending `"2013 Congress Government"` as the last received data.
* Now, if there's **no change**, the server **holds** all new requests in a waitlist.
* Whenever new data arrives, the server **releases all waiting requests** and sends the updated data.

```markdown
// Initial data value
let data = "2013 Congress Government";

// Array to store waiting client connections
const waitingClientList = [];

/**
 * Long polling endpoint to get data
 * Clients connect and wait for data changes
 */
app.get("/getData", (req, res) => {
  console.log("\n🔄 GET /getData");
  console.log("📱 Client's last known data:", req.query.lastData);
  console.log("💾 Current server data:", data);

  // If data has changed since client's last request
  if (data !== req.query.lastData) {
    console.log("✨ Data changed - sending new data to client");
    res.send(data);
  } else {
    // If no change, hold the connection
    console.log("⏳ No data change - adding client to waiting list");
    waitingClientList.push(res);
    console.log("👥 Current waiting clients:", waitingClientList.length);
  }
});
```

Client when web page loads on [localhost:3000](http://localhost:3000) first time 

```html
 <script>
        let lastData="";
        function fetchData(lastData) {
            // first time u send the data with lastData as empty string
            fetch('http://localhost:3000/getData?lastData='+lastData)
                .then(response => response.text())
                .then(data => {
                    // serves sees the lastData is empty string and sends the data 
                    // because the data is changed and u r putting the data in lastData and polling again
                    document.getElementById('currentTime').textContent = data;
                    console.log("Got the data from server  polling again with data",data);
                    lastData=data;
                    fetchData(data);
        
                    // after getting the data polling again
               
                })
                .catch(error => {
                    console.error('Error fetching data:', error);
                });
        }

        // Fetch data immediately and then every 2 seconds
        fetchData();
      
    </script>
```

### When data changes

### When Data Changes

Now, someone needs to update the data from anywhere. So, we have created an endpoint to update the data:

**http://localhost:3000/updateData?newData=BJP_GOVT_2014**

* When this request is made, the server **detects the data change**.
* It then **notifies all waiting clients**.
* Any client that previously had `"2013 Congress Government"` will now receive `"BJP_GOVT_2014"`.

This demonstrates how **long polling** works—holding requests and responding only when new data is available. 🚀

![image.png](/public/images/blogs/lp_4.png)

Server Update Data code

```jsx
 */
app.get("/updateData", (req, res) => {
  console.log("\n🔄 GET /updateData");
  const newData = req.query.newData;
  
  console.log("📝 Old data:", data);
  console.log("✨ New data:", newData);
  
  // Update the data
  data = newData;

  // Notify all waiting clients
  console.log(`📢 Notifying ${waitingClientList.length} waiting clients`);
  waitingClientList.forEach(client => {
    client.send(data);
  });

  // Clear the waiting list
  waitingClientList.length = 0;
  console.log("🧹 Waiting list cleared");

  res.send("Data updated successfully");
});
```

So, that’s all about **Long Polling**! 🎯

It was a long blog, but I wanted to make sure you understand it well.

See you in the next topic! 👋 Bye-bye! 🚀


Practical Guide Long Polling 

In any web app, there are two types of layers:

1. **UI Layer** – This refers to any UI elements you see on the webpage.
2. **Data Layer** – This is where the data is defined. It serves as the actual data source for the UI application.

The UI layer is controlled by the data layer. The data layer is responsible for everything happening in the app, including bugs and data changes.

### Why Do We Need State?

Each UI element has some interactivity where data changes dynamically. To manage this changing data, we need a place to store and update it. This is where **state** comes in—it allows us to track and manage dynamic data in a web app.

### Local State

Suppose your UI layer has cards like this (refer to the screenshot below).

![image.png](/public/images/blogs/sm_2.png)

In a card, we need an **image source, heading, and tags**, correct? Where does this data come from? It comes from a **data source**, which is the **data layer**. In a React app, this data is usually stored in the **local state** of the file where the card is defined using HTML or JSX.

That's why **local state** is needed for UI elements—it holds the dynamic data of the app to display information in the UI layer.

### Props Drilling

Suppose you have multiple cards managed by a **parent component**, and each card (a child of the parent) has **more children**. The cards share an **identical data set** coming from a single source.

To pass data to each card, the best approach is to store the data in the **parent component** and then pass it down to all child components instead of managing data individually in each card.

This process—**passing data from parent to child to child**—is called **props drilling**. It follows a **unidirectional data flow**, which is a core concept in React.

![image.png](/public/images/blogs/sm_3.png)

### State Lifting

In React, child components **cannot communicate directly** with each other. This is a limitation.

Suppose **Child 1** has some data that affects **Child 2**. If data changes in **Child 1**, it should also update **Child 2**. But since children can’t communicate directly, how do we manage this?

This is where **state lifting** comes in. Instead of keeping the state in **Child 1**, we move it to the **parent component**. This way, both **Child 1** and **Child 2** can access and modify the state through the parent.

Moving state from a child component to the parent component is called **state lifting**.

### State Management Libraries

We manage state within local components, but **why do we need libraries for state management?**

In **large applications** with multiple pages, managing data becomes difficult due to a **complex component hierarchy**. Suppose data from **Component A (Page 1)** needs to be shared with **Component B (Page 2)**—passing it manually would be **too complicated**.

**State management libraries** solve this by creating a **centralized store** where all app data is stored. Every component reads and updates data from this store, preventing **prop drilling** issues.

And it's all **reactive**.

**Reactive** means that when the **data changes**, the **component re-renders** automatically to reflect the updated state. 

Each framework has its own state management libraries. For React, I have attached a screenshot you can refer to below.

![image.png](/public/images/blogs/sm_4.png)

### Context API

**Remember:** State management libraries are only required for **medium and large-scale projects**, not for small projects.

For **small-scale projects**, you can use **local state and props drilling**. However, React provides another built-in feature that allows you to **share data across components** without installing any third-party library—this is the **Context API**.

With **Context API**, you can define your data in the **root app** or any specific component, making it accessible to all components **page-wise or as needed**.


LLD: State Managemnet and Libraries

State Managemnet and Libraries

If we want **multi-language support** in our app, where users can select a language based on **localization**, we should load our website in the **local language**.

This is all possible based on **config-driven UI**, using:

1. A **JSON file or**
2. **Calling an API** when a language is selected from the dropdown.

### [Read: What is config driven UI](https://heyashu.in/digital-garden/notes/front-end-design-system/what-is-config-driven-ui)

A **config-driven UI** means that the UI is controlled by **configuration files** instead of hardcoded values.

![image.png](/public/images/blogs/mls_2.png)

So it's all possible because of **Config-Driven UI**.

The **JSON** is responsible for the **web page content** getting changed based on the **selected language**.

In the same way, you can use a **store** to manage data where the language is updated based on the selected language.

**For example:**

```jsx
const jsonData = {
    en: [
      { id: 1, title: 'Welcome', description: 'Welcome to our multi-language support page' },
      { id: 2, title: 'Features', description: 'Explore the features of our application' },
      { id: 3, title: 'Contact Us', description: 'Get in touch with our support team' },
      { id: 4, title: 'About Us', description: 'Learn more about our company and values' },
      { id: 5, title: 'FAQ', description: 'Frequently Asked Questions' }
    ],
    hi: [
      { id: 1, title: 'स्वागत है', description: 'हमारे बहुभाषी समर्थन पृष्ठ पर आपका स्वागत है' },
      { id: 2, title: 'विशेषताएँ', description: 'हमारे अनुप्रयोग की विशेषताओं का अन्वेषण करें' },
      { id: 3, title: 'संपर्क करें', description: 'हमारी समर्थन टीम से संपर्क करें' },
      { id: 4, title: 'हमारे बारे में', description: 'हमारी कंपनी और मूल्यों के बारे में अधिक जानें' },
      { id: 5, title: 'सामान्य प्रश्न', description: 'अक्सर पूछे जाने वाले प्रश्न' }
      //..... other lang
      ]
      }
```

Live link : https://heyashu-react.netlify.app/multi-lang-support

Code Link: https://github.dev/ashumsd7/react-playground-2025/blob/main/src/pages/MultiLangSupport.jsx


LLD: Multi Languages Support

Web Multi Languages Support

In this guide, we’ll dive deep into the **DOM**, how content gets rendered on a web page, how data comes from the server, different rendering types, and more.

### Types of Rendering

1. **Client-Side Rendering (CSR)**
2. **Server-Side Rendering (SSR)**

In SSR, there are two key variations:

* **SSR (Server-Side Rendering):** Content is generated on demand.
* **SSG (Static Site Generation):** Pages are pre-generated at build time.

A mix of **SSR and CSR** is known as **React Server Components (RSC)**, a new concept in modern web development.

### Client-Side Rendering (CSR)

I’ve written a simple functional component in **Next.js** that renders a page using CSR. You can observe how everything happens on the client side.

GitHub repo:[ (link)](https://github.com/ashumsd7/web-rendering-patterns)



```jsx
import React, { useEffect, useState } from "react";
import Link from 'next/link';

export default function CSRPage() {
  const [videos, setVideos] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    const fetchVideos = async () => {
      try {
        const response = await fetch('http://localhost:3002/videos');
        const data = await response.json();
        setVideos(data);
      } catch (error) {
        console.error('Error fetching videos:', error);
      } finally {
        setLoading(false);
      }
    };

    fetchVideos();
  }, []);

  if (loading) {
    return <div>Loading...</div>;
  }

  return (
    <div className="container mx-auto p-4">
      <div className="flex justify-between items-center mb-6">
        <h1 className="text-2xl font-bold">Video Tutorials (CSR)</h1>
        <Link href="/ssr-page">
          <button className="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
            Go to SSR Page
          </button>
        </Link>
      </div>
      <div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6">
        {videos.map((video) => (
          <div key={video.id} className="border rounded-lg overflow-hidden shadow-lg">
            <img src={video.image} alt={video.title} className="w-full h-48 object-cover" />
            <div className="p-4">
              <h2 className="text-xl font-semibold mb-2">{video.title}</h2>
              <p className="text-gray-600 mb-2">{video.description}</p>
              <p className="text-sm text-gray-500">Watch time: {video.watchTime}</p>
            </div>
          </div>
        ))}
      </div>
    </div>
  );
}

// 
```



[](<>)

### Client-Side Rendering (CSR)

In CSR, the browser first loads the HTML, then fetches CSS, JavaScript, images, and API calls before rendering the page. **Hydration** happens in between, where event listeners are added to the DOM elements.

A key issue with CSR is that **LCP (Largest Contentful Paint) gets delayed** since everything loads before the largest content element is painted.

![](/public/images/blogs/red_2.png)

### Hydration

In client-side rendering, **hydration** is the process where a JavaScript framework like React takes static HTML and transforms it into an interactive web page by attaching event listeners and application state to existing DOM elements.

### Server-Side Rendering (SSR)

In SSR, everything—HTML, API calls, JS execution, and CSS—is processed on the server. The generated HTML is sent to the browser, making the page appear faster.

However, **hydration still happens in the browser**, where event listeners are attached to make the page interactive.

```jsx
import React from "react";
import Link from 'next/link';

export default function SSRPage({ videos }) {
  return (
    <div className="container mx-auto p-4">
      <div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6">
        {videos.map((video) => (
          <div key={video.id} className="border rounded-lg overflow-hidden shadow-lg">
            <img src={video.image} alt={video.title} className="w-full h-48 object-cover" />
            <div className="p-4">
              <h2 className="text-xl font-semibold mb-2">{video.title}</h2>
              <p className="text-gray-600 mb-2">{video.description}</p>
              <p className="text-sm text-gray-500">Watch time: {video.watchTime}</p>
            </div>
          </div>
        ))}
      </div>
    </div>
  );
}

export async function getServerSideProps() {
  try {
    const response = await fetch('http://localhost:3002/videos');
    const videos = await response.json();

    return {
      props: {
        videos,
      },
    };
  } catch (error) {
    console.error('Error fetching videos:', error);
    return {
      props: {
        videos: [],
      },
    };
  }
}
```

[](<>)

![](/public/images/blogs/rend_3.png)

In SSR, you can see the API call, but no image load, as the API is handled on the server, not on the client.

[](<>)

![](/public/images/blogs/red_31.png)

We need to avoid things that take too much time on the first load. If your first page relies on props in SSR and loads after 3 seconds, LCP gets impacted, so be aware.

**[GitHub Repo: ](https://github.com/ashumsd7/web-rendering-patterns)**

### Static Site Generation (SSG)

SSG is a technique similar to SSR, but instead of generating the page dynamically for each request, it pre-generates and stores the page on the server, serving it directly to the client without rebuilding it.

SSG is best for pages that don't change frequently, like blogs or static content. If data changes frequently (e.g., user-specific data), SSR is a better choice.

![](/public/images/blogs/red_4.png)

* **SSR**: Use when data changes dynamically for each request.
* **SSG**: Use when content is mostly static and doesn't require frequent updates.

In SSG, we use `getStaticProps` instead of `getServerSideProps`.

```jsx
import React from "react";
import Link from 'next/link';

export default function SSGPage({ videos }) {
  return (
    <div className="container mx-auto p-4">
      <div className="flex justify-between items-center mb-6">
        <h1 className="text-2xl font-bold">Video Tutorials (SSG)</h1>
        <Link href="/csr-page">
          <button className="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
            Go to CSR Page
          </button>
        </Link>
      </div>
      <div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6">
        {videos.map((video) => (
          <div key={video.id} className="border rounded-lg overflow-hidden shadow-lg">
            <img src={video.image} alt={video.title} className="w-full h-48 object-cover" />
            <div className="p-4">
              <h2 className="text-xl font-semibold mb-2">{video.title}</h2>
              <p className="text-gray-600 mb-2">{video.description}</p>
              <p className="text-sm text-gray-500">Watch time: {video.watchTime}</p>
            </div>
          </div>
        ))}
      </div>
    </div>
  );
}

export async function getStaticProps() {
  try {
    const response = await fetch('http://localhost:3002/videos');
    const videos = await response.json();
    return {
      props: {
        videos,
      },
    };
  } catch (error) {
    console.error('Error fetching videos:', error);
    return {
      props: {
        videos: [],
      },
    };
  }
}
```

No matter how much time `http://localhost:3002/videos` takes, SSG will keep it handy as a built file and serve it without calling the API again. This never happens with SSR because SSR calls everything, including APIs, on each request.

### React Server Components (RSC)

In SSR, everything gets rendered on the server. However, in React Server Components (RSC), we decide **what to render on the server** and **what to render on the client**—that's the only difference.

**Documentation:** [Understanding React Server Components](https://vercel.com/blog/understanding-react-server-components)

To mark a component as a client component, add `'use client'` at the top before defining the

![image.png](attachment:71f87a86-461e-49e7-af30-fe932f0e9fe2:image.png)

### Benefits of React Server Components

1. **Data Fetching** – Fetch data directly on the server, reducing client-side API calls.
2. **Security** – Sensitive logic stays on the server, preventing exposure to the client.
3. **Caching** – Server-side caching optimizes performance and reduces redundant requests.
4. **Bundle Size** – Smaller client-side bundle, improving load time.
5. **Initial Page Load** – Faster load times as less JavaScript is shipped to the client.
6. **Streaming** – Allows progressive rendering, improving perceived performance.
7. **SEO** – Pre-rendered content improves search engine indexing.

I will create a proper repo for server components in the future. Meanwhile, you can keep checking or learn from YouTube or articles.


What are Web Rendering Patterns

Web Rendering Patterns

URL is the most important part of any web app. Changing it after production is not a good idea from both a user perspective and a developer perspective. Changing it later affects the entire file structure, which is not good. Changing routes is also not good for SEO and your website ranking.

So, we need to choose routes carefully and protect them wherever required.

We will discuss all of that.

A best practice, if you are changing routes, is to redirect from the old to the new route. However, users may not have a good experience with this approach, but there is no better solution than redirection.

### A Bit About History

There used to be multiple-page applications (MPAs) with files like `index.html`, `about.html`, `contact.html`, etc. When new frameworks emerged, they started following the SPA (Single Page Application) approach. Technically, everything happens on a single page, but users see different routes without page reloads. In traditional MPAs, switching pages caused a full reload, which was not the best user experience.

Over time, frameworks evolved, and they introduced routing packages, either developed by them or third-party libraries.

**Libraries:**

- For Angular, there is a different library.
- For Vue.js, there is another one.
- For React, the widely used library is `react-router-dom`.

### Interview Perspective

If asked about routing in an interview, you should be able to talk for about five minutes on how you manage routes and their best practices.

### Protected Routes

In any web app, some routes are accessible to all users, while others are restricted. For example:

- `/about` and `/terms` can be accessed by everyone.
- `/billing` should be restricted because it contains user-specific billing details.

These restricted routes fall under **protected routes**, so during route design, you need to ensure they are not visible to unauthorized users.

To handle protected routes, we create a wrapper in code that restricts access to non-public routes, ensuring only logged-in users can visit them.

I will soon share the code and a GitHub repo link. Stay tuned!


Web Routing & Protected Routes

Let’s learn about WebSockets. This is another way to communicate from the client to the server, just like short polling and long polling, but it is more commonly used. It supports full-duplex communication. Now you might wonder, what is full-duplex? Full-duplex means data can be transmitted in both directions simultaneously—both parties can send data to each other without any interruption. Here, the parties are the backend and the frontend, or the client and the server.

Unlike short polling and long polling, which rely on HTTP, WebSockets are a completely different technology. It works based on a single, live TCP connection, allowing continuous and bidirectional communication.

![image.png](/public/images/blogs/ws_2.png)

The first handshake happens over an HTTP connection, which is then upgraded to WebSockets using the **101 Switching Protocols** method. After this, a new connection is established, and a long-lived TCP connection is maintained. This connection stays open until it is explicitly closed from either the backend or the frontend. During this time, bidirectional data flows continuously.

We will discuss all of this in detail, but first, let’s build something and see it in action.

### Code

We’ve built a simple chat UI with an input box, a send button, and a section to display messages. However, there are two key problems we need to solve:

* When we type a message, it should be sent to the server.
* Anyone who has opened [localhost:3000](http://localhost:3000/) should receive the new message without reloading the page. This is the essence of a duplex connection. Messages should flow seamlessly between clients. If someone types a message, it should appear on my screen, and vice versa.

How will we make this possible?

### [Socket.io](http://socket.io/) / WebSockets

We are going to use **Socket.io**, a technology designed for bidirectional and low-latency communication across platforms. You can read the documentation by [clicking here](https://socket.io/).

Remember, WebSocket is also available as an [NPM library](https://www.npmjs.com/package/websocket), but here we’ll implement this using [Socket.io](http://socket.io/).

```markdown
git clone https://github.com/ashumsd7/web-communication-techniques.git
cd web-communication-techniques
npm i
npm run web socket
-------------------
Open browser and type
http://localhost:3000/ // Observe network tab
```

After installing all the dependencies, you can close the repo. Then, go to this URL: **[localhost](http://localhost/)**, and your application will be running after executing the following command:

```bash
npm run web-sockets
```

### Server Code

If you’ve already installed and run your application, you should be familiar with everything. But if not, here’s the backend code. The backend handles the WebSocket connection to send and receive messages.

```jsx
const server = http.createServer(app);

// Step 0 : import socket.io
const { Server } = require("socket.io");
// creating Instance of socket.io
const io = new Server(server);

// Step1 : when connection is established
io.on("connection", (socket) => {
  console.log("🚀 Connection Established");

  // Step1a : when we receive a message : Listening for the event
  socket.on("chat-message", (message) => {
    console.log("🚀 Message Received", message);
    // Step1aa : emit the message to all connected clients : Broadcasting the message
    io.emit("chat-message", message);
  });

  // Step1b : when connection is disconnected
  socket.on("disconnect", () => {
    console.log("🚀 Disconnected");
  });
});
```

### Step 0: Imports and Creating the Server

The first step is all about importing the necessary modules and creating a server.

### Step 1: Establishing the Connection

When the connection is established, you’ll see **"Connection Established"** in the console. Inside the callback function where you receive the `socket` as a parameter, you can listen for messages.

* **Step 1a:** Use `socket.on('chat-message')` to listen for the `'chat-message'` event. This event name should be the same on the client side while sending the message. We’ll see that client-side code soon.
* **Step 1aa:** Once you receive the message, you can broadcast it to all connected clients using `socket.emit()`. This ensures that every client gets notified of the new message.
* **Step 1b:** Finally, handle the disconnection using `socket.on('disconnect')`. This will trigger when a connection gets disconnected.

Now, let’s see how it works on the frontend.

![image.png](/public/images/blogs/ws_3.png)

Now, let's dive into the code and understand the core logic of WebSockets.

```html
const socket = io();

    console.log("🚀 Socket From frontend", socket);

    function sendMessage() {
      const message = messageInput.value.trim();
      if (message) {
        console.log('Sending message:', message);
        // emiting message to the server
        socket.emit("chat-message", message);
        // Add message to messages div
  
      }
    }

    // listening for the message from the server :auto receive the message
    socket.on("chat-message", (message) => {
      console.log("🚀 Message Received From Server", message);
      // Add message to messages div
      const messageElement = document.createElement('div');
      messageElement.className = 'message';
      messageElement.textContent = message;
      messagesDiv.appendChild(messageElement);
      // Auto scroll to bottom
      messagesDiv.scrollTop = messagesDiv.scrollHeight;

      // Clear input
      messageInput.value = '';
    });
```

So, if you look above, you will see that you have one active connection with the CDN in the HTML part. When you type and send a message in the `sendMessage` function, you emit a message to the server. You can see that the same event name, `chat-message`, is used here. Now, you can see one more `.on` event, as we've seen in the server code. This event gets fired automatically when the server emits it. In that `.on` message, we are just appending the received message to the HTML. Now, let's see the console to understand how it works.

### Inspection

Let's check the browser's dev tools. When you first visit [localhost:3000](http://localhost:3000/), in the screenshot below, you can see `101 Switching Protocols`, where the HTTPS connection gets upgraded to WebSocket. This connection is long-lived until either party disconnects.

![image.png](/public/images/blogs/ws_4.png)

If you switch to the messages tab and then send a message from the UI, you will see the message count and the actual message in the screenshot below. Now, notice that this is a WebSocket connection, not an HTTPS connection anymore.

![image.png](/public/images/blogs/ws_5.png)

Now, the question arises: is this really worth it? You’re sending messages to everyone, so how does exclusivity work? Yes, this is not limited—WebSocket is vast. You can create rooms, send requests to only one user (one-to-one connection), group connections, and more. This was just an overview, so keep exploring and learning.

Remember: as the web has `https` and `http`, similarly with WebSockets, you have `ws://` and `wss://`.

There is also a concept of framing, where we send data in chunks.

### Use Cases

* Chat apps
* Analytics
* Financial trading
* Online gaming
* Collaborations

### Challenges

* It uses a lot of resources based on the number of users due to long-lived connections.
* Connection limits.
* Strict sessions (read about load balancers—Google it).
* Authentication can be a challenge (example it).
* Cache layers.
* Scaling issues (not as good as long-polling and short-polling).
* Testing and debugging.
* Backward compatibility: what if the connection gets disturbed?
* Resource cleanup.
*

Now, that's all for this blog. See you in the next one!

Also checkout : 

* **[How the web works](https://heyashu.in/digital-garden/notes/front-end-design-system/how-the-web-works)**
* **[Communication Protocols](https://heyashu.in/digital-garden/notes/front-end-design-system/communication-protocols)**
* **[HTTP Headers Methods Status Codes](https://heyashu.in/digital-garden/notes/front-end-design-system/http-headers-methods-status-codes-and-rest-api-deep-dive)**


Web Socket Lets Chat

So, we know **why performance is important**, but how do we measure changes? Where do we monitor, and how do we track metrics? Let’s dive into **Performance Metrics / Core Web Vitals.**

### Performance Metrics / Core Web Vitals

Let’s discuss **performance optimization**, starting with **Core Web Vitals**. Now, the question is: What are “vitals”?

In the context of the human body, **vitals** are the critical organs, like the brain, liver, heart, and lungs, that are necessary to maintain life. Similarly, for the web, there are some **Core Web Vitals** that are crucial for website performance:

* **LCP (Largest Contentful Paint)**
* **FID (First Input Delay)**
* **CLS (Cumulative Layout Shift)**

These metrics help evaluate user experience and are essential for performance monitoring.

![image.png](/public/images/blogs/web_vital2.png)

We name it **Core Web Vitals** because there are multiple web vitals, but these three are the most important. For a web page, the journey is like this: first, it loads; then you interact with it; and finally, you consume the content, which may involve layout changes.

### **LCP (Largest Contentful Paint)**

LCP simply means **how much time it took to load the maximum elements of the web page**.

For example, as you can see in the above screenshot, if it takes **2.5 seconds** to load, it is good. If it takes between **2.5 to 4 seconds**, there is a need for improvement. If it takes more than **4 seconds**, then there is a serious issue, and the performance is bad.

Official documentation for LCP: [LCP Documentation](https://web.dev/articles/lcp)

### **FID (First Input Delay)**

FID measures the **time when an element becomes interactive**. The delay is counted from the time when the element is loaded until it is interactive.

* **Under 100ms** is great.
* **100ms to 300ms** needs improvement.
* **Above 300ms** indicates poor performance.

Official documentation for FID: [FID Documentation](https://web.dev/articles/fid)

### **CLS (Cumulative Layout Shift)**

CLS happens after the page loads when elements change their position unexpectedly. It measures the amount of layout shifting that happens and whether it's good or bad for the user experience.

There are formulas and techniques to calculate CLS, which can be seen in the screenshot above. We will discuss this in more detail later.

Official documentation for CLS: [CLS Documentation](https://web.dev/articles/cls)

let`s understand with example

![image.png](/public/images/blogs/web-vital-3.png)

Whatever appears first on the page is called **FCP (First Contentful Paint)**. It measures the time when the first thing appears on the page. Once most of the largest elements of the page are rendered, that’s called **LCP (Largest Contentful Paint)**. As shown in the screenshot above, LCP is when the major content appears.

The second section of the screen shows LCP, and after that, the page may still be rendering elements. You may not be able to interact with buttons or other elements because they are still loading. The time between FCP and when you can interact with the page is called **FID (First Input Delay)**.

Now, when elements are rendered on the page but something appears after that—like a side banner or an additional section—this should happen within a short time, not after several seconds. This is called a **layout shift**, also known as **CLS (Cumulative Layout Shift)**.

**Note:** It's important to mention that CLS can occur not just during the initial load but also when users scroll down the page. As new content is added or the layout shifts, CLS continues to happen throughout the user journey until the page is fully loaded and settled.

### **CLS with Example**

Let’s understand CLS better with a screenshot, so we can learn how to handle it properly.

![image.png](/public/images/blogs/web-vital-4.png)

As you can see in the screenshot above, when the page first loads, you get the main content of the webpage. Then, an ad panel appears from the top, causing the previous layout, which started at the top of the page, to shift down. This shift can also happen from the left or right side of the page, depending on the layout.

To better understand CLS and how it happens, let's first get a clear understanding of what it is and how it impacts the user experience.

### **How to Get the Score of Any Webpage**

To get the performance score of a webpage, there are multiple tools available, such as [PageSpeed Insights](https://pagespeed.web.dev/), **Microsoft Clarity**, and **Sentry**. We will discuss these tools in detail later, including how to improve performance.

When you use these tools, you will see results similar to the screenshot of **Google PageSpeed Insights** shown above.

![image.png](/public/images/blogs/web-viteal-5.png)

### **Let’s Measure in Real-Time Using Dev Tools**

You can go into the **Inspect Mode** of your website and select the **Performance** tab, just like you would with the **Console** or **Network** tabs. Click the **Record** button (the rounded button in the top-left corner) and then reload the page using the browser button. After a few seconds (around 5-6 seconds), stop the recording, or it will stop automatically.

In the same tab, you can also go to **Lighthouse** in Dev Tools to perform the same task and get detailed insights.

![image.png](/public/images/blogs/web-vital-6.png)

and after stoping it you will see somehtign liek this 

![image.png](/public/images/blogs/web-vital-7.png)

Where you can see **FCP**, **LCP**, and others, we will dig deeper properly later.

### **A New Metric That Is Core Now**

So, we have learned about **FID**, which is the time when we are able to click on any button for the first time. But as we know, we also interact with our page, and scripts get loaded when we scroll or interact. The **Input Delay** is also important for other elements that are added to the webpage later after interaction. To measure that, we have **INP (Interaction to Next Paint)**.

### **INP (Interaction to Next Paint)**

![image.png](/public/images/blogs/web-vital-8.png)

**INP (Interaction to Next Paint)** is a metric that measures how quickly a website responds to user interactions. It tracks the time it takes for things to load and become interactive. If the response time is within 500ms, it’s okay; otherwise, it’s not good. This metric was introduced in March 2024.

![image.png](/public/images/blogs/web-vital-9.png)

Let’s talk more about it.

There are many metrics, but some are user-centric and related to the user experience, while others are browser-related. As a developer, we should know which metrics relate to which persona.

### **Browser-Centric Metrics**

1. **TTFB (Time to First Byte)**: The time it takes to receive the first byte of data from the server to the client browser.
2. **Network Requests**: How many requests are needed to serve the page.
3. **DNS Resolution**: The time it takes to resolve the domain name to an IP address.
4. **Connection Time**: The time taken for the handshake and establishing the connection.
5. **DOM Content Loaded Time**: The time it takes for the DOM to be fully loaded.
6. **Page Load Event**: The event that signals the page has been fully loaded.

### **User-Centric Metrics**

1. **FCP (First Contentful Paint)**
2. **LCP (Largest Contentful Paint)**
3. **FID (First Input Delay)**
4. **INP (Interaction to Next Paint)**
5. **TBT (Total Blocking Time)**: The time between FCP and interactivity.
6. **CLS (Cumulative Layout Shift)**

Learn more here: [User-Centric Performance Metrics](https://web.dev/articles/user-centric-performance-metrics)

### Other Web Vitals

There are other vitals like **TTMFP** (Time to Maximum First Paint) and **TTI** (Time to Interactive) that can be monitored as well.

So that's all for this note. We’ll meet in the next one, where we’ll discuss the tools we can use to measure these metrics in detail.

Take care of your performance and health. Do exercise and stay healthy. See you, bye-bye!


FCP LCP CLS and INP The Core Web Vitals  ?

What are FCP LCP CLS and INP The Core Web Vitals 

Let’s talk about a modern way of real-time communication on the web: **Server-Sent Events (SSE)**. It’s supported by most modern browsers. So, let’s understand what this is.

First, a connection is made from the client, which is basically an HTTP connection. This connection is long-lived. Whenever new data is available on the server, it is sent to the client at regular intervals.

![image.png](/public/images/blogs/sse_2.png)

But there are a few key terms we need to understand:

* **Long-lived connection**
* **Unidirectional connection**
* **Single HTTP connection**

For example, on platforms like **LinkedIn** or **Twitter (X)**, you see notifications like *"New post available"* without refreshing the page. Similarly, in monitoring dashboards or notification systems, the client doesn’t have to do anything—the server pushes the updates automatically.

![image.png](/public/images/blogs/sse_3.png)

So now you might be thinking, **how does this work?** How does the data come through, and do we need any third-party libraries? 🤔

Let’s discuss these things. We receive data in the form of **event streams**.

### 🚀 How to Achieve This?

Generally, on the **server side**, we expose an **endpoint** where we send data as a stream with the content type `text/event-stream`.

On the **frontend**, we make an HTTP API call and use the **`EventSource`** API, which is natively supported by modern browsers. This allows us to listen for events sent by the server.

For now, on the server, we’ve mimicked the process by sending data as an event stream every 5 seconds.

### 📂 GitHub Repository

I’ve added a GitHub repo where you can clone the project, follow the commands, and see it in your browser. But if you really want to understand how it works—whether you run the code or not—I’ve provided the core code below.

```jsx
git clone https://github.com/ashumsd7/web-communication-techniques.git
cd web-communication-techniques
npm i
npm run server-side-events
-------------------
Open browser and type
http://localhost:3000/ // Observe network tab
```

### 💻 Server Code

Here’s the server’s core logic:

```jsx
app.get('/sse', (req, res) => {
 // data is going  to be long live 
  // data is going to be as event stream and no cache 
 res.setHeader('Content-Type','text/event-stream')
 res.setHeader('Connection', 'keep-alive')
 res.setHeader('Cache-Control', 'no-cache')
 // logic of data is going to be here : Database call 
 res.write('data: Hello, client! This is a test message.\n\n');

// after 5 seconds it will send random number 
const intervalId = setInterval(() => {
  res.write(`data: Random number: ${Math.floor(Math.random() * 100)}\n\n`);
 }, 5000);

 req.on('close', () => {
  console.log('Client disconnected');
  clearInterval(intervalId);
  res.end();
 });

});
```

So if you see above, we have an **endpoint** that will be called by the client. We are setting headers to:

* **Keep the connection alive** for a long-lived connection.
* Set the **Content-Type** as `text/event-stream`.
* Disable caching with **no-cache**.

Then, we are **writing the stream**, and after 5 seconds, we write again. So, any client that is **listening** to this will receive the data.

In between, you can add database logic or any other operations. This is just **mimicking the functionality** of Server-Sent Events (SSE).

Now, let’s look at the **frontend code**.

### 💻 Frontend Code

Here’s a snapshot of the frontend code where we use **`EventSource`** and wait for the data.

```jsx
 const eventSource = new EventSource('/sse');

    // Listen for messages
    eventSource.onmessage = function(event) {
      console.log('Event received:', event.data);
     
      
    };
```

So, it’s **super easy**! We are just **listening** to the event and logging it to the console.

Now, you can also **display it on the DOM** of your web page.

### 🔍 Let's Inspect It

After running the server, open **[localhost:3000](http://localhost:3000/)** in your web browser.

You will see the incoming data in the **console** and, if implemented, on the **webpage** as well.

![image.png](/public/images/blogs/sse_4.png)

A **long-lived** and **no-cache** request is being made. Right after that, you can see a tab labeled **"Event Stream"**, just like we had the **"Messages"** tab in WebSocket.

If you want to explore more about WebSocket, check out this blog:

👉 **[Learn WebSocket](https://heyashu.in/blog/web-socket-lets-chat)**

Here’s a **screenshot** showing what it looks like when we switch to the **Event Stream** tab:

![image.png](/public/images/blogs/sse_5.png)

Now, if you look at the **UI**, you’ll see that the data is getting **populated in real-time**! 🚀

This happens seamlessly as the server pushes new events to the client without any need for manual refreshes. Pretty cool, right?

![image.png](/public/images/blogs/sse_6.png)

### **Challenges**

1. Browser compatibility
2. Number of connections (6-8 per domain)
3. Reconnection logic
4. Background tab behavior
5. Resource utilization
6. Sticky connections
7. Proxies and firewalls
8. Testing and load balancing
9. Efficient broadcasting

So, that’s all for this one! More topics will be discussed in upcoming blogs, including **Webhooks**. Stay tuned! 👋 Bye bye!


Server Sent Events:   A Real time communication

What are Server Sent Events  A Real time communication

This is another technique used for real-time communication, commonly used in applications without being noticed. We use multiple services, and one such service is **Webhooks**. In this blog, we’ll understand Webhooks using the example of payment processing—how a payment is initiated from the browser and the confirmation received.

### Polling vs Webhooks in Payment Processing

Below is a screenshot comparing **Polling** and **Webhooks** for handling payments. Both methods are used for payment processing, but let’s first discuss **Polling**.

### Polling

In the polling method, API requests are sent to a payment service to check if the payment is processed, completed, or failed. The challenge with polling is that it’s a repetitive process, constantly checking for payment status, leading to unnecessary API calls.

This results in wasted resources as the server checks repeatedly, even when there’s no update, causing blocking and waiting. It’s an inefficient way to handle requests.

For more on Polling, read here: [Practical Guide to Long Polling](https://heyashu.in/blog/practical-guide-long-polling).

- - -

**Webhooks** offer a more efficient solution, notifying in real-time whenever the status changes. Stay tuned to learn more about how Webhooks solve this problem

![image.png](/public/images/blogs/wbh_-.png)

- - -

### Webhooks

Webhooks are **a way for applications to communicate with each other in real-time by sending data over HTTP**. They are triggered by specific events, such as a payment transaction. In this example, we provide a callback to a third-party service, which calls you back once the job is done. It’s an event-driven mechanism where webhooks know when to call and what methods to invoke, depending on the status.

There is also a retry mechanism for verification and acknowledgment.

### Things to Remember

* Real-time communication
* Event-driven
* POST REST API
* Payload, authorization, and secret key
* Retry, verification, and acknowledgment

### Usage

* Notification systems
* Data synchronization (performing other tasks once the main work is done)
* Automation (For example, on GitHub, once you push to the main branch, a mail is generated for deployment. This is all possible because of webhooks, or we can say webhooks are used behind the scenes.)

![image.png](/public/images/blogs/web_3.png)

If you visit the GitHub Webhook page, you will see a similar definition:

[GitHub Webhooks Documentation](https://docs.github.com/en/webhooks/about-webhooks)

**Webhooks provide a way for notifications to be delivered to an external web server whenever certain events occur on GitHub. You can add a webhook after watching some tutorials on Google.**

If you want to create a webhook in Node.js or enable something on GitHub, you can try it. But for now, I’m stopping the writing. We’ll meet in another blog. See you, bye-bye!


Introduction to Web hooks

What are web hooks

### Config-Driven UI

If a website runs globally but needs to show an ad campaign only in India, we use **Config-Driven Design**. This approach relies on a **JSON file** that defines the page layout and elements dynamically.

When the page loads for the first time, an API call fetches the config file, which determines how the **HTML structure** and content should be displayed. The order of elements and layout is controlled by this config.

📌 **Config ⇒ Defines the webpage layout**

📌 **Also known as Dynamic UI**

For example, **Swiggy** loads content dynamically based on the user’s location.

![image.png](/public/images/blogs/confog-2.png)

So basically, when **Swiggy** loads, it calls an API that returns a **config file**. This config defines how the page should look, including the layout and content, based on the user's location.

```jsx
fetch("https://www.swiggy.com/mapi/misc_new/skeleton?lat=28.4594965&lng=77.0266383");
```

Result Config

```jsx
{
    "statusCode": 0,
    "skeleton": {
        "statusMessage": "done successfully",
        "cards": [
            {
                "card": {
                    "card": {
                        "@type": "type.googleapis.com/swiggy.gandalf.widgets.v2.SearchBar",
                        "placeholder": "Search for restaurant, item or more",
                        "cta": {
                            "link": "swiggy://explore?keyboard=true",
                            "type": "DEEPLINK"
                        },
                        "height": 56
                    }
                }
            },
          ............
```

And based on the **config**, it renders the page. This is also known as **Backend-Driven UI** or **Server-Driven UI**.

### **Importance of Config-Driven UI**

* **Customizable**
* **Multiple UI variations based on location**
* **Better UI management**
* **No frontend code changes required**

You need to answer this way and keep these points in mind for **Config-Driven UI** before designing an application.


What is Config Driven UI

Shimmer UI is **a user interface that uses a moving animation to indicate that a web page or app is loading**. It is used to enhance the user experience by displaying a placeholder similar to the actual content until the real data loads.

That's it. I'm not providing a specific example—you are capable enough to understand this and develop it using any library or your own CSS and HTML. Display this component until the `isLoading` value is `true`.


What is Shimmer Effect

Ah, I see! Let’s imagine this scenario: You’re super hungry, but the kitchen is closed. You can’t just go in and make something yourself, so you’ve ordered food, but you’re not sure when it’ll be ready. What do you do? You can’t wait forever, so you keep knocking on the kitchen door at regular intervals, hoping to see if your food is ready yet.

Every few seconds, you knock again, checking if it’s time to eat. It’s not constant—just a brief check, then you wait and knock again after a short while. This is exactly like short polling. You keep checking for an update (your food being ready) at small intervals, without establishing a long connection, just knocking (or requesting) repeatedly until you get the response.

In short polling, just like you keep knocking, the system repeatedly asks for data at regular intervals, waiting for a response each time.

So, here we are going to discuss short polling, including its interview perspective with examples and code. So, let's not wait anymore and start learning.

It is a methodology we generally use to connect the front end to the backend—a communication technique.

Generally, when we need data, the front end calls an API and uses it. If you need data again, you call the API, and it provides the data after each request.

![image.png](/public/images/blogs/sp_2.png)

But what if you need this data quickly, like loading a cricket score, checking notifications from the backend, or seeing if the delivery boy has arrived? This is called the short polling technique, where you repeatedly call or check for results in real-time and need constant updates.

It is not a persistent connection but retrieves data after each call. We are not increasing or establishing a new connection over an existing one. Instead, we call the API each time, but the calling frequency is very high, happening again and again.

![image.png](/public/images/blogs/sp_3.png)

So, to check real-time data, you can use short polling. But remember, calling an API repeatedly is not scalable. If the API has limited resources, you can use this method, but for large-scale applications, it is not recommended.

### Usage of Short Polling

1. Real-time systems
2. Notification data
3. Cricinfo (cricket updates)
4. Analytics
5. Checking anything you need in real-time
6. Normal chat applications (not the best approach, but possible)

### Let's Code

Now, it's time to code! Clone this repo if you want to see it live:

[GitHub Repo](https://github.com/ashumsd7/web-communication-techniques)

```jsx
git clone https://github.com/ashumsd7/web-communication-techniques.git
cd web-communication-techniques
npm i
npm run short-polling
-------------------
Open browser and type
http://localhost:3000/ // Observe API Calls in network tab
```

When you visit http://localhost:3000/, you will see an API being called every 5 seconds. That is short polling in action.

```jsx
    <script>
        function fetchData() {
            fetch('http://localhost:3000/getData')
                .then(response => response.text())
                .then(data => {
                    document.getElementById('currentTime').textContent = data;
                })
                .catch(error => {
                    console.error('Error fetching data:', error);
                });
        }

        // Fetch data immediately and then every 2 seconds
        fetchData();
        // Do not forget to clear this interval 
        setInterval(fetchData, 5000);
    </script>
```

So, in the above example, you will see a function called `fetchData`, which is being called every 5 seconds. Each time it runs, it fetches data from `/getData` and updates the web page.

After closing the project, if you observe the API calls, you will notice that it is being called repeatedly at regular intervals. See the screenshot below for reference.

![image.png](/public/images/blogs/sp_4.png)

Zoom in on the page and observe the timing—it’s just 2, 4, 6, or 7 milliseconds, which is very low. The resources used are also minimal, just a few bytes.

So, short polling is only recommended when you need to load small amounts of data quickly on the web, and your requests are fast. For large-scale requirements, it is not recommended.

### Characteristics of Short Polling

1. Short-lived connection
2. No persistent data
3. Low resource usage
4. Scalability issues

That’s all for this topic! See you in long polling. Goodbye!


What is short polling! Learn with example

What is short polling!  Learn with example

Many companies today use **GraphQL**. In this blog, we’ll explore what GraphQL is, its benefits, and why it’s so popular. Be patient—it’s not an Instagram Reel, but for serious learners, it’ll be worth the read.

Here’s what we’ll cover:

1. What is GraphQL?
2. Why GraphQL? Its benefits
3. REST vs. GraphQL
4. Building blocks of GraphQL
5. Building a GraphQL app
6. Calling GraphQL from the client
7. Tools provided by the GraphQL community
8. Advanced features that make GraphQL powerful

- - -

### What is GraphQL?

Suppose your app needs information about continents, countries, and languages. If you’re using REST APIs, you’ll likely call multiple APIs to fetch this data and then organize it for your frontend.

(Read: [Deep Dive into REST APIs](https://heyashu.in/digital-garden/notes/front-end-design-system/http-headers-methods-status-codes-and-rest-api-deep-dive))

In GraphQL, however, you define **exactly** what data you need, and the **GraphQL server acts as a middle layer** to handle the request efficiently. This means the frontend gets only the data it asks for, reducing unnecessary load and improving performance.

Let’s see how!

![image.png](/public/images/blogs/g_2.jpg)

### More About GraphQL

GraphQL stands for **Graph Query Language**.

Imagine a graph where continents have countries, and countries have languages. It’s like a hierarchy where everything is interconnected, forming a graph structure. If you observe closely, almost everything on the planet is connected in some way, just like a graph.

This is why GraphQL is so powerful—it mirrors the way data is naturally structured. It allows us to efficiently query and showcase only the specific data we need in a frontend web app.

![image.png](/public/images/blogs/g_3.jpg)

GraphQL empowers the client by giving it the **flexibility and capability** to request exactly what data is needed—no more, no less.

The biggest benefit of GraphQL is that it allows you to fetch only the required information. For example, in the screenshot below, the client requests only `firstName` and `lastName`, and that’s exactly what the response includes.

Even if additional information like `userVillage` or `pincode` is available on the server, it won’t be sent unless explicitly requested. This avoids unnecessary data transfer, keeping the frontend clean and optimized.

This level of control is one of the key advantages of GraphQL over REST APIs.

You can try it out yourself using tools like GraphQL playground or GraphiQL!

https://studio.apollographql.com/sandbox/explorer

![image.png](/public/images/blogs/g_4.jpg)

### Benefits of GraphQL

1. **Avoids Overfetching:** Fetch only the data you need.
2. **Avoids Underfetching:** Retrieve all required data in a single request.
3. **Better Mobile Performance:** Mobile apps often need less data, and GraphQL ensures only the necessary information is sent.
4. **Efficiency and Precision:** Optimized data fetching leads to efficient performance.
5. **Declarative Data Fetching:** The frontend is in control of what data is needed.
6. **Structured and Hierarchical Data:** GraphQL organizes data in a structured and logical way.
7. **Strongly Typed Language:** GraphQL uses a schema that defines data types, reducing errors.
8. **Fewer Mistakes:** With type checking, there’s less room for errors in requests and responses.
9. **Introspection:** Unlike REST APIs, where you need to document endpoints, GraphQL comes with built-in introspection for easy exploration.
10. **Real-Time Capabilities:** GraphQL supports subscriptions for real-time updates.

- - -

### REST vs. GraphQL Comparison
- **Data Fetching**:
    - REST API: Requires multiple endpoints.
    - GraphQL: Uses a single endpoint for all data.
- **Request Structure**:
    - REST API: Fixed structure with HTTP methods.
    - GraphQL: Flexible, using queries and mutations.
- **Overfetching/Underfetching**:
    - REST API: Common issue.
    - GraphQL: Solved with precise queries.
- **Response Size**:
    - REST API: Fixed.
    - GraphQL: Flexible.
- **Versioning**:
    - REST API: Explicit versioning required.
    - GraphQL: No versioning needed due to flexible schema.
- **Schema Definition**:
    - REST API: Not well-defined.
    - GraphQL: Strongly defined schema.
- **Real-Time Capabilities**:
    - REST API: Polling and WebSockets.
    - GraphQL: Built-in subscriptions.
- **Tools**:
    - REST API: Postman.
    - GraphQL: GraphQL Playground.
- **Caching**:
    - REST API: Relies on HTTP caching.
    - GraphQL: Fine-grained caching possible.
- **Client Control**:
    - REST API: Server defines the response.
    - GraphQL: Client decides the response.
- **Adoption**:
    - REST API: Widely adopted.
    - GraphQL: Rapidly growing in popularity.

### More About GraphQL

GraphQL has two key components:

1. **Creator (Server):** Responsible for providing the data via GraphQL queries and mutations.
2. **Consumer (Client):** Sends requests to the server and consumes the data.

You can use a simple HTTP fetch request to interact with GraphQL. However, to fully leverage its benefits, it’s recommended to use libraries like **Apollo Client** or **graphql-hooks**.

Explore tools and libraries here: [GraphQL Community Tools](https://graphql.org/community/tools-and-libraries/?tags=javascript)

On the server side, you can use GraphQL server libraries.

- - -

### GraphQL Building Blocks

1. **Schema/Types:** Defines the structure of the data.

   * **Scalar Types:** Basic types like `Int`, `String`, `Boolean`, and `ID`.
   * **Custom Types:** Define complex types like `Country`, `Language`, etc., based on your data.

   GraphQL is a strongly typed language, and its schema is also known as **SDL (Schema Definition Language)**.
2. **Query/Mutations:**

   * **Query:** Used to fetch data.
   * **Mutation:** Used to update or modify data.

   Syntax for these will be covered in detail later.
3. **Resolver:** Contains the logic to fetch data from the database or perform updates.

- - -

### Creating a GraphQL Server

To create a server, you can use various libraries. For example, **Apollo Server** is a popular choice. Follow this guide to get started: [Apollo Server Documentation](https://www.apollographql.com/docs/apollo-server)

Alternatively, you can try the following commands to set up a basic GraphQL server:

```jsx
mkdir graphql-server-example
cd graphql-server-example
npm init --yes 
npm pkg set type="module"
npm install @apollo/server graphql

// create a index.js file 
// and wirte a script in package.json   "start": "node index.js"

// then paste this in index.js

// The ApolloServer constructor requires two parameters: your schema
import { ApolloServer } from "@apollo/server";
import { startStandaloneServer } from '@apollo/server/standalone';

// A schema is a collection of type definitions (hence "typeDefs")
// that together define the "shape" of queries that are executed against
// your data.
const typeDefs = `#graphql

# Comments in GraphQL strings (such as this one) start with the hash (#) symbol.

# This "Book" type defines the queryable fields for every book in our data source.
type Book {
  id: ID!
  name: String!
  author: String!
 
}
  type Author{
  id: ID!
  name: String!
  books: [Book]
  }

# The "Query" type is special: it lists all of the available queries that
# clients can execute, along with the return type for each. In this
# case, the "books" query returns an array of zero or more Books (defined above).
type Query {
  authors: [Author]
  books: [Book]
}
`;

const books = [
  {
    id: 1,
    name: 'The Awakening',
    author: 'Kate Chopin',
  },
  {
    id: 2,
    name: 'City of Glass',
    author: 'Paul Auster',
  },
];

const authors = [
  {
    id: 1,
    name: 'John Doe',
    books: [1, 2],
  },
];

const resolvers = {
  Query: {
    books: () => books,
    authors: () => authors,
  },
};

// definition and your set of resolvers.
const server = new ApolloServer({
  typeDefs,
  resolvers,
});

// Passing an ApolloServer instance to the `startStandaloneServer` function:
//  1. creates an Express app
//  2. installs your ApolloServer instance as middleware
//  3. prepares your app to handle incoming requests
const { url } = await startStandaloneServer(server, {
  listen: { port: 4000 },
});

console.log(`🚀  Server ready at: ${url}`);
```

### Overall Flow of GraphQL

In GraphQL, you work with:

1. **Type Definitions (TypeDefs):** Where you define the types, queries, and mutations.
2. **Resolvers:** For each query or mutation, you create a function with the same name as defined in your schema.

The **Apollo Server** acts as the bridge that connects these and ensures everything works together seamlessly.

When you run `npm start`, a GraphQL Playground opens where you can test your queries and fetch the data you need.

Here’s a screenshot for reference: (Insert your screenshot here)

![image.png](/public/images/blogs/g_5.jpg)

If you inspect the network tab and click the play button to run a query, you'll see headers and payload, similar to REST APIs.

```jsx
fetch("http://localhost:4000/", {
  "headers": {
    "accept": "*/*",
    "accept-language": "en-US,en;q=0.9,hi-IN;q=0.8,hi;q=0.7",
    "content-type": "application/json",
    "sec-ch-ua": "\"Google Chrome\";v=\"131\", \"Chromium\";v=\"131\", \"Not_A Brand\";v=\"24\"",
    "sec-ch-ua-mobile": "?1",
    "sec-ch-ua-platform": "\"Android\"",
    "sec-fetch-dest": "empty",
    "sec-fetch-mode": "cors",
    "sec-fetch-site": "same-origin"
  },
  "referrer": "http://localhost:4000/",
  "referrerPolicy": "strict-origin-when-cross-origin",
  "body": "{\"query\":\"query ExampleQuery {\\n  books {\\n    id\\n    name\\n  }\\n}\\n\",\"variables\":{},\"operationName\":\"ExampleQuery\"}",
  "method": "POST",
  "mode": "cors",
  "credentials": "include"
});
```

So, like this, you can create relationships between different data sets. You need to learn GraphQL properly, but the goal of this note was to make you familiar with these topics and help you become interview-ready when someone asks you about the difference between REST APIs and GraphQL. Similarly, you can add mutations into resolvers and typeDefs to handle updates.

For the frontend, there are client libraries like Apollo Client that can make things more efficient. There’s a lot more to learn, but that’s all for now.

Take care and bye!


Why GraphQL over Rest APIs

Let's talk about web performance—what is necessary to know for interviews and what is not. We'll cover the key aspects of web performance and everything you need to understand.

Here’s what we are going to learn:

1. Why performance matters
2. Performance metrics
3. Measuring performance and tools
4. How to monitor something already in production
5. How assets are accessed from the server to the client (Asset Optimization)
6. Rendering patterns: CSR, SSR, ISR, Server Components
7. Network optimization
8. React/Framework optimization
9. Build-level optimization
10. Semantic ways of writing code

### Why is Performance Important?

For a web developer, performance is not just an interview topic but an essential skill from junior to senior levels. Understanding performance helps developers work efficiently and become experts in their field. Let’s understand why performance matters:

* **Improving User Experience:** Users shouldn’t have to wait too long or see blank screens.
* **Productivity:** In apps like admin panels, everything should work instantly without long loading times.
* **Customer Satisfaction:** A fast and smooth experience keeps users happy.
* **Revenue & Profitability:** Use cost-effective services while maintaining the best performance.
* **Operational Costs:** Efficiently handling tickets and complaint systems reduces costs.
* **Competitive Advantage:** Compete with the best websites in your industry.
* **Google Ranking:** Performance impacts search rankings.
* **Business Metrics:** Align performance improvements with business goals.
* **Bounce Rate:** Avoid users leaving after opening your site for the first time.
* **Session Time:** Increase user engagement duration.
* **Understanding Users:** Know your end users and their needs.
* **User Device Percentage:** Analyze the percentage of users on different devices and optimize your website accordingly, especially for mobile.

For example, you can check real-time statistics on [Cloudflare Radar](https://radar.cloudflare.com/).

![image.png](/public/images/blogs/per_2.png)

For your website, you can use tools like **Google Analytics**, **Plausible Microsoft Clarity**, and other similar tools to measure these statistics. These tools provide insights into user behavior.

For example, if most of your users are on mobile, your app should be optimized for mobile-first and ensure a fully responsive design.

![image.png](/public/images/blogs/per_3.png)

Based on the internet quality of your users, you should optimize your app’s **DNS response time** and **latency**. There may be hundreds of parameters to analyze, but a few major ones should always be prioritized, and you should consider both **your server's and the user's CPU and GPU** performance. Heavy computations on the client side can slow down the browser or even cause crashes. Understanding these factors is crucial for optimizing performance.

Next, in upcoming posts, we will discuss all these points in detail, including **performance metrics, tools, and various optimization techniques**.

Stay tuned! **Bye-bye!** 🚀


FRONTEND SYSTEM DESIGN

Best Web Performance tools

For Real-Time Users

For Simulated Data

For Developer mode