GitHub recently shared numbers that show how big this shift is. In September 2026 alone, developers and agents made 7.38 billion commits on GitHub. That is more than five times the number from a year earlier.

Between September 2025 and August 2026, it more than doubled, from 218.2 billion events per month to 473.3 billion.

GitHub says agentic development is driving this growth, and it is now rebuilding the Git infrastructure behind the platform to handle it. In this article, you’ll learn what is changing, why the old design struggles with agents, and how GitHub plans to fix it, in simple terms.

(Source: GitHub Engineering Blog)

Table of Contents

• Why AI Coding Agents Are Changing Software Development
  • How AI Agents Change the Development Workflow
  • How One Push Triggers More Work
• Why GitHub's Existing Architecture Struggles to Scale
  • How GitHub Stores Git Repositories
  • The Architectural Bottleneck: Why Scaling Reads Makes Writes Harder
  • Where the Old Architecture Hits Its Ceiling
  • What Happens When a Fileserver Fails?
• How GitHub Is Redesigning Its Git Infrastructure
  • Separate Storage From Compute
  • How GitHub Plans to Make Pushes Faster
  • How GitHub Moves Maintenance Off the Serving Path
• Adapt or Get Left Behind

Why AI Coding Agents Are Changing Software Development

How AI Agents Change the Development Workflow

Humans and AI coding agents do not use Git in the same way. A developer might push a few times a day. If a push takes a second or two, you will not even notice it.

An agent works differently. It saves its progress after almost every small step, so it commits and pushes again and again. Each time, it has to wait for the push to finish before moving ahead.

Imagine waiting two seconds after typing every sentence in a document. You would feel it very quickly. This is what an agent faces. The time a push takes becomes the speed limit for the whole workflow.

How One Push Triggers More Work

The problem does not end after the push. Many automated systems react to every new commit. For example:

• A continuous integration (CI) pipeline clones the repository to run tests.
• Security scanners clone it to check for vulnerabilities.
• Other agents fetch the new changes to continue their own work.

Cloning means downloading the full repository, and fetching means downloading only the latest changes.

GitHub says CI and code scanning alone can clone or fetch the same branch thousands of times per minute. This pattern, where one action spreads into many, is called fan-out. GitHub Actions ran 3.26 billion times in September 2026, which is more than four times the number from a year earlier.

So every push (a write) creates a large number of reads. These reads must stay fast and cheap, otherwise everything slows down.This is where the old design starts to struggle

Why GitHub's Existing Architecture Struggles to Scale

To understand why the old architecture struggles, let's look at how GitHub stores repositories and why that design becomes a bottleneck for agentic workflows.

How GitHub Stores Git Repositories

GitHub uses a system called Spokes to store and manage Git repositories across multiple fileservers. It keeps copies of each repository in sync so GitHub can handle operations like cloning, fetching, and pushing code.

When a repository is created on GitHub, Spokes assigns it to a set of fileservers - five by default. Each fileserver stores a complete copy of the repository on its local disk. Spokes coordinates these copies to keep the repository data consistent across the fileservers.

When a push arrives, Spokes coordinates the write across the repository's replicas using a quorum-based protocol.

The Architectural Bottleneck : Why Scaling Reads Makes Writes Harder

Now that we understand how GitHub stores repositories, let's look at a problem with this architecture.

Agentic workflows can generate more repository activity than traditional development workflows. CI pipelines, security scanners, and other agents may repeatedly clone or fetch the same repository. As this read traffic grows, GitHub needs a way to serve more requests without slowing down the systems that accept new changes.

In the existing architecture, one way to increase read capacity is to add more fileservers and replicate repository data across them. More replicas can help distribute read traffic, but they also introduce a trade-off.

Remember how Spokes coordinates writes across repository replicas using a quorum-based protocol ?

When a developer or an AI agent pushes new changes, Spokes has to coordinate the write across the fileservers.

When a push updates a reference, Spokes uses a three-phase commit protocol and a quorum to keep repository state consistent. Because the replicas participate in the write, the push can be limited by the slowest replica. Adding replicas to handle more reads can therefore increase the cost of writes.

Now, if GitHub adds more fileservers to handle more read requests, it also has more replicas to manage. This can make writes more complicated and increase the time needed to complete them.

In simple terms, adding more fileservers can help handle more reads, but it can also make writes slower.

The infrastructure used to increase read capacity is also involved in the process of accepting writes. Optimizing one side of the workload can therefore make the other side more expensive.

This becomes a bigger problem when AI agents push changes frequently while CI pipelines and other systems keep reading the repository.

So, the question is: Can GitHub handle more read requests without making writes slower?

That's exactly what GitHub wants to solve with its new architecture.

Where the Old Architecture Hits Its Ceiling

The ceiling comes from a fundamental design choice - durability and scale are the same mechanism. The fileserver replicas are both your serving fleet and backup plans.

This creates three problems:

• Scaling reads hurts writes.
• Scaling writes hurts reads.
• You can't optimise one at a single time without hurting other.

What Happens When a Fileserver Fails?

Let's say one of the five fileserver holding your repository dies. Whether it's disk crashes , the machine lose power or for any other reason.

Now you lose two things :

• You lose one read server - only four machines can serve clone and fetch requests for that repo. Read capacity dropped by 20%
• You lose one durable copy - only four copies of your repo exists instead of five. Your safety margin shrank.

How GitHub Is Redesigning Its Git Infrastructure

Now, let's see how GitHub plans to handle the growing demands of agentic workflows.

Separate Storage From Compute

One of the major changes is separating the storage layer from the compute layer.

In the new architecture repository data will be stored in Azure Blob Storage, which handles data durability and replication. Lightweight compute workers will handle incoming Git requests. The workers will cache data locally to serve requests faster and fetch it from Azure Blob Storage when needed.

Now, when GitHub needs to handle more read traffic, it can simply add more compute workers without adding more replicas to the write path. This means it can increase read capacity without adding the same overhead to writes.

And if a compute worker fails, the repository data is still safe because the actual data lives in Azure Blob Storage. Another worker can take over the requests.

How GitHub Plans to Make Pushes Faster

In the old system, a push involved several operations before GitHub could confirm that it was complete. These included storing Git objects, checking whether they were connected correctly, running secret scanning, and updating the reference.

Not all these operations need to wait for each other. GitHub's new approach is to reduce the work that must finish before a push can be acknowledged.

The key step is updating the reference, which tells Git where the latest commit is. This update needs coordination to keep the repository consistent. Other work, such as storing objects, checking their connectivity, and scanning for secrets, can happen in parallel with other writes.

By reducing the work that has to wait for coordination, GitHub aims to make pushes faster. For AI agents that commit frequently, even a small reduction in push latency can help them move through their workflows faster.

How GitHub Moves Maintenance Off the Serving Path

Previously, repository maintenance tasks, such as compaction and garbage collection, ran on the same fileservers that handled live Git requests. This meant background tasks could compete with incoming requests for CPU, memory, and other resources.

To solve this, GitHub plans to introduce separate workers to handle repository maintenance directly on data stored in Azure Blob Storage. This keeps maintenance work separate from the workers handling live Git requests.

Now, live Git requests and background maintenance run separately, so cleanup tasks are less likely to compete with live requests for the same resources. This helps keep repository operations responsive even as the workload grows.

Adapt or Get Left Behind

AI coding agents are evolving faster than ever. They're changing how we write code, build software, and think about development itself. Tasks that once took hours can now be completed in minutes.

But the bigger lesson isn't just about writing code faster. It's about how the entire software development ecosystem needs to evolve alongside these tools.

GitHub's infrastructure redesign is a great example. As developers change how they work, the systems supporting them must change, too.

Either you evolve with time, or time leaves you behind.

Happy Coding :)

So I'm a full-stack dev ( MERN / PERN ). React, Express, Node, that's my comfort zone. But recently I started learning Angular, and routing in Angular is a whole different game. Some things are surprisingly nice, some things made me go "why is this so complicated?"

So instead of just learning and forgetting, I thought why not write about it? If you're also a React dev exploring Angular for the first time, this one's for you.

Stay tuned and have a look at the sections below.

What’s in this Article !

• How Routing Works in Angular (the mental model, RouterModule, app-routing.module)

• Basic Routing Example

• Lazy Loading (brief intro)

Before starting, I would like to mention - I am not an expert in Angular. I just started exploring it and I'm sharing my knowledge here. So you get to see a React guy's POV while learning Angular sideways.

How Routing works in Angular.

So unlike React - where we have to install npm packages and use React Router or TanStack Router for routing, because React doesn't have routing on its own - in Angular it's totally different. It provides a prebuilt routing architecture that we can use while building projects, and this is what they use in production grade products too.

This is called the Angular Router ( @angular/router ). It comes built-in when you create a project using the Angular CLI.

We don’t have to do npm install, or any third party package, nothing. Just create a project and start routing.

So how to use this? Since i’m using Angular 22 , so we are going to stick to this, we'll be using the standalone approach. If you see older tutorials using RouterModule.forRoot() and app-routing.module.ts , that's the old way. We are not doing that here.

Now before jumping into code, let me quickly explain the key pieces you need to know:

Routes

This is just an array where you define which path should load which component. If you've used React Router, think of it like your route config array. Something like { path: 'about', component: AboutComponent }.

ProvideRouter()

This is how you register your routes in app.config.ts. You pass your routes array inside this function and Angular takes care of the rest.

This is the placeholder in your HTML where the matched component will render. If you know React Router, this is basically <Outlet />. You put this in your app.component.html and Angular will swap components in and out of this spot based on the URL.

routerLink

This is Angular's version of <Link to="/" /> from React Router. Instead of using <a href=""> (which will reload the whole page), you use routerLink for client-side navigation. Looks like this: <a routerLink="/about">About</a>.

That's it. These four things are all you need to set up basic routing in Angular. If you already know React Router, here's a quick cheat sheet:

Basic Routing Example

So , now it’s time to build something. Now we are going to build an Angular app with 4/5 pages.

Follow the steps below:

Step - 1 :

Create a new Angular app.

ng new angular-routing

It will ask you few questions, mae sure to click yes while setting up a new app.

Step - 2 :

Generate the Components

ng g c about
ng g c contact
ng g c home
ng g c pricing

After this your folder structure should look somethig like this-

You can add some basic text in those components tempalte files. So that you can identify the pages easily.

Step - 3 :

Now it’s time to define the routes.

In the app folder, you can see a file named as - app.route.ts

Open this file and initially it shold look like this -

import { Routes } from '@angular/router';

export const routes: Routes = [];

now we are going to write the routing of our project here .

For this- you need to import all components and add them inside the array. this should look like this -

import { Routes } from '@angular/router';
import { About } from './about/about';
import { Contact } from './contact/contact';
import { Home } from './home/home';
import { Pricing } from './pricing/pricing';

export const routes: Routes = [
    {path:'', component: Home},
    {path:'about', component: About},
    {path:'contact', component: Contact},
    {path:'pricing', component: Pricing},
     { path: '**', component: NotFound }
];

If you've used React Router, this is basically your route config array.

That ** refers to wildcard routes, you can obviously create a not-found page and assign it there .

Step - 4 :

Now it’s tme to register the routes.

Open the app.config.ts file and here we need to register the routes in our app.

import { ApplicationConfig, provideBrowserGlobalErrorListeners } from '@angular/core';
import { provideRouter } from '@angular/router';

import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [
    provideBrowserGlobalErrorListeners(),
    provideRouter(routes)
  ]
};

You might have to do this manually or there are high chances it is already done for you, depends on how you configured your app.

Now your entire app has the context of your routing. Now it’s time to use it.

Step - 5 :

Now it’s time to add and navigation links. Open the app.ts file and write this -

import { Component, signal } from '@angular/core';
import { RouterOutlet, RouterLink } from '@angular/router';

@Component({
  selector: 'app-root',
  imports: [RouterOutlet, RouterLink],
  templateUrl: './app.html',
  styleUrl: './app.css'
})
export class App {
  protected readonly title = signal('angular-routing');
}

Important thing to notice here is - In React we don’t need to do this, but in Angular, standalone components need to explicitly declare what they use. Took me a while to get used to this.

Now open the app.html file which is the main template file and write this -

<nav>
  <a routerLink="/">Home</a>
  <a routerLink="/about">About</a>
  <a routerLink="/contact">Contact</a>
</nav>

<router-outlet></router-outlet>

We are basically creating a navbar here and providing the context for routing here.

If you want you can create separate navbar and use that here. I”m doing this to keep things easy and minimal.

Lazy Loading.

For a small app, this is no big deal. But imagine you are working on a production grade product and you have 50 pages.

But your user just want to see the Home page, but their browser is downloading all 50 pages. Obviously this is not the optimised way to handle things.

Now this is where Lazy Loading comes to the game. It only loads a page’s code when the user actually navigate to it. Not before it.

In React this is the same concept but the difference is only how we implement this concept.

As we discussed earlier how to define routes -

import { AboutComponent } from './pages/about/about.component';

{ path: 'about', component: AboutComponent }

This is where we add lazy loading concept. Now if you want this page to lazily load then you have to do this -

{
  path: 'about',
  loadComponent: () => import('./pages/about/about.component')
    .then(m => m.AboutComponent)
}

Important thing to remember - you don’t have to import it at the top.

Now about component will only load when someone actually clicks on it or navigates to it.

So yeah, that's it for Part 1. We covered how routing works in Angular, set up a basic routing example from scratch, and looked at lazy loading. If you made it this far, you know enough to start building stuff with Angular routing.

In Part 2 we’ll learn about :

• Route Parameters & Query Params

• Nested / Child Routes

• Route Guards

If you found this helpful, share it with your dev friends who are still stuck in the React bubble. And follow me so you don’t miss part 2 .

Happy Coding🌻

It's a small program that sits on your machine and manages multiple Node installations. That's its only job — install Node versions and switch between them.

Life Without NVM

Let's assume we don't know what NVM is, and we install Node on our system. Let's say you installed Node 20 on your system, and it gets installed fine.

Now every project, every command, will use Node 20 — because that's the only version available on your system.

But let's add a twist.

You also install a slightly older version, or another newer version, of Node. Now your system has two versions of Node — one you installed first, and one you installed recently.

So the question is — what happens now? By default, which one gets used in your projects or terminal sessions?

Now things get messy. Your system doesn't have a smart manager like NVM, so there are two possibilities.

Option A

The latest install overrides the old one. It doesn't matter whether you installed the latest version first and then an older one, or the other way around — whichever you installed most recently overrides the one before it. That old version is basically gone from your system now.

Option B

They conflict and break each other. Now your terminal is confused about which one to use, and starts throwing weird errors.

Understanding the Real Problem

When you install Node on your system, it gets installed in a specific path — let's say:

/usr/bin/node → Node 20

That's one location, and it works fine. Whenever you use the node command, under the hood it points to this path:

node command → /usr/bin/node → Node 20 ✅

Everything's good — until you install another Node version. Now you have multiple paths on your system where Node lives. So when you type node, it's confused about where to look. Or in the other case, it just picks the first one it finds — and you can't really control that.

This is exactly the problem NVM solves.

How NVM Solves This Problem

Instead of installing Node into your system folders, NVM uses its own isolated folders to install different versions of Node. Inside NVM's isolated folders, the different versions never touch each other — no conflicts, nothing.

NVM entirely controls the PATH. When you run nvm use 16, it points your PATH to the folder that has Node 16 installed — and vice versa.

That's the whole solution: isolated folders, and PATH control.

Setting Up NVM on Linux

Step 1 — Install NVM

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

Step 2 — Reload the terminal

source ~/.bashrc

Step 3 — Verify the version

nvm --version

Step 4 — Install the Node versions you want

nvm install 16.20.2
nvm install 20

Step 5 — Set the default Node version for your machine

nvm alias default 16.20.2

Summary

NVM solves the conflict problem by keeping every Node version in its own isolated folder, and letting you control which one your terminal uses by updating the PATH. Linux uses the original NVM, installed via curl. Windows uses nvm-windows, installed via an exe file. The commands are almost identical on both.

A few days back, I came across an opportunity that I genuinely didn’t want to miss just because I didn’t know Playwright. The problem? I had never really worked with it before, and honestly, it sounded a bit scary at first 😅

So I made a simple decision:
Spend 10 hours learning Playwright with zero excuses.

Surprisingly, it took me around 6 hours to understand the fundamentals, workflow, and how things actually work behind the scenes.

And trust me, those 6 hours were messy 👾
I jumped between the official docs, YouTube tutorials, random errors, and yes… asked ChatGPT some very dumb questions too.

So in this blog, I’m going to share everything I learned in those 6 hours — in a simple 6-minute read for you 🚀

By the end of this blog, you’ll be able to:

• Set up Playwright

• Run your first test

• Record test scripts

• Understand locators and assertions

• Debug tests properly

• Build a small real-world testing workflow

So let’s get started 👨‍💻

What is Playwright.

Before understanding what Playwright actually is, just think about how you normally interact with a website.

Let’s say you want to buy something from Amazon. What do you usually do?

Login → search for the item → click the product → add to cart → place the order → make payment → checkout.

That entire process is called a user flow.

With Playwright, we can automate this entire user flow and test whether the app is working correctly or breaking somewhere after new updates.

Now imagine manually testing this same flow again and again after every small update in the app 💀 Sounds painful, right?

This is exactly where Playwright comes in.👾

Playwright is an end-to-end testing and browser automation framework built by Microsoft that helps developers automate real user interactions inside the browser.

In simple words, Playwright can automatically do the same things a real user would do:

• click buttons

• fill forms

• search items

• navigate pages

• verify results

• and test complete workflows automatically

And the best part? It works across multiple browsers like Chrome, Firefox, and Safari using a single framework.

Installation & SetUp

Installing Playwright is honestly super easy. You just need a Node.js environment and a few commands.

First, create a new project folder and open it inside VS Code.

Then initialize your project:

npm init -y

Now install Playwright:

npm init playwright@latest

Once you run this command, Playwright will start asking you a few setup questions like:

• Which language do you want to use? (JavaScript / TypeScript)

• Where should test files be stored?

• Do you want GitHub Actions setup?

• Do you want to install Playwright browsers?

After setup, Playwright automatically creates a proper folder structure for you 🪄

You’ll notice files like:

tests/
playwright.config.js
package.json

It also installs browser binaries for:

• Chrome/Chromium 🌐

• Firefox 🦊

• WebKit (Safari engine) 🧭

With one setup, you can test across multiple browsers automatically 🚀

Try to read and understand the playwright.config.js file carefully 👀

That file is basically the heart of your Playwright setup.

From there, you can control things like:

• which browser to run tests on 🌐

• headless or UI mode 👨‍💻

• test timeout ⏱️

• screenshots & videos 📸

• base URL

• parallel testing

• retries and much more

At first it may look confusing, but trust me, understanding this one file will make Playwright way easier later on 🚀

Your First Test

When you install Playwright, it automatically gives you an example test file so you can understand how things actually work.

At first, this code may look scary 😵‍💫
But trust me, it’s much simpler than it looks.

So let’s decode this example step by step 👇

Step 1 — Importing Playwright Functions

import { test, expect } from '@playwright/test';

Here:

• test() → used to create a test

• expect() → used to verify whether something is working correctly or not

Think of expect like: In real life how we expect things to be that's how expect works here.

Step 2 — Creating a Test

test('has title', async ({ page }) => {

this creates a test named "has title".

And this page object is super important 👀

page basically represents the browser tab.
Using it, Playwright can:

• open websites

• click buttons

• type into inputs

• navigate pages

• and interact like a real user

Step 3 — Opening a Website

await page.goto('https://playwright.dev/');

This line simply opens the Playwright website in the browser 🌐

Step 4 — Assertion (Checking Something)

await expect(page).toHaveTitle(/Playwright/);

This is called an assertion.

Here Playwright checks whether the page title contains the word "Playwright" or not.

If yes ✅ → test passes
If no ❌ → test fails

Understanding the Workflow

I know it might feel overweling, seeing a lot of new tings at first , but playwright is comparatively easy, Now install a vs code extension named - playwright test for vs code by microsoft.

Before jumping into recording tests and writing automation scripts, let's understand the actual Playwright workflow.

One thing I really liked about Playwright is that it gives you multiple ways to work with it 👀

You can either:

• use the VS Code extension/tools 🧩

• or do everything directly from the command line 💻

I personally started with the VS Code Playwright extension because it makes things way easier for beginners. You get:

• test explorer

• run buttons

• browser controls

• debugging tools

• trace viewer

• and many other powerful features directly inside VS Code 🚀

But the cool part is — behind the scenes, all of these tools are basically running Playwright commands for you.

For example:

• running tests

• debugging

• opening UI mode

• generating tests

Everything can also be done manually through the terminal.

So while the VS Code tools make the experience smoother, understanding the command-line workflow is equally important because that’s how Playwright is usually used in real projects and CI/CD pipelines.

Recording Tests 🌀

This was honestly one of the coolest parts of Playwright for me 😄

Instead of manually writing every single line of automation code, Playwright can actually watch your actions inside the browser and generate the test code automatically.

Yes… literally 😵‍💫

You open a browser, click buttons, type into inputs, navigate pages - and Playwright keeps generating the code in real time.

This feature is called Codegen.

You can start it using the command line:

npx playwright codegen

Or directly from the VS Code Playwright tools 🧩

Once it starts, a browser window opens and starts recording your actions.

For example:

• login to a website

• search for a product

• click buttons

• fill forms

• submit data

And Playwright converts all those actions into actual automation scripts automatically 🚀

Something like this:

await page.goto('https://example.com');
await page.getByRole('textbox').fill('Abhi');
await page.getByRole('button', { name: 'Login' }).click();

This helped me understand the workflow way faster because instead of thinking:

“What code should I write?”

I could first perform the action manually and then observe how Playwright writes the code behind the scenes 👀

One more cool thing I noticed: Playwright also tries to generate smart locators automatically instead of giving random messy selectors all the time.

And honestly, Codegen is one of the fastest ways for beginners to start learning Playwright without feeling overwhelmed.

These are the tolls that will help you to pick locator, assert visibility, assert text, assert value.

Understanding Locators 📍

Now here comes one of the most important concepts in Playwright - Locators.

In simple words, locators help Playwright find elements on the page.

Because think about it 🤔 If Playwright wants to click a button or type inside an input field, it first needs to know:

“Which exact element should I interact with?”

That’s where locators come in.

For example:

await page.getByRole('button', { name: 'Login' }).click();

Here Playwright finds the Login button and clicks it.

Common Locators You’ll Use 👇

By Role

page.getByRole('button', { name: 'Submit' })

This is one of the best and most reliable ways because it works similar to how real users and screen readers interact with the page.

By Text

page.getByText('Welcome')

Finds elements using visible text.

By Label

page.getByLabel('Email')

Super useful for forms and input fields.

By Placeholder

page.getByPlaceholder('Enter password')

Targets input placeholders directly.

By Test ID

page.getByTestId('login-btn')

Very commonly used in real-world projects because it stays stable even if UI changes.

Why Locators Matter So Much ⚡

Bad locators = flaky tests 💀

If your locator is weak or unstable, your tests may randomly fail after small UI updates.

That’s why Playwright recommends using:

• roles

• labels

• text

• test ids

instead of complicated CSS selectors whenever possible.

And honestly, once you understand locators properly, writing Playwright tests becomes way easier 🚀

Assertions ✨

So far we learned how to:

• open a website

• click buttons

• fill forms

• interact with elements

But here’s the real question 👀

How do we actually verify that things are working correctly?

That’s where Assertions come in.

Assertions are basically checks that confirm whether the expected result happened or not.

For example:

• Did the login succeed?

• Is the heading visible?

• Did the page redirect correctly?

• Is the error message showing?

• Did the cart update?

Without assertions, Playwright would just perform actions blindly without verifying anything.

Example of an Assertion 👇

await expect(page).toHaveTitle(/Playwright/);

Here Playwright checks whether the page title contains "Playwright" or not.

If yes ✅ → test passes If no ❌ → test fails

Some Common Assertions

Check Visibility

await expect(page.getByText('Welcome')).toBeVisible();

Checks whether an element is visible on the page.

Check Text

await expect(page.getByRole('heading')).toHaveText('Dashboard');

Verifies exact text content.

Check URL

await expect(page).toHaveURL('https://example.com/dashboard');

Checks whether the current URL is correct.

Check Input Value

await expect(page.getByLabel('Email')).toHaveValue('abhi@gmail.com');

Useful for forms and input validation.

Debugging & Interactive Mode 🐞

While working with Playwright , Your tests will fail sometimes.

And honestly, that’s normal.

Sometimes the locator breaks, sometimes the page loads slowly, sometimes the element is not found… and this is exactly where Playwright’s debugging tools become super useful 🚀Interactive UI Mode 👨‍💻

Playwright comes with an amazing Interactive UI Mode that lets you visually run and inspect your tests.

You can start it using:

npx playwright test --ui

Once it opens, you can:

• run tests visually

• see each test step

• inspect failures

• watch browser actions live

• replay tests

• debug easily

Honestly, this made learning Playwright way easier for me because I could literally see what was happening instead of guessing blindly 😭

Final Thoughts 🌻

Honestly, there’s still a lot more to explore in Playwright.

Things like:

• CI/CD integration

• advanced debugging

• reporting

• and scaling large test suites

This blog was just a beginner-friendly guide to help you get started without feeling overwhelmed.

And trust me, Playwright looks scary only in the beginning 😄 Once you understand the workflow, things start making sense pretty quickly.

My biggest advice would be: Don’t try to memorize everything.

Instead:

• run tests

• break things

• debug errors

• experiment with locators

• and build small real-world flows

That’s honestly the fastest way to learn.

I learned most of this in around 6 hours just by trying things myself, getting confused, reading docs, watching videos, and asking questions constantly 😂

So if you’re someone who was avoiding Playwright because it sounded complicated… hopefully now it feels a little less scary 👨‍💻

Happy Testing 🌻

And if you’re reading this, there’s a high chance that you didn’t even bother to Google it or ask ChatGPT.

But don’t worry — I’m no different. I was in the exact same place.

After hearing these terms again and again, I finally decided to Google them and do some basic research. And you know what?

It’s not as complicated as it sounds.

Monolith. Microservice.
Big scary words… but very simple ideas.

The names might scare you, but under the hood, these are just design choices — ways to structure your application depending on your requirements and how much you want to scale.

So today, we’re going to break this down in the simplest way possible.

No overcomplicated definitions. No boring theory.

Just clear understanding.

Let’s get started 🚀

MONOLITH

If you came this far, I’m assuming you’re a grown man/woman, and you’ve probably gone grocery shopping at least once in your life.

Monolith architecture is like your shopping cart.

I’m not talking about your digital cart. Imagine the physical carts kept at the entrance of a supermarket, stacked together in a long line. You pick one, walk through the aisles, and keep throwing everything into that single cart.

Everything. In one place.

That’s exactly how monolith architecture works.

You keep every required service of your application in a single codebase, running as one system.

For example, I recently built tokenmitra.online — a queue management and appointment automation system for medical clinics using the MERN stack.

In tokenmitra.online , I used a monolithic architecture. Everything lives in one place:

User, Auth, Bookings, Appointments, Messages — all inside a single application.

This approach is great for beginners (like me). It’s simple to build and easy to manage in the early stages.

But as you might have guessed, everything is tightly coupled.

If one part has an issue or needs scaling, you often end up affecting or scaling the entire application.

Monolith architecture is simple to start but painful to scale...

Problems with Monolith architecture

So if you’re not a web crawler gathering data, I can assume that by now you’ve already guessed the problems with monolith architecture. But still for better clarity, let's discuss the problms:

• Everything is tightly coupled

In a monolith, all your services live together.

• Scaling becomes painful

Let’s say only your booking service is getting heavy traffic. But in a monolith, you can’t scale just that part.

You have to scale the entire application.

• Codebase becomes messy over time

At the beginning, everything feels clean. But as features grows everything becomes messy.

• Slower development speed

If multiple developers are working you can't increase the development speed.

• Hard to adopt new tech

In monolith: everything uses same tech stack.So if you want to use a new database or try a different language , It becomes very hard without affecting the whole system.

• Deployment is risky

Even a small change requires redeploying the whole app.

MICORSERVICE

So let’s move on to microservices.

After everything we just discussed, I don’t think I need to repeat the question: “Why do we need microservices?”

If you can read (and you made it this far), you already have an idea why.

Now let's talk about What is Microservice.

Let’s go a bit deeper into this.

In microservices architecture, every service is independent.

As shown in the image, services like Auth, Booking, Messages, and User are all separate and communicate with each other through APIs.

Each service runs in its own space and handles a specific responsibility.
This makes the system more organized and easier to manage.

These services are loosely coupled.
Which means changes in one service do not directly affect others.

Because of this:

• You can scale only the service that needs more resources (for example, booking service during high traffic)

• The codebase remains cleaner and more maintainable

• Teams can work on different services independently

• You can use different technologies for different services if needed

Microservices give you more flexibility and control over your application as it grows.

TLDR

At the end of the day, both monolith and microservices are just different ways to structure your application.

Monolith is simple and a great starting point.
Microservices bring flexibility and scalability as your application grows.

There is no “one size fits all”.

It always depends on your use case, your team, and how big your system is going to be.

Happy Coding

But doing this for the first time… I had to deal with a lot of issues.
One of the major ones was CORS, which took some time to figure out.

I was using JWT + cookie-based auth, and I had also bought a cheap domain from GoDaddy and started using it.

I added all the required A records, CNAME, and all that stuff.

But the real problem was something deeper… something I didn’t even realize at first.

My frontend (hosted on Render along with the backend) started showing this error:

We weren't able to issue a certificate

And that’s where the real debugging started… 😅

Honestly, I’m not some expert who understands all these concepts deeply.
But I kept trying different things… and kept failing 😅

At first i thought :

• Maybe I messed up A record

• Maybe DNS not propagated

• Maybe Render is buggy

But after doing some digging, I realized the issue is something else… something I didn’t even understand.

So I did what every developer does 😅
I used LLMs to figure out what was actually going wrong.

The Actual Problem

I realised the issue was with GoDaddy DNS, not my code, not my deployment.

GoDaddy silently adds something called CAA records ( Certification Authority Authorization).

These records basically says :

Only specific companies can issue SSL certifcates for this domain.

Now the thing is :

• Render uses something known as - Let's Encrypt

• GoDaddy's default CAA does not always allow it .

So render tried → Got blocked → SSL failed 🥲

How i Debugged it

After showign this error multiple time , the first thought came to my mind was -

• I'm doing nothing wrong.

• Domain pointing correctly .

• App working on default domain .

• But only SSL failing

Now as someone who has no experience working with all these , i used LLM chatbots to find a solution. And then i get to know that -

Instead of fighting wiht GoDaddy DNS i can replace it with something better.

The Fix: Moving DNS to Cloudflare

Here is exactly what i did.

Step 1 : Created a Cloudflare Account

Go to Cloudflare.

Sign up ( i choose the free plan )

Step 2 : Add your Domain

Click "Add a site"

Enter your domain : tokenmitra.online

Choose Free plan

Now Cloudflare will automatically Scan your existing DNS & import A, CNAME etc.

Step 3 : Verify DNS Records

Double check these things :

• A record → Points to your backend ( mine was pointing to render )

• CNAME → Points to frontend ( i deployed my fronted in vercel this time)

Don't blindly trust import - verify everything.

Step 4 : Change Nameservers in GoDaddy

Go to GoDaddy

• Open your domain settings

• Find Nameservers

• Replace :

ns01.domaincontrol.com
ns02.domaincontrol.com

With Cloudflare nameservers (example):

cruz.ns.cloudflare.com

dean.ns.cloudflare.com

This is the main switch - now Cloudflare controls your DNS.

Step 5 : Wait for DNS Propagation

Now as you have almost done everything, but one thing to remember, still you have to wait and the time depends from 10-60 minutes.

In my case i just sleep and woke up with everything running.

Now Cloudflare is active & GoDaddy DNS is no longer being used.

Step 6 : Retry SSL Insurance

Now go back to Render dashboard & trigger redeploy or Wait.

This time you will find no errors.

Final Thoughts

This bug taught me someting important:

Sometimes the problem is not in your code,

It's in the infrastructure around it .

In this article, I’m going to explain routing in modern React apps, along with a simple setup guide.

So, let’s get started 🚀

When i started learning about routing in react, at first i get overwelmed .

BrowserRouter, RouterProvider, createBrowserRouter — too many things to digest .

But instead of just watching some random youtube tutorial i tried to understand things, and here i'm going to share what i have understand so far.

React Router vs React Router DOM

So, the first confusing thing in this journey is understanding what React Router and React Router DOM actually are.

If you dig a little deeper, you’ll find that React Router is the core package - it contains all the main routing logic and functionalities.

On the other hand, React Router DOM is the web-specific package used for browser-based React apps. It is built on top of React Router and depends on it, but it’s specifically designed for the web.

So, if you’re working with web apps (which most of us are), you’ll be using React Router DOM almost all the time - basically the web version of React Router.

Installing Dependencies

To install React Router DOM :

npm install react-router-dom

You don't need any extra package, this will do the job for you.

Understanding the Modern Approach

So there are mainly two ways , how you can use routing in react by using react-router-dom.

Old Way - BrowserRouter + Routes

Modern Way - createBrowserRouter + RouterProvider

Today we are going to learn about the modern approach .

BrowserRouter + Routes

This is what everyone learned in 2022–2025. Super simple and readable with JSX.

• Wrap your app with

• Define routes using and components

Pros: Easiest to understand, perfect for small/medium apps or beginners.
Still 100% supported in v7.

createBrowserRouter + RouterProvider

This became the official recommended way starting in v6.4 and is even stronger in v7.

• You define all your routes as a JavaScript array/object

• Use createBrowserRouter()

• Render everything with

Pros: Unlocks powerful Data APIs (loaders for fetching data before the page renders, actions for forms, parallel loading, built-in error boundaries, pending UI, etc.).

It comes with Better performance and future-proof.

And today we are going to learn about this modern way and do some basic rouer setup using this.

Setup Guide :

Step - 1 : Create Rouer

Create a routes folder inside your src directory. Now create a AppRoutes.jsx file inside the routes folder.

Now this is the perfect place where you can create the router.

import { createBrowserRouter } from "react-router-dom";
import App from "../App.jsx";
import About from "../pages/publicC/About.jsx";

const router = createBrowserRouter([
  {
    path: "/",
    Component: App,
    children: [
      { index: true, Component: Landing },
      { path: "about", Component: About },
    ],
  },
]);

export default router;

Now you must be thinking why should i create a separate routes folder and do all this.

Honestly you don't have to do this , but it's a good practice.

As your app grows, routing can get messy - lots of paths, nested routes, layouts, etc. Keeping everything inside a routes folder helps you :

• To keep things organized

• Separate routing logic from UI components

• Easily find & manage all routes in one place.

Alternatives : You can always do what you want to do, even you can define the routes directly inside App.jsx , if your project is small.

What does "Creating a router" means?

When we use createBrowserRouter, we basically define all the routes of our app in one place.

You are basically telling react :

• What URL maps to which component

• how routes are nested

• what should render inside what

This is your app's navigation blueprint

createBrowserRouter([....])

Step - 2 : Add RouterProvider

Now it's time to add the RouterProvider , so go to your main.jsx file and do this

import { StrictMode } from "react";
import { createRoot } from "react-dom/client";
import "./index.css";
import { RouterProvider } from "react-router-dom";
import router from "./routes/AppRoutes.jsx";

createRoot(document.getElementById("root")).render(
  <StrictMode>
    <RouterProvider router={router} />
  </StrictMode>,
);

Now let's talk about what does this even mean..
So after creating the router, now it's time to connect your router to your app.

Like think about it , you created the routes, but now how your app will know about it ???
You have to tell it right .

When you do this :

<RouterProvider router={router} />

You are basically telling React :

Hey , use this router to control navigation in my app.

And the router is the router object, that you are exporting from the AppRoutes.jsx file.

Without RouterProvider , your router is just defined ... but not used yet!

Now you must be thinking but why do need to do all these with main.jsx ??

Because this is the entry point of your app - so you wrap your whole app with routing from the start.

Step - 3 : use Outlet in the App

Now go to your App.jsx file and do this

import { Outlet } from "react-router-dom";

const App = () => {
  return (
    <>
      <Outlet />
    </>
  );
};

export default App;

Ok, so let's try to understand what we just did here .

is basically a placeholder - It tells React Router:

Render the child route component here only

Why do we need Outlet ?

first look at your roues ;

{
    path: "/",
    Component: App,
    children: [
      { index: true, Component: Landing },
      { path: "about", Component: About },
    ],
  },

here :

• App is the parent route.

• Landing and About are child router.

So when you go to :

• / - Landing page should render

• /about - About page should render

But where should they render inside App ?

That's where comes in the picture.

Outlet basically Renders the matching child route in the place of

Think like this - you have Navbar & Footer to show in each page, but you don't want to write it everywhere. So now what ?

Now you will use Outlet -

const App = () => {
  return (
    <>
      <Navbar />
      <Outlet />
      <Footer />
    </>
  );
};

Navbar & Footer stays same , only the middle content changes.

Nested Routes

Nested Routes - as you can understand from the name it mean - routes inside routes.

Nesting is useful in real apps, as many pages share the same layout.

For Example :

• Navbar stays same

• Footer stays same

• Only content changes

So instead of repeating the same code again and again, we use nested routes.

Layouts are just like wrapper components that holds common UI. Like you discussed while talking about .

{
    path: "/",
    Component: App,
    children: [
      { index: true, Component: Landing },
      { path: "about", Component: About },

      {
        path: "auth",
        Component: AuthLayout,
        children: [
          { path: "login", Component: Login },
          { path: "register", Component: Register },
        ],
      },
    ],
  },

Here App is the main layout ( Navbar / Footer included within)

AuthLayout is different layout ( no Navbar/ Footer , simple page )

Example :

• / → App → Landing

• /about → App → About

• /auth/login → AuthLayout → Login

• /auth/signup → AuthLayout → Signup

Simple Idead : how you can understand -

• Parent = layout

• Child = actual page

• Outlet = where page shows

Common Mistakes

There are some common mistakes that beginners fall easily. So let's talk about those so you can avoid repeating the same mistakes.

1 - Mixing element & component

React router has two styles :

OLD style -

element : <Home/>

NEW style -

Component : Home

Don't mix them randomly in the same setup.

Pick one style ( prefer Component for modern apps) and stay consistent.

2 - Forgetting

As we discussed about Outlet and it's usecase above, i think you already understand how important it is to use , but still sometimes while working with nested routes you might forget to use it .

And that's what cause problem. Now your child routes will not render at all . So always remember to use Outlet.

3 - Using BrowserRouter + RouterProvider together

Using BrowserRouter & RouterProvider is another mistakes that beginners do.

This is wrong and using BrowserRouter is the old way. So try to stay updated with the React Router docs and write code mindfully.

Common Folder Structure :

Conclusion

That’s it for this one.

This blog was just a beginner-friendly guide to help you get started with the modern setup using createBrowserRouter. If you can set up routes, use <Outlet />, and understand nesting - you’re already ahead of many beginners.

Of course, there’s still more to explore like data fetching (loaders), error handling, and protected routes. I didn’t cover those here to keep things simple and focused.

You can always refer to the official React Router docs if you want to go deeper - they have everything in detail.

I’ll probably write more about the advanced stuff in the next part.

For now, just try building something small using this setup - that’s where the real understanding comes from 🌻

Because in this cruel world, everyone can make a promise, but no one really knows how to keep a promise. So I'm on a mission to make this world a better place by teaching you not just how to make a promise, but how to actually keep it.😌🤝

So let's get started. But before we jump into Promise methods, I want to explain about- what is a Promise?

Just in case some nerd opens this article who doesn't even know how to make one Promise but is trying to learn the methods. Kind of like me trying to build a full-stack app right after learning HTML.

What is a JavaScript Promise ?

A Promise in JavaScript is an object that represents the eventual completion or failure of an asynchronous task.

As we all know Javascript is a single-threaded and synchronous language, So it can only handle one task at a time - and that to be a synchronous task.

So now what JavaScript will do when he have to do some async task ?

Let's take an example from a Bollywood movie.

You have seen this many times - the hero finds his soulmate and wants to marry her.

But he can't just do it. Why? Because first of all, this is India, not Los Angeles.

Our hero needs to convince the religious + strict + stereotype father of that girl. And he can only marry her when the father gives the green signal. But trust me my friend this is not easy as it sounds.

For now, let's say the hero is "RAJ" and the heroine is "SIMRAN"

And just like our movie, JavaScript works in a similar way. When it needs to handle any async task, it makes a Promise. Now that Promise has 3 states.

Anything can happen. You never know if the strict father will agree or not. In the same way, you never know whether the Promise will resolve or reject.

Three states of a Promise :

1- Pending

2- Fulfilled**

3- Rejected**

Let's deep dive into what does these states even mean …..

• When promise is pending - RAJ promises to win SIMRAN & He goes to convince her strict father. ( Now RAJ is on his way not reached yet …… still in the train…….) 🏃‍♀️🚂

• When promise is fulfilled - RAJ finally convinced SIMRAN'S father's approval. Now RAJ & SIMRAN can live happily ever after:)🧎‍➡️🧍‍♀️

• When promise is rejected - RAJ failed to convince SIMRAN'S strict father and SIMRAN married someone else. :( 🧍‍♀️🚂💃

So I hope now you have a better understanding of JavaScript Promises.

And if you are not an Indian, then I assume I just gave you an insider tip on how to make your own Bollywood movie.

Now it's time for the main thing. Are you all excited !!!

Let's start discussing about Promise Methods in Javascript.

Promise Methods in JavaScript

So in JavaScript Promise we have mainly 2 types of methods -

Instance Method

• promise.then()

• promise.catch()

• promise.finally()

Static Method

• Promise.all()

• Promise.allSettled()

• Promise.race()

• Promise.any()

• Promise.resolve()

• Promise.reject()

Let's start with Instance Methods. But alwys remember one thing before all these one thing has already happened - which is promise creation.

RAJ already promised SIMRAN:

"Simran, I will win your father's approval and come back for you."

promise.then()

This method runs when a promise is fulfilled. Which means Happy Ending of our story. Promise is resolved. RAJ finally wins the heart of SIMRAN's strict father.

.then() executes when :

• Promise is fulfilled

• It receives the resolved value.

let rajPromise = new Promise((resolve, reject) => {
    let fatherAgrees = true;

if (fatherAgrees) {
        resolve("Simran mil gayi ❤️");
    } else {
        reject("Bauji ne mana kar diya 💔");
    }
});

rajPromise.then((result) => {
    console.log("Success:", result);
});

Now if resolved - .then() runs and we get "Simran mil gayi ❤️ " as result.

If rejected - .then() is skipped.

The interesting thing here is You can always chain .then() and Each .then() returns a new promise. promise

promise
  .then((res) => {
    console.log(res);
    return "Cold drink";
  })
  .then((drink) => {
    console.log(drink);
  });

Promise chaining is like -

• RAJ wins father

• Then marry SIMRAN

• Then they live happily …..

promise.catch()

This method runs when the promise is rejected.

When SIMRAN'S father says - "Mat ja SIMRAN".

Now the Promise that RAJ made to SIMRAN is rejected. Raj fails & Love story breaks.

let rajPromise = new Promise((resolve, reject) => {
    let fatherAgrees = false;

if (fatherAgrees) {
        resolve("Simran mil gayi ❤️");
    } else {
        reject("Bauji ne mana kar diya 💔");
    }
});

rajPromise.then((result) => {
    console.log("Success:", result);
}).catch((error) => {
      console.log("Error:", error);
  });

Now as we can see the fatherAgrees is false , so now the .catch() method will work here and we will get error as - "Bauji ne mana kar diya 💔"

promise.finally()

This method runs no matter what happens. It will run whether promise resolved or rejected.

This method is like the TRAIN that leaves anyway.

If RAJ gets SIMRAN or not . The TRAIN will not stop for anyone, it will leave the station.

rajPromise
  .then((result) => {
      console.log("Success:", result);
  })
  .catch((error) => {
      console.log("Error:", error);
  })
  .finally(() => {
      console.log("Train has left the station 🚂");
  });

Unlike .then() and .catch() , .finally() doesn't receives any value. It is mainly used for cleanup tasks.

Now as we have completed learning about Instance Methods , now let's start our Static Methods.

Promise.resolve()

Imagine SIMRAN'S Father immediately says: "Ja SIMRAN, Jee le apni zindagi".

Now there is no struggle.

No delay. Already Successful.

This is exactly how Promise.resolve() works.

It creates a promise that is already fulfilled. let p = Promise.resolve("Simran mil gayi ❤️");

let p = Promise.resolve("Simran mil gayi ❤️");

p.then(data => console.log(data)); 

Use When:

• You want to return a resolved promise

• Convert normal value into promise

Promise.reject()

Now SIMRAN'S Father says : "Bilkul nahi"

Which means her father denied. Now there is No more chance for RAJ to marry SIMRAN. Direct Failure.

And this is how Promise.reject() works. Already rejected promise.

let p = Promise.reject("Shaadi cancel 💔");

p.catch(err => console.log(err));

You can use this when you want to manually trigger failure.

Promise.all()

Now RAJ must complete All tasks:

• Convince SIMRAN's father

• Impress SIMRAN's mon

• Fight with Villains

Now if ANY ONE fails - then RAJ & SIMRAN can't be together.

Only when ALL SUCCEED - then weeding happens.

And this is how exactly Promise.all() works.

let bauji = Promise.resolve("Bauji agreed");
let mom = Promise.resolve("Mom agreed");
let goons = Promise.resolve("Villains defeated");

Promise.all([bauji, mom, goons])
  .then(results => {
    console.log("Shaadi pakki:", results);
  })
  .catch(err => {
    console.log("Mission failed:", err);
  });

• If ONE rejects - whole thing rejects.

• This method returns array of results.

Promise.allSettled()

Now it is like RAJ wants to know :

• Who aggred

• Who rejected

Even if someone says no, he still wants to know all outcomes.

And this is how Promise.allSettled() method works.

Marriage may or may not happen - but we get full report of who aggred and who disagree. (So we can deal with them later 😈)

let bauji = Promise.resolve("Bauji agreed"); let mom = Promise.resolve("Mom agreed"); let fufaJi = Promise.reject("FufaJi said no");

let bauji = Promise.resolve("Bauji agreed");
let mom = Promise.resolve("Mom agreed");
let fufaJi = Promise.reject("FufaJi said no");

Promise.allSettled([bauji, mom, fufaJi])
  .then(results => {
    console.log(results);
  });

Output looks like :

[
  { status: "fulfilled", value: "Bauji agreed" },
  { status: "fulfilled", value: "Mom agreed" },
  { status: "rejected", reason: "fufaJi said no!" },
]

This method never rejects.

Always gives status of all promises.

Promise.race()

RAJ is running to catch the train & SIMRAN is waiting.

Whoever happens FIRST decides the FATE.

• If RAJ reaches the train first - love wins

• If TRAIN leaves the station first - love lost

And this is how Promise.race() works.

First settled promise always wins. No matter it is resolved or rejected.

let raj = new Promise(resolve =>
  setTimeout(() => resolve("Raj reached train"), 2000)
);

let train = new Promise(( reject) =>
  setTimeout(() => reject("Train left 💔"), 1000)
);

Promise.race([raj, train])
  .then(res => console.log(res))
  .catch(err => console.log(err));

Promise.any()

RAJ tries to :

• Convince SIMRAN's father

• Convince SIMRAN's mom

• Convince SIMRAN's fufaJi

Now situation got out to control. RAJ just need at least one persons approval to their relationship. IF any one of these aggrees then RAJ and SIMRAN can live happily. They just need one validation now.

And this is how Promise.any() works.

let p1 = Promise.reject("Bauji no");
let p2 = Promise.reject("Mom no");
let p3 = Promise.resolve("fufaJi helped");

Promise.any([p1, p2, p3])
  .then(res => console.log("Hope alive:", res))
  .catch(err => console.log("All rejected:", err));

This method resolves when FIRST fulfilled promise comes.

This method rejects only when all are rejected.

Summary

At the end of the day, a Promise in JavaScript is simple - handle it properly, and it won't break your app… or your heart. I tried my best to keep the Hindi minimal so this article stays accessible to everyone . I hope you enjoyed the story.

#chaicode #javascript #promise