Forem: Vishw Patel

How I Deploy My Backend to a VPS (Zero Downtime + Instant Rollbacks,Guide Included)

Vishw Patel — Wed, 04 Mar 2026 18:05:16 +0000

Deploying a backend to a VPS is easy.

Deploying it properly, with versioning, rollback support, persistent storage, and zero downtime, is what makes a system production-ready.

In this article, I'll show the exact deployment workflow I use for file converter project ConvertX.

https://convertx.vizzv.com

This setup gives me:

Versioned deployments
Instant rollback
Persistent database storage
Zero-downtime deployment
Clean release history

And the best part: it works with any backend.

Who This Article Is Perfect For

Indie hackers
SaaS founders
Junior backend developers
Developers moving from localhost to production
People renting their first VPS

If you want production reliability without Kubernetes-level complexity, this approach is for you.

The Core Idea

Instead of deploying directly into one folder like this:

/var/www/app

It overwrites the same folder every time.This is dangerous.

Instead, I use a release-based deployment structure. Each deployment creates a new immutable release, and the active version is controlled using a symlink.

A symlink (also called a symbolic link) is a type of file in Linux that points to another file or a folder on your computer. Symlinks are similar to shortcuts in Windows.

This simple idea changes everything.

Why Direct Folder Deployments Are Dangerous

When you deploy directly into one folder:

Files get partially overwritten
Old and new code can mix
Rollbacks are painful
Failed uploads leave broken states
Debugging becomes difficult

If deployment fails mid-upload, your app might be:

Half old version
Half new version
Completely broken

And you won't even know which files changed. That's how production outages happen.

Why Immutable Releases Matter

An immutable release means:

Once deployed, it is never modified
Each version lives in its own folder
Releases are timestamped
Old versions stay untouched

Benefits:

You can inspect any past version
Rollback is instant
Debugging becomes easier
No accidental file mutation

This pattern is used by professional deployment tools like Capistrano.

How This Mimics Capistrano-Style Deployments

Tools like Capistrano popularized this structure years ago:

app/
├── releases/
├── shared/
└── current -> releases/version

I simply implement the same architecture manually using:

rsync
symlinks
PM2

No heavy tooling required.

Server Directory Structure

/root/convertx
├── current → releases/20260117_2120
├── releases
│   ├── 20260104_2031
│   └── 20260117_2120
└── shared
    ├── .env
    └── data
        ├── mydb.sqlite
        ├── uploads
        └── output

Folder Purpose

Folder	Purpose
releases	Immutable deployments
current	Active running version(symlink)
shared	Persistent data
.env	Environment variables
data	Database & uploads

PM2 always runs the application from current.

Why Symlink Switching Is Atomic in Linux

This is the magic.

When you run:
ln -sfn releases/NEW_VERSION current

Linux replaces the symlink atomically.
That means:

There is no intermediate broken state
The pointer changes instantly
The filesystem guarantees consistency

From the OS perspective, the switch happens in one operation.
That's how zero-downtime switching works.

Deployment Flow

The deployment process looks like this:

Local Machine
    ↓
Build project
    ↓
Create release folder
    ↓
Upload via rsync
    ↓
Link shared files
    ↓
Switch "current" symlink
    ↓
Restart PM2

I use pm2 reload to avoid downtime. The new version becomes live immediately. The previous version still exists inside releases/.

This allows a new version to go live instantly.

What Happens If Deployment Fails Mid-Upload?

Nothing breaks.

Why?
Because:

Upload happens inside a new release folder
current is not touched during upload
The live app keeps running

If upload fails:

Delete the incomplete release
Redeploy

Your live application is never affected.

Rollbacks in Seconds

If something goes wrong after switching:

ln -sfn /root/convertx/releases/OLD_VERSION /root/convertx/current
pm2 restart convertx

Rollback time: under 5 seconds.

No rebuilding.
No reinstalling.
No panic.

Just switch the symlink.

Tech Stack Used

For this deployment workflow I use:

Bun runtime
PM2
Nginx reverse proxy
SQLite
rsync for fast deployments

This stack is simple, cheap, and extremely reliable.

Security Practices

Some important security rules I follow:

.env is never uploaded
node_modules is never uploaded
data/ stays persistent
SSH keys only (no password login)
HTTPS handled via Nginx

This keeps secrets and data safe during deployments.

Automatic File Cleanup

ConvertX processes uploaded files, so temporary files must be removed periodically.

I implemented two cleanup systems:

Internal scheduler in the application
System cron fallback

This ensures storage never grows uncontrollably.

Why Not Docker?

Docker is great.

For small single-service VPS deployments, Docker may not provide enough benefit to justify its operational overhead.

Adds complexity
Requires image builds
Adds extra layer of debugging
Consumes more memory

For simple backend services, native runtime + PM2 is often enough.

Why Not CI/CD Pipelines?

CI/CD is powerful.

But for solo builders:

Adds setup time
Adds moving parts
Can obscure what actually happens on the server

Manual release-based deployment is:

Transparent
Predictable
Easy to debug

You can always add CI later.

Why Not Git-Based Deployment?

Some deploy with:

git pull origin main

This has problems:

No version isolation
Harder rollback
Risk of merge conflicts on server
Repository becomes mutable production state

Production should not be your working directory. Releases solve this cleanly.

Why This Deployment Strategy Works

Benefits of this approach:

Zero-downtime deployment
Safe rollbacks
Clean release history
Persistent storage
Easy debugging
Production-grade workflow

And it works on any VPS.

Final Thoughts

A lot of developers over-complicate deployments with heavy infrastructure.

But with rsync + symlinks + PM2, you can build a very reliable deployment pipeline on a simple VPS.

Sometimes the best solutions are the simplest ones.

Bonus

This is exact guide, I use for deployment for convertx.

## Server Directory Structure

/`/`/`

/root/convertx
├── current → releases/20260117_2120
├── releases
│   ├── 20260104_2031
│   └── 20260117_2120
└── shared
├── .env
└── data
├── mydb.sqlite
├── uploads
└── output

/`/`/`

### Rules
- `shared/` → persistent files
- `releases/` → immutable deployments
- `current` → active version (symlink)
- PM2 always runs from `current`

---

# FIRST TIME DEPLOYMENT

---

## 1.Build Locally

/`/`/`bash
bun install
bun run build
/`/`/`

(If build is not required, skip.)

---

## 2.Create New Release (Local)

/`/`/`bash
cd ~/deployment/convertX/releases

TS=$(date +%Y%m%d_%H%M)
mkdir $TS
/`/`/`

Copy project files:

/`/`/` bash
rsync -av \
  --exclude node_modules \
  --exclude data \
  --exclude .git \
  ~/opensource/ConvertX/ \
  ~/deployment/convertX/releases/$TS/
/`/`/`

---

## 3.Upload Release to Server

/`/`/`bash
rsync -avz \
  --exclude node_modules \
  --exclude data \
  --exclude .git \
  ~/deployment/convertX/releases/$TS/ \
  root@SERVER_IP:/root/convertx/releases/$TS/
/`/`/`

---

## 4.Link Shared Files (Server)

/`/`/`bash
ssh root@SERVER_IP
/`/`/`

/`/`/`bash
cd /root/convertx/releases/$TS

ln -s ../../shared/.env .env
ln -s ../../shared/data data
/`/`/`

---

## 5.Activate Release

/`/`/`bash
ln -sfn /root/convertx/releases/$TS /root/convertx/current
/`/`/`

---

## 6.Install Dependencies

/`/`/`bash
cd /root/convertx/current
bun install
/`/`/`

---

## 7.Restart Application

/`/`/`bash
pm2 restart convertx
/`/`/`

---

## 8.Verify Deployment

/`/`/`bash
pm2 status
/`/`/`

/`/`/`bash
curl -H "Authorization: Bearer API_TOKEN" \
https://api.com/api/health
/`/`/`

---

# DEPLOYING A NEW RELEASE

Repeat the same flow.

---

## Local

/`/`/`bash
TS=$(date +%Y%m%d_%H%M)

mkdir ~/deployment/convertX/releases/$TS

rsync -av \
  --exclude node_modules \
  --exclude data \
  --exclude .git \
  ~/opensource/ConvertX/ \
  ~/deployment/convertX/releases/$TS/
/`/`/`

---

## Upload

/`/`/`bash
rsync -avz \
  --exclude node_modules \
  --exclude data \
  --exclude .git \
  ~/deployment/convertX/releases/$TS/ \
  root@SERVER_IP:/root/convertx/releases/$TS/
/`/`/`

---

## Server

/`/`/`bash
cd /root/convertx/releases/$TS

ln -s ../../shared/.env .env
ln -s ../../shared/data data

ln -sfn /root/convertx/releases/$TS /root/convertx/current

cd /root/convertx/current
bun install
pm2 restart convertx
/`/`/`

---

# ROLLBACK

If deployment fails:

/`/`/`bash
ln -sfn /root/convertx/releases/OLD_TIMESTAMP /root/convertx/current
pm2 restart convertx
/`/`/`

Rollback time: **< 5 seconds**

---

# CLEAN OLD RELEASES

Keep last 3–5 releases.

/`/`/`bash
cd /root/convertx/releases
ls
rm -rf OLD_TIMESTAMP
/`/`/`

Never delete `current`.

---

# SECURITY NOTES

* Never upload `.env`
* Never upload `data/`
* Never upload `node_modules`

---

# PM2 COMMANDS

/`/`/` bash
pm2 status
pm2 logs convertx
pm2 restart convertx
pm2 save
pm2 startup
/`/`/`

---

**ConvertX deployment is live. 🚀**

How We Built Secure Cross-App SSO for Multi-Tenant Financial Application : Architecture, Risks, and Lessons

Vishw Patel — Thu, 12 Feb 2026 12:46:56 +0000

Introduction

For the past two years, I've been working on a large-scale multi-tenant financial platform serving 250+ financial institutions across the U.S. The system supports millions of end users, with around 50-60k monthly active users interacting across different portals.

Recently, we implemented a secure cross-application SSO flow between our admin operations portal and a dedicated reporting dashboard. What initially looked like a simple "View Dashboard" button turned into a deeper architectural challenge involving tenant isolation, token exchange, and strict access boundaries — where errors are costly, user trust is critical, and sensitive financial data is always at stake.

Before diving into SSO, it's important to understand how the platform itself is structured.

High-Level Architecture: Three Portals, Three Responsibilities

Our system isn't a single monolithic app. It consists of three independent portals:

Customer Portal - used by end users interacting with financial products.
Admin & Operations Portal - used internally to manage multiple tenants (financial institutions).
Reporting Dashboard - focused on KPIs, analytics, and performance reporting.

Each portal has its own purpose, deployment lifecycle, and trust boundary. Separation allowed our team (compact 7-engineer group owning everything from architecture and design to development, testing, and deployment) to scale independently and reduced the risk of exposing sensitive reporting functionality directly inside operational workflows.

From a technology standpoint, we used React for the frontend and .NET for the backend.

From an identity perspective, this also meant authentication couldn't be tightly coupled to one application - especially in a multi-tenant setup.

Three Types of Users

Our architecture revolves around three main user roles:

Customers - interact only with the customer portal.
Financial Institution (FI) Employees - log directly into the reporting dashboard using username/password.
Admins - operate from the admin portal and also require access into reporting for operation purposes.

The reporting dashboard was originally designed only for FI employees and single-tenant access patterns. Later, due to operational requirements, we needed to extend it to support both Admins and FI employees.

Fig.1 - Overview of portals and user roles showing access boundaries.

New Requirement

Admins have a simple "Reporting" button. On clicking it, they should be redirected to the Reporting Portal in a new tab without logging in again.

Admins already have higher privileges and multi-tenant roles, which complicates seamless access while maintaining strict isolation between tenants.

The Core Problem introduced with requirement

At first, this sounded like a simple redirect problem. In reality, it introduced deeper architectural questions around identity boundaries and tenant safety.

Admins operate the Admin & Operations Portal and can manage multiple financial institutions (FIs). When performing actions, they select a tenant and operate under that FI context.

With the new requirement:

Admins expect instant access to the tenant's reporting environment.
Tenant isolation must be preserved: the Reporting Portal should only allow access to the currently selected FI.
We currently use JWT tokens in both portals to store access and role information.

Challenges:

Maintain strict tenant isolation - an admin should not access data from another FI just because they have global privileges.
Avoid sharing sessions directly between apps - no session cookies or tokens should be blindly reused.
Prevent long-lived tokens from leaking across domains, which could compromise data security.

Problem with reusing Admin JWT:

Using the Admin JWT in the Reporting Portal would blur tenant boundaries. It risks cross-tenant data leaks, defeating the purpose of isolated reporting per FI.

SSO Solution: How We Enabled Secure Cross-App Access

Once we clearly understood the risks around tenant isolation and cross-application authentication, the goal became simple to define but harder to execute: enable admins to move from the operations portal to the reporting dashboard seamlessly - without sharing sessions directly or weakening security boundaries. It was about connecting two independent applications without breaking tenant isolation or expanding trust boundaries.

Overall Approach

Instead of sharing sessions or forwarding existing admin tokens, we implemented a token exchange based SSO flow. The admin portal initiates the process, but the reporting application ultimately issues and owns its own authentication token. This allowed each portal to remain autonomous while still providing a unified experience to the user.

The core principle behind the design was simple:

Never transfer long-lived identity between applications - exchange it for a new, purpose-built token.

Admin Portal Login Flow (Before SSO)

Before diving into the SSO flow, let's first understand how the Admin Portal login works in our system.

Step 1: Admin Authentication

Admins log in using a username and password. Behind the scenes, our custom Identity Server handles authentication. When credentials are submitted:

The Identity Server validates the admin.
If authentication succeeds, it issues a JWT.

This initial token contains:

Admin metadata
A list of accessible banks
High-level permissions and claims

At this point, the token is not scoped to a specific bank.

Step 2: Bank Selection

After login, the admin is presented with a list of banks they are authorized to manage.

When the admin selects a bank:

The frontend sends a request to the Identity Server with the selected bankGuid.

The Identity Server verifies whether the admin has permission to access that specific bank.

If authorized, a new JWT is generated - this time scoped to the selected bank. The new token includes bank-level permissions and context. The token is returned to the admin.

The frontend then replaces the initial token with this bank-scoped token and uses it for all subsequent API requests.

Why We Use bankGuid Instead of Primary Keys

We never expose actual database primary keys to the UI.

Instead, we use temporary, globally unique identifiers (bankGuid) that map internally to bankId.

Key characteristics of this mapping:

Automatically generated
Globally unique
Refreshed approximately every 30 minutes
New GUIDs are reassigned after refresh

This provides:

An abstraction layer between UI and database
Protection against direct ID enumeration
Reduced risk of exposing internal data structures

Token Expiry and Seamless Refresh

Bank-scoped JWTs expire after ~20 minutes. To maintain uninterrupted access:

The frontend uses a refresh token to request a new access token when the current one expires.
If the bank’s bankGuid has rotated in the meantime, the new token contains the current valid GUID.
Any request made with an old token automatically triggers this refresh flow. The new token replaces the old one transparently.

This ensures:

No broken sessions
No manual re-login required
Continuous, secure access under the correct bank context

The bankGuid rotation is designed to minimize exposure of stable internal IDs, and does not invalidate active sessions. During token refresh, the current valid bankGuid is always issued to ensure seamless continuity.

Since each JWT is scoped to a single bank:

The admin operates strictly within one bank context at a time. Opening multiple tabs does not allow simultaneous operation across different banks under the same session. In financial systems, "context confusion" is a real risk. An admin believing they are working in Bank A while modifying Bank B is not a theoretical problem - it’s an operational nightmare.

By enforcing bank-scoped tokens, we eliminate context confusion and significantly reduce the risk of unintended changes across financial institutions.

Fig.2 - Admin Authentication Flow.

With bank-scoped tokens firmly established in the Admin Portal, the next challenge was securely extending this tenant context to the Reporting Dashboard without compromising isolation or security boundaries.

The Token Exchange Flow: Step-by-Step

Once the admin is authenticated and the bank-scoped JWT is issued, the next task is to securely extend the admin's session to the Reporting Portal while maintaining tenant isolation. Instead of transferring the long-lived bank-scoped JWT between applications, we implemented a token exchange flow to ensure security boundaries are respected.

Here's a detailed breakdown of how it works:

Step 1: Admin Requests Access to Reporting

The admin clicks the "Reporting" button on the dashboard.
The admin frontend sends a Single Sign-On (SSO) token request to the admin backend, including the bank context extracted from the JWT stored in local storage.
The admin backend forwards the token to the identity server.
The identity server validates the token and checks the admin’s permissions for accessing the reporting system.
If valid, the identity server creates a short-lived, encrypted token (2-minute expiry) containing the admin info and bank context, then returns it to the admin backend.
The admin backend forwards this short-lived SSO token to the admin frontend.

Step 2: Redirect to Reporting Dashboard

The admin frontend opens the Reporting Dashboard in a new browser tab, sending the short-lived SSO token along with the request.
The request reaches the reporting frontend, which passes it to the reporting backend.
The reporting backend sends the SSO token to the identity server for verification.
Upon validation, the identity server issues a new JWT containing the admin’s reporting permissions and bank context.
The reporting frontend uses this new JWT for all subsequent requests, ensuring secure access without ever exposing the long-lived bank-scoped JWT.

Fig.3 - Token Exchange Flow.

Why This Approach Works

Tenant Isolation: The admin's bank context is always scoped to the reporting system.
Short-lived Tokens: Minimize exposure of sensitive credentials during redirects.
Centralized Validation: The identity server enforces permissions at every stage, ensuring only authorized access.

Edge Case: Context Confusion Across Multiple Tabs

You might think the token exchange flow is bulletproof and technically, it is. Strict tenant isolation, short-lived tokens, and carefully scoped permissions make cross-bank data leaks practically impossible. But here's the twist: sometimes, it’s the human — not the code — who becomes the weak link.

Picture this:

An admin logs into the Admin Portal and selects Bank A.
He/She click the Reporting button, opening Bank A's Reporting Dashboard in a new tab - all good.
Then, the admin goes back to the Admin Portal, navigates to the home page, and switches to Bank B.
He/She click Reporting again, opening Bank B's Reporting Dashboard in a second tab.

At this point:

The first tab still shows Bank A's dashboard.
The second tab shows Bank B's dashboard.

The system is doing exactly what it should: both dashboards enforce correct bank-level access, and the backend has kept each tenant neatly separated.

However, the user could get confused, thinking that both tabs are linked to the same bank context or confuse between banks. This may lead to operational mistakes, like performing actions in Bank B while thinking they are in Bank A.

Even with strict backend isolation, UX design must reinforce tenant boundaries to prevent "context confusion" that could lead to mistakes.

Mitigation: Real-Time Tab Coordination

Even with single-session rules, admins may already have a reporting tab open when they try to open another. To handle this smoothly and prevent confusion, we implemented cross-tab messaging:Broadcasting Events Between Tabs

We use the browser's Broadcast Channel API to send messages to all open tabs of the same application.

When a new reporting session starts, the reporting frontend broadcasts a "reporting session started" message to all other tabs.
Upon receiving the broadcast, any previous reporting tab automatically logs out the active reporting session.

This ensures only one reporting session per browser at any time.

Tradeoffs

Implementing a secure, token-exchange SSO with strict tenant isolation isn't free - it comes with tradeoffs that are worth acknowledging.

Performance :

Each SSO flow involves extra redirects and token validation steps.
We accepted this tradeoff because correctness, security, and tenant isolation outweigh shaving milliseconds.

Over-Trusting Tokens

Tokens must never be blindly trusted across applications or sessions.
Sharing tokens between portals would break tenant boundaries and risk sensitive data exposure.
The token-exchange flow mitigates this, but it requires careful validation, short lifetimes, and consistent backend enforcement.

User Experience vs Security

Enforcing one reporting session per device prevents context confusion but may frustrate admins who are used to opening multiple tabs, but it's a UX compromise to maintain security.

Implementation Complexity

Adding token exchange, session invalidation, and cross-tab messaging adds more moving parts.
Each component must be carefully tested to avoid race conditions, token mismatches, or failed SSO flows.
For a small team, this increases maintenance overhead, but it's necessary for enterprise-grade multi-tenant security.

Lesson Learned :

Even with rock-solid backend isolation, UX design acts as the guardian.

From this experience, we realized:

Technical safeguards aren't enough: No matter how airtight your token exchange or permission model is, users can still get confused.
Cross-tab coordination is essential: Real-time messaging between tabs prevents "ghost sessions" and reduces operational mistakes.

Conclusion

Designing secure cross-application SSO in a multi-tenant financial system pushed us to think far beyond simple redirects and token handling. It required clear trust boundaries, purpose-built token exchange instead of shared identity, strict tenant scoping, controlled session invalidation, and thoughtful UX decisions to prevent context confusion. In environments where sensitive financial data is involved, even small architectural shortcuts can lead to serious consequences, so every layer (identity server, token lifecycle, tenant mapping, and frontend behavior) must work together intentionally. SSO is not just about seamless access; it is about enforcing boundaries while preserving usability. When built correctly, it becomes a disciplined bridge between independent systems rather than a shortcut around authentication.

Keep learning, keep growing.

Don't call your self react developer until you don't know this

Vishw Patel — Tue, 29 Apr 2025 09:22:10 +0000

How React Works Under the Hood

React may seem magical, but behind the scenes, it's a highly optimized and elegant system.

In this comprehensive deep dive, we’ll explore:

What React DOM really does
How JSX is parsed into JavaScript objects
Why every component is just a function or object
The diffing and reconciliation process
How Hooks like useState and useEffect really work
Optimization strategies React uses
React Fiber: the heart of the React rendering engine
How to build your own mini React

Let’s decode the internals

1. React DOM: The Rendering Engine

React is a powerful JavaScript library for building user interfaces, but it doesn't interact directly with the browser's Document Object Model (DOM). That crucial responsibility is handled by ReactDOM, which serves as the rendering engine that connects React's declarative component model to the actual browser environment. When developers write a command like ReactDOM.render(<App />, document.getElementById('root'));, they're instructing ReactDOM to take the virtual component tree and mount it into the specified location in the real DOM. Behind the scenes, ReactDOM creates a virtual representation of the UI elements, compares them during updates using a diffing algorithm, and applies only the minimal set of changes needed to the real DOM — improving performance and responsiveness.

ReactDOM's strength lies in its ability to efficiently manage host environment logic, meaning it knows how to interact with browser-specific APIs like document.createElement, appendChild, or removeChild. This separation of concerns allows React itself to remain platform-agnostic — enabling other renderers like React Native or React 360 — while ReactDOM is specifically tailored for web browsers. By handling DOM interactions, event delegation, and mounting lifecycle logic, ReactDOM plays a critical role in making React applications feel fast, interactive, and modern.

2. How JSX Works Internally

JSX may look like regular HTML, but it's actually a JavaScript syntax extension that simplifies how we write React components. Instead of manually calling JavaScript functions to create DOM elements, JSX allows us to write components in a familiar, HTML-like structure. But here's the catch: JSX doesn’t directly work in the browser. It’s converted into JavaScript before the browser can run it. JSX is essentially syntactic sugar, meaning it makes writing code easier, but it still gets converted into something else under the hood.

Let’s break it down with a simple example:


<div>Hello, world!</div>

At first glance, this looks like regular HTML. But when JSX is compiled by tools like Babel, it gets turned into a JavaScript function call like this:

React.createElement('div', null, 'Hello, world!');

This may seem confusing at first, but what’s happening here is that React.createElement is a function that React uses to create a virtual representation of the UI you’re building. In this case, it’s creating an object that describes the

element, its attributes (none in this case), and its content (the text 'Hello, world!').

Why Do We Use JSX?

JSX makes React development more intuitive and less verbose. Imagine creating a list of items in pure JavaScript without JSX:

const list = React.createElement('ul', null, 
  React.createElement('li', null, 'Item 1'),
  React.createElement('li', null, 'Item 2'),
  React.createElement('li', null, 'Item 3')
);

This looks cumbersome compared to the JSX version:

<ul>
  <li>Item 1</li>
  <li>Item 2</li>
  <li>Item 3</li>
</ul>

As you can see, JSX provides a cleaner, more readable way to write React components. And under the hood, it’s just a simpler, more intuitive way to call React.createElement.

3. Components Are Objects or Functions

In React, components are the building blocks of your application. A component is a reusable piece of code that defines part of the UI. You can think of a component as a function or a class, both of which return a description of what the UI should look like. This description is what React will use to create the actual user interface in the browser. So, when you create components, you’re basically writing a function or class that returns what the UI should look like at that moment.

Function Components
Let’s start with function components, which are simpler and more common in modern React development .A function component is just a function that returns JSX. Here’s an example:

function MyButton() {
  return <button>Click me</button>;
}

In this example, MyButton is a function that returns a JSX element a <button> element with the text Click me. This function component looks simple, but when it’s rendered, React does a lot behind the scenes. It takes this JSX, converts it into a virtual DOM node, and eventually updates the real DOM on the page.

Now, when you call the MyButton component in JSX like this:<MyButton>

React doesn’t directly render it to the page. Instead, it takes the JSX and creates a JavaScript object that represents the component. This object looks like this:

{
  type: MyButton,
  props: {}
}

This object has two important properties:

type: This refers to the component itself (MyButton).
props: This refers to the properties (or "props") passed to the component. In this case, there are no props passed, so it's an empty object.

How React Uses Components

React uses both function and class components in a similar way. Whether you define your component as a function or a class, React calls the component to get the description of the UI (the JSX), then builds a tree of virtual DOM nodes. This process is recursive — meaning if you have a component that contains other components, React will also create virtual DOM nodes for those components.

For example, let’s say you have a parent component and a child component:


function Parent() {
  return <MyButton />;
}

Here, React will first create the virtual DOM node for the Parent component. Then, it will call the MyButton component inside the Parent component and create the virtual DOM node for it too. It does this recursively, meaning if components are nested, React will go through each one to build the complete tree of virtual DOM nodes.

4. Reconciliation and Virtual DOM

One of the main reasons React is known for its performance is its reconciliation algorithm and the use of the Virtual DOM. But what does this mean, and how does it help make React fast and efficient? Let's break it down step by step.

What is the Virtual DOM?

To understand how React updates the real DOM efficiently, we first need to understand the Virtual DOM. The Virtual DOM is a lightweight, in-memory representation of the real DOM. It’s essentially a copy of the UI, but it’s not the actual elements on the page. React uses this virtual representation to figure out what changes need to be made to the real DOM, without directly manipulating it right away. This saves a lot of time and resources because interacting with the real DOM can be slow, especially when there are many elements.

When State Changes
Now, let’s say something changes in your app, such as when a user clicks a button or enters text in an input field. This is a state change, and when state changes, React follows these steps:

Rebuild the Virtual DOM: React re-renders the component and rebuilds the entire Virtual DOM tree. This means React creates a new in-memory copy of the UI based on the updated state.
Compare the Virtual DOMs: React then compares the newly created Virtual DOM tree to the previous one. This comparison helps React figure out what has changed between the two.
Apply Necessary Updates: After React has identified the differences, it applies only the necessary updates to the real DOM. React doesn’t update the entire real DOM — just the parts that have changed. This process is called reconciliation.

How Reconciliation Works
React's reconciliation process follows specific rules to make updates efficient. Let’s go through them one by one:

Elements of Different Types: If the type of the element has changed (for example, if a is replaced by a
), React will completely replace the existing DOM node with a new one. This ensures that React doesn’t try to keep any unnecessary information when the structure changes.
For example, if you change a <div> to a <button>:
```
<div>Click me</div> // Previous
<button>Click me</button> // Updated
```
React will replace the entire <div> node with a new <button> node.
1. Same Type: If the element type is the same (for example, a <div> to another <div>), React will update the existing element’s props and children. React only updates the things that need to be updated. This makes updates much faster than creating a whole new element.
For instance, if you change the text inside a <div>:
```
<div>Hello</div> // Previous
<div>Goodbye</div> // Updated
```
React will just update the text inside the same <div> element, rather than creating a whole new element.
1. Children Need Keys for List Diffing: When working with lists of elements (like in a list or a table), React needs a way to keep track of each item in the list when the list changes. For this, React uses keys. A key is a unique identifier that helps React match the old items in the list with the new ones.
For example, consider this list of items:
```
<ul>
  <li>Item 1</li>
  <li>Item 2</li>
</ul>

If you change the order or remove items from the list, React needs a way to keep track of which item is which. Without keys, React might get confused about which item should be updated and might not perform updates correctly. That’s why you should always provide a unique key for each item in a list:
```
- Item 1
- Item 2
```
By providing keys, React can efficiently update the list when changes occur, reducing unnecessary re-renders and keeping the UI in sync with the data.
```
5. Hooks Internals

React Hooks like useState, useEffect, and others may seem like magic at first, but under the hood, their logic is surprisingly elegant. Understanding how they work internally not only gives you more confidence while coding, but also helps avoid common mistakes like using hooks conditionally or inside loops.

Let’s break it down step by step.

The Concept: Hooks as State Slots

When you use hooks like useState, React manages state without classes. Instead, it internally keeps track of an array of state values (or “slots”) for each functional component. Each time your component renders, React walks through that array, calling your hooks in the exact same order.

Here’s a simplified version of how useState might work behind the scenes:
```
let hookIndex = 0;
const hooks = [];

function useState(initial) {
  const currentHook = hooks[hookIndex] ?? initial;

  const setState = (newValue) => {
    hooks[hookIndex] = newValue;
    rerender(); // Re-render the component when state changes
  };

  hookIndex++;
  return [currentHook, setState];
}
```
This example assumes a global hookIndex and hooks array. Every time the component renders, hookIndex resets to 0, and React walks through the hooks in the same order they were declared. When you call useState(), it looks at the hooks[0] slot on the first call, then hooks[1] on the second call, and so on.

Why Hooks Must Be Called in the Same Order
Because React relies on the order of hook calls to match values with the correct state slot, you must never call hooks conditionally or inside loops. Otherwise, the order will be inconsistent between renders, and React won’t know which slot corresponds to which hook, causing bugs or errors.

Incorrect (don’t do this):
```
function MyComponent(props) {
  if (props.show) {
    const [count, setCount] = useState(0); // ❌ Hook inside a condition
  }
}
```
Correct:
```
function MyComponent(props) {
  const [count, setCount] = useState(0); // ✅ Always called
  // You can conditionally use the value later
}
```
React needs this consistent ordering to work properly — think of it like stepping through a list of saved values. If the order changes, React ends up reading or writing to the wrong index.

Internal Flow of Hooks in a Component
Imagine a component like this:
```
function Counter() {
  const [count, setCount] = useState(0);
  const [name, setName] = useState('Guest');

  return (
    <div>
      <p>{name}: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
}
```
Internally, React builds a hook state array something like:
```
hooks = [0, 'Guest']; // index 0 = count, index 1 = name
```
When you click the button, setCount updates index 0 and triggers a re-render. During the re-render, React reads from the hooks array in the same order to re-apply the useState calls.

6. React Fiber: The Core Architecture

What is Fiber?

React Fiber is the engine that powers React behind the scenes. Introduced in React 16, Fiber was a complete rewrite of React's internal rendering logic to improve performance, responsiveness, and flexibility.

Before Fiber, React used a synchronous, blocking update model — which meant large updates could freeze the UI. Fiber changed all that by making rendering incremental and interruptible.

Think of Fiber like a highly efficient project manager. Instead of doing all tasks at once (which might delay user interactions), it breaks them into smaller chunks and pauses/reorders them based on priority.

How Does Fiber Work?

Fiber breaks down rendering work into units, and schedules them based on priority. This makes React feel faster and more responsive — especially on slow devices or large apps.

Here’s how Fiber improves the update process:

Incremental rendering: React doesn’t process the whole component tree in one go. It can pause work and resume it later.

Interruptible rendering: If a more urgent update (like a user typing) comes in, React can pause current work and handle the urgent update first.

Smart scheduling: React uses a scheduler that decides what updates to do now, and what can wait (e.g., transitions or animations).

The Fiber Node

Each React element or component becomes a Fiber node — a JavaScript object with links to related nodes and properties. Imagine it like a tree where each node is a task with connections to siblings, parents, and children.

Here’s what a simplified Fiber node looks like:
```
{
  type: MyComponent,        // Function or DOM type
  child: [childNode],       // First child in the tree
  sibling: [nextSibling],   // Next sibling on the same level
  return: [parentNode],     // Parent fiber
  props: { ... },           // Props passed to the component
  stateNode: DOM or class   // Reference to DOM node or class instance
  alternate: [oldFiber]     // Used for diffing with previous version
}
This forms a linked list/tree structure, allowing React to efficiently walk through and update parts of the UI.
```
Scheduling and Priorities

React assigns each update a priority level, called a lane. For example:
- urgent: typing input, clicks
- default: UI updates
- transition: animations or routes
- idle: low-priority background tasks
React uses a loop (like requestIdleCallback) to decide which updates to work on, and can yield (pause) between chunks so it doesn’t block the browser.

Think of it like juggling — React keeps many tasks in the air, but it knows which ones to catch first based on importance.

The Commit Phase

Once React finishes building the updated Fiber tree (this is called the render phase), it enters the commit phase, where:
1. DOM updates are applied (in a batch).
2. Effects like useLayoutEffect and useEffect are executed.
By separating the render and commit phases, React ensures smooth visual updates and allows powerful features like concurrent rendering, Suspense, and transitions.

React Fiber is the heart of modern React, enabling:
- Smooth, responsive interfaces
- The ability to pause and resume rendering
- Smarter prioritization of UI tasks
This internal architecture makes it possible to build complex apps without worrying about performance — React takes care of the heavy lifting behind the scenes.

Conclusion

Diving into React's internals isn’t just for advanced developers — it’s a powerful way to level up your day-to-day React skills. When you understand how React works under the hood — from JSX and component trees to the Fiber architecture and hooks — everything starts to make more sense.

You begin to write cleaner code, avoid common pitfalls, and debug with confidence because you know why React behaves the way it does. You realize that things like stable hook order, using keys in lists, or why rendering is fast and batched aren’t just “rules” — they’re design decisions based on a deeply thought-out engine.

React is not just a library — it’s a state machine, a scheduler, and a rendering engine all working in sync to deliver fluid user experiences. And the best part? It gives you a simple, declarative API to work with, so you can focus on your product while it handles the complexity.

So, the next time something in your app feels "off," or you want to improve performance, remember: React’s inner workings are not a black box.

Keep Learning , Keep Growing

Building Dynamic Pagination in React: Server-Side Fetching with Client Components

Vishw Patel — Mon, 28 Apr 2025 07:39:54 +0000

Building Dynamic Pagination in React: Server-Side Fetching with Client Components

Pagination is a core feature for any application dealing with a large amount of data: product listings, blog posts, user lists, etc.

Today, we'll explore how to implement dynamic pagination that fetches data from the server page-by-page, while keeping the UI fast and smooth with React Client Components.

Why Use Dynamic Pagination?

Dynamic pagination means:

Fetching only a subset of data (e.g., 10 items at a time) from the server.
Avoiding loading all data at once (which slows down apps).
Improving load times, SEO, and UX.
Reducing server load and bandwidth consumption.

Perfect for ecommerce stores, blogs, dashboards, admin panels, etc.

How Pagination Works (At a High Level)

User visits the page.
Frontend sends a request to the server with a page number.
Server sends back only the relevant items.
Frontend renders them dynamically.
User can navigate between pages, triggering new fetches.

Setting Up the Backend (Fake API Example)

Your backend route might look like this:

GET /api/items?page=2&limit=10

Returns:

{
  "items": [/* 10 items here */],
  "total": 100
}

You need items and total count to calculate how many pages there are.

Frontend: React Pagination Example

Let's build a dynamic pagination system using React client components.

1. Create a Pagination Service

// services/itemService.ts

import axios from 'axios';

export async function fetchItems(page: number, limit: number = 10) {
  const response = await axios.get(`/api/items?page=${page}&limit=${limit}`);
  return response.data;
}

2. Create a PaginatedList Component

// components/PaginatedList.tsx

'use client';

import { useState, useEffect } from 'react';
import { fetchItems } from '@/services/itemService';

export default function PaginatedList() {
  const [items, setItems] = useState([]);
  const [total, setTotal] = useState(0);
  const [page, setPage] = useState(1);
  const limit = 10;

  useEffect(() => {
    async function loadItems() {
      const data = await fetchItems(page, limit);
      setItems(data.items);
      setTotal(data.total);
    }

    loadItems();
  }, [page]);

  const totalPages = Math.ceil(total / limit);

  return (
    <div className="p-4">
      <h2 className="text-xl font-bold mb-4">Items</h2>

      <ul className="space-y-2">
        {items.map((item: any) => (
          <li key={item.id} className="border p-2 rounded">{item.name}</li>
        ))}
      </ul>

      <div className="flex gap-2 mt-4">
        <button onClick={() => setPage(p => Math.max(p - 1, 1))} disabled={page === 1} className="px-4 py-2 bg-gray-300 rounded">Previous</button>

        <span className="px-4 py-2">Page {page} of {totalPages}</span>

        <button onClick={() => setPage(p => Math.min(p + 1, totalPages))} disabled={page === totalPages} className="px-4 py-2 bg-gray-300 rounded">Next</button>
      </div>
    </div>
  );
}

Key Features of This Setup

Server-Side Fetching:
- Each page fetches only needed items.
- Saves bandwidth and improves speed.
Client Components:
- Handles navigation and user interaction instantly.
- Fetches new data only when needed (on page change).
Graceful State Handling:
- Disable buttons when you reach first or last page.
- Smooth user experience without page reloads.

Server-Side vs Client-Side Pagination: When to Use

Conclusion

Dynamic pagination is an essential building block for scalable, fast, and user-friendly React applications.

By fetching data page-by-page from the server and rendering them smoothly using client-side components, you keep your app lightweight and your users happy.

Start simple — but always keep in mind:

Proper state management
Loading states and error handling
Optimizing API efficiency

Pagination isn't just about navigation — it's about performance. 🚀

Build it right, and your app will scale effortlessly, even when you have millions of records!

Understanding React Server Components (RSC)

Vishw Patel — Fri, 25 Apr 2025 07:58:09 +0000

Understanding React Server Components (RSC): The Future of React Rendering

React Server Components (RSC) mark a fundamental shift in how we build performant React applications. Introduced by the React team, RSC aims to combine the developer-friendly JSX syntax with server-first rendering principles to reduce bundle size, enhance performance, and improve scalability.

What Are React Server Components?

React Server Components are components that are rendered entirely on the server, and their output is streamed to the client without including any of their code in the final JS bundle.

Key Concepts:

Zero JavaScript shipped to the client for server components
Can be mixed with traditional client components
Enable fetching data server-side without useEffect or SWR
Seamlessly integrated in frameworks like Next.js App Router

Client vs Server Components: What’s the Difference?

Feature	Client Component	Server Component
Runs on	Browser	Server
JavaScript bundle	Included	Not included
Can use hooks	Yes	Only use for promises
Access to DOM/events	Yes	No
Data fetching	With effects/libraries	Native (await syntax)

Example:

// Server Component
export default async function ProductPage() {
  const data = await fetchProducts();
  return <ProductList products={data} />;
}

Using RSC in Next.js 14

Next.js 13+ App Router supports RSC out of the box. Files in the app/ directory are server components by default.

Folder Structure:

/app
  /products
    page.tsx    // Server Component
    Product.tsx // Client Component

To make a component run on the client:

'use client';
export default function Product({ product }) {
  return <button>Add {product.name}</button>;
}

Benefits of Server Components

Minimal JS Bundle Size

Server components don’t get bundled for the client, which means:

Faster load time
Reduced memory footprint
Better Lighthouse scores

Server-Side Data Fetching

No need for SWR or useEffect for data fetching — you can await directly in the component.

Improved Developer Experience

Clearer separation of client/server logic
Closer to traditional backend-rendered paradigms

How Server Components Work Internally

Server renders the component tree
Renders are serialized into a special format
React client runtime hydrates the shell and replaces server output as needed
Maintains full interactivity via islands of client components

Streaming:

Server Components support streaming rendering — which means parts of the UI can be shown as they are ready.

<Suspense fallback={<Loading />}>
  <ProductList />
</Suspense>

When to Use Server Components

Use Server Components when:

You don’t need interactivity (e.g., static content, product listings)
You need fast, secure server-side data fetching
You want to reduce frontend bundle size

Avoid them for:

Interactive UI (forms, dropdowns)
Components that use DOM APIs or event handlers

Composing Server and Client Components

You can freely mix server and client components:

<ProductList>
  <ProductCard>
    <AddToCart /> // Client-only
  </ProductCard>
</ProductList>

This makes RSC flexible for real-world apps where interactivity is needed only in some areas.

Security & Limitations

Cannot access browser-only APIs
Do not support state, effects, or DOM manipulation
Need careful boundary planning (client/server distinction)

The Future of React with RSC

React Server Components are setting the stage for the next era of web development:

Hybrid rendering is the new standard
Combined with Edge functions, you can get fast, dynamic UIs with low latency
Expect broader framework support beyond Next.js soon

Conclusion

React Server Components are not a replacement for client components — they are a powerful complement. By moving the non-interactive logic to the server:

Your pages load faster
Bundle sizes shrink
Data fetching becomes native

If you’re working with Next.js, start using RSC today. It’s the direction React is heading.

Scalable React Component Patterns: From Atomic Design to Compound Components

Vishw Patel — Fri, 25 Apr 2025 07:49:14 +0000

Scalable React Component Patterns: From Atomic Design to Compound Components

As your React app grows, the way you organize and build components becomes critical. Instead of just “breaking things into components,” advanced design patterns help you:

Promote reusability
Reduce prop drilling
Create highly customizable UIs
Avoid tech debt

In this article, we’ll explore key React component patterns that help build modular, maintainable, and scalable frontends.

Atomic Design: Structuring Components by Granularity

Atomic Design (coined by Brad Frost) is a methodology that breaks the UI into five stages:

Atoms – Basic building blocks (e.g., Button, Input)
Molecules – Groups of atoms (e.g., Input + Label)
Organisms – Full sections (e.g., Header, Card)
Templates – Page-level layouts
Pages – Complete pages with data

Benefits:

Enforces consistency
Enables design system reuse
Scales well with teams and folders

Compound Components: Components That Work Together

Compound components are a pattern where multiple components share implicit state using React context.

<Tabs>
  <Tabs.List>
    <Tabs.Trigger value="1">Tab 1</Tabs.Trigger>
    <Tabs.Trigger value="2">Tab 2</Tabs.Trigger>
  </Tabs.List>
  <Tabs.Content value="1">Panel 1</Tabs.Content>
  <Tabs.Content value="2">Panel 2</Tabs.Content>
</Tabs>

Why it works:

Components are declarative and readable
State is managed internally in Tabs, shared through context

This is used by libraries like Radix UI and Headless UI.

Controlled vs Uncontrolled Components

Controlled:

<input value={value} onChange={e => setValue(e.target.value)} />

State is owned by the parent
Easier to control programmatically

Uncontrolled:

<input defaultValue="hello" ref={ref} />

DOM manages the state
Ideal for quick forms or integrating with non-React libs

Use controlled when you need validation, centralized state, or interactivity.

Render Props: Component Logic Sharing

Render props is a technique to share logic by passing a function as a child.

<MouseTracker>
  {({ x, y }) => <div>Mouse position: {x}, {y}</div>}
</MouseTracker>

Under the hood:

function MouseTracker({ children }) {
  const [pos, setPos] = useState({ x: 0, y: 0 });
  // track mouse...
  return children(pos);
}

Before hooks, this was one of the main ways to reuse logic. Still useful for fine-grained control.

Headless Components: Logic Without Markup

Headless components (like useCombobox() from Downshift) expose logic but let you define the UI.

const { isOpen, getItemProps, getMenuProps } = useCombobox({...});

Why it scales:

Keeps logic and markup separate
Highly composable
Works with any design system

Great for building framework-agnostic, accessible libraries.

Presentational + Container Components

This classic pattern separates logic from UI:

Container:

function UserContainer() {
  const user = useUser();
  return <UserProfile user={user} />;
}

Presentational:

function UserProfile({ user }) {
  return <div>{user.name}</div>;
}

This is great when using tools like Storybook, where presentational components can be tested in isolation.

Contextual Components and Portals

Use React’s context to avoid prop-drilling and manage shared state across compound UIs.

Portals let you render children outside the parent DOM node — ideal for modals, dropdowns, tooltips:

ReactDOM.createPortal(<Modal />, document.body);

Combined with context, this enables decoupled, accessible UI patterns.

Custom Hooks + Refs + Imperative Handles

Custom hooks let you extract and reuse logic cleanly.

function useToggle(initial = false) {
  const [on, setOn] = useState(initial);
  const toggle = () => setOn(o => !o);
  return { on, toggle };
}

useImperativeHandle lets you expose internal component methods to parent refs — useful for forms, sliders, and interactive components.

useImperativeHandle(ref, () => ({ focus: () => inputRef.current?.focus() }));

When and Where to Use Each Pattern

Pattern	Best For
Atomic Design	Design systems, scalable folder structure
Compound Components	Tabs, modals, dropdowns
Render Props	Custom logic with full control over rendering
Headless Components	Logic-heavy reusable components
Container/Presentational	Separation of concerns
Context + Portals	Shared state across UI layers

Final Thoughts

Mastering these patterns enables you to:

Build clean, reusable, consistent UI systems
Collaborate better with designers and teams
Write more maintainable, readable code

Modern React is more than JSX — it’s a design system toolkit.

Pick the right pattern for the job, and your components will scale like pros. 💪✨

Forem: Vishw Patel

How I Deploy My Backend to a VPS (Zero Downtime + Instant Rollbacks,Guide Included)

Who This Article Is Perfect For

The Core Idea

Why Direct Folder Deployments Are Dangerous

Why Immutable Releases Matter

Server Directory Structure

Folder Purpose

Why Symlink Switching Is Atomic in Linux

Deployment Flow

What Happens If Deployment Fails Mid-Upload?

Rollbacks in Seconds

Tech Stack Used

Security Practices

Automatic File Cleanup

Why Not Docker?

Why Not CI/CD Pipelines?

Why Not Git-Based Deployment?

Why This Deployment Strategy Works

Final Thoughts

Bonus

How We Built Secure Cross-App SSO for Multi-Tenant Financial Application : Architecture, Risks, and Lessons

Introduction

High-Level Architecture: Three Portals, Three Responsibilities

Three Types of Users

New Requirement

The Core Problem introduced with requirement

Challenges:

Problem with reusing Admin JWT:

SSO Solution: How We Enabled Secure Cross-App Access

Overall Approach

Admin Portal Login Flow (Before SSO)

The Token Exchange Flow: Step-by-Step

Edge Case: Context Confusion Across Multiple Tabs

Mitigation: Real-Time Tab Coordination

Tradeoffs

Lesson Learned :

Conclusion

Don't call your self react developer until you don't know this

How React Works Under the Hood

1. React DOM: The Rendering Engine

2. How JSX Works Internally

3. Components Are Objects or Functions

4. Reconciliation and Virtual DOM

5. Hooks Internals

6. React Fiber: The Core Architecture

What is Fiber?

Conclusion

Building Dynamic Pagination in React: Server-Side Fetching with Client Components

Building Dynamic Pagination in React: Server-Side Fetching with Client Components

Why Use Dynamic Pagination?

How Pagination Works (At a High Level)

Setting Up the Backend (Fake API Example)

Frontend: React Pagination Example

1. Create a Pagination Service

2. Create a PaginatedList Component

Key Features of This Setup

Server-Side vs Client-Side Pagination: When to Use

Conclusion

Understanding React Server Components (RSC)

Understanding React Server Components (RSC): The Future of React Rendering

What Are React Server Components?

Key Concepts:

Client vs Server Components: What’s the Difference?

Example:

Using RSC in Next.js 14

Folder Structure:

Benefits of Server Components

Minimal JS Bundle Size

Server-Side Data Fetching

Improved Developer Experience

How Server Components Work Internally

Streaming:

When to Use Server Components

Composing Server and Client Components

Security & Limitations

The Future of React with RSC

Conclusion

Scalable React Component Patterns: From Atomic Design to Compound Components

Scalable React Component Patterns: From Atomic Design to Compound Components