DEV Community: Ashay Tiwari

Inheritance in OOP: Solving Code Duplication or Creating New Problems?

Ashay Tiwari — Thu, 25 Jun 2026 07:29:46 +0000

Many developers learn:

Inheritance allows code reuse.

Technically true.

But if that's your primary reason for using inheritance, you'll often create bad designs.

❓ Why Was Inheritance Invented?

Imagine:

User
 ├── Customer
 ├── Admin
 └── Seller

All of them have:

id
name
email
login()
logout()

Instead of duplicating these everywhere:

class Customer { ... }
class Admin { ... }
class Seller { ... }

we extract common behavior:

class User {
  id: string;
  name: string;
  email: string;

  login() {}
  logout() {}
}

Then:

class Customer extends User {}

class Admin extends User {}

class Seller extends User {}

This creates an IS-A relationship.

Admin IS A User

Customer IS A User

Seller IS A User

This is the most important rule of inheritance.

What Does `extends` Actually Do?

Consider:

class User {
  login() {
    console.log('login');
  }
}

class Admin extends User {}

Now:

const admin = new Admin();

admin.login();

works.

Why?

Because JavaScript walks up the prototype chain:

admin
   ↓
Admin.prototype
   ↓
User.prototype

and finds login().

Inheritance is fundamentally prototype delegation.

User
   ↓
Admin

Admin has everything a User has, plus additional capabilities.

Example:

class User {
  login() {}
}

class Admin extends User {
  banUser() {}
}

Now:

admin.login();
admin.banUser();

Overriding Methods

Children can change behavior.

class User {
  getRole() {
    return'User';
  }
}

class Admin extends User {
  getRole() {
    return'Admin';
  }
}

Now:

newUser().getRole();
// User

newAdmin().getRole();
// Admin

Same method name.

Different behavior.

This becomes important later when we discuss polymorphism.

🤯 The Biggest Mistake with Inheritance

The Hidden Problem

Over time, developers started encountering a different challenge.

Imagine we have a Vehicle class:

class Vehicle {
  start() {}
  stop() {}
  lockDoors() {}
}

Seems harmless.

But what happens when we introduce a Bicycle?

class Bicycle extends Vehicle {}

Bicycles don't have doors.

Yet they've inherited door-related behavior.

Now our model starts feeling strange.

The problem becomes even worse as systems grow.

Developers often found themselves inheriting behavior they didn't actually need.

Changes in parent classes unexpectedly affected child classes.

The hierarchy became increasingly difficult to maintain.

What started as a solution to code duplication sometimes created tightly coupled systems.

⚔️ The Double-Edged Sword

Inheritance solves one problem very well:

Reusing common behavior.

But it can introduce another:

Tight coupling between parent and child classes.

The child depends heavily on decisions made by the parent.

As hierarchies become deeper, understanding the system becomes harder.

A small change in a base class can ripple through multiple child classes.

This is one reason why modern software design is often more cautious about using inheritance.

✅ When Inheritance Is Actually Good

Use inheritance when:

1. Real IS-A relationship exists

Admin IS A User

Manager IS An Employee

Dog IS An Animal

2. Parent behavior is truly shared

class User {
  login() {}
  logout() {}
}

All child classes genuinely need this.

3. Hierarchy is shallow

Good:

User
 ├─ Admin
 └─ Customer

Bad:

User
 ↓
Employee
 ↓
Manager
 ↓
RegionalManager
 ↓
DistrictManager
 ↓
SuperDistrictManager

⏭️ What's Next?

Inheritance helped developers reuse behavior.

But over time, many teams discovered that inheritance wasn't always the most flexible solution.

This led to an important shift in software design thinking:

Instead of inheriting behavior, what if we assembled behavior from smaller pieces?

In the next article, we'll explore Composition vs Inheritance and understand why many modern applications prefer composition when building complex systems.

Abstraction in OOP: Hiding Complexity Without Hiding Capability

Ashay Tiwari — Wed, 17 Jun 2026 12:24:42 +0000

In the previous article, we discussed Encapsulation and how objects should control changes to their own state.

Now let's talk about another fundamental concept of Object-Oriented Programming: Abstraction.

Like always, let's start with a problem.

The Problem

Imagine you own a car.

To drive it, you do a few simple things:

Start the engine.
Press the accelerator.
Apply the brakes.
Turn the steering wheel.

You don't need to know:

How fuel is injected into the engine.
How the pistons move.
How the gearbox changes gears.
How combustion generates power.

All that complexity is hidden from you.

You simply interact with a straightforward interface.

Software systems work in a very similar way.

A Real-World Example

Suppose we need to send an email.

The application code might look like this:

emailService.send({
  to: "john@example.com",
  subject: "Welcome!",
  body: "Hello John"
});

Looks simple.

But what actually happens behind the scenes?

Potentially a lot:

Validate the email address.
Create an SMTP connection.
Authenticate with the provider.
Build the message.
Retry if sending fails.
Log failures.
Close the connection.

As consumers of email service, we don't care about those details.

We only care that:

If I call send(), the email should be sent.

This is exactly the problem Abstraction tries to solve.

The Problem with Exposing Everything

Imagine if sending an email required every caller to do this:

connect();
authenticate();
buildMessage();
sendMessage();
disconnect();

Every single time.

Suddenly:

Every consumer knows too much.
Every consumer is responsible for the implementation.
Changing the implementation becomes painful.

What if we switch from SMTP to a third-party email provider?

Now every place that sends emails needs to change.

The consumers have become tightly coupled to implementation details.

The Idea Behind Abstraction

Abstraction is about exposing what an object can do while hiding how it does it.

Instead of exposing every implementation detail, we expose only what consumers need.

For example:

emailService.send(email);

The caller doesn't need to know:

Which provider we're using.
How authentication works.
How retries are handled.
How messages are constructed.

Those details remain hidden.

Consumers interact with a simple and stable interface.

Abstraction Is Not the Same as Encapsulation

These two concepts are often confused.

Encapsulation asks:

Who should be allowed to change the object's state?

Abstraction asks:

What details should consumers be aware of?

Encapsulation protects data.

Abstraction hides unnecessary complexity.

They often work together, but they solve different problems.

What's Next?

So far, we've discussed:

How objects protect their state using Encapsulation.
How objects hide complexity using Abstraction.

Next, we'll look at another question developers faced:

If multiple objects share similar behavior, do we really need to write that code repeatedly?

This leads us to one of the most well-known—and sometimes controversial—concepts in OOP:

Inheritance.

Encapsulation in OOP: Protecting an Object's State from Unintended Changes

Ashay Tiwari — Mon, 15 Jun 2026 08:16:37 +0000

In the previous articles, we discussed why Object-Oriented Programming was introduced and explored different ways of creating objects using factory functions and classes.

Now it's time to look at one of the most important ideas behind OOP: Encapsulation.

Like every concept in this series, let's start with the problem rather than the definition.

The Real Problem Encapsulation Solves

Imagine you're building a bank account.

Without encapsulation:

class BankAccount {
  balance = 1000;
}

const account = new BankAccount();

account.balance = -50000;

Now your account contains:

Balance = -50000

which may be impossible according to business rules.

The problem isn't that someone changed a variable.

The problem is:

Anybody can put the object into an invalid state.

Encapsulation is NOT About Hiding

Most beginners think:

Encapsulation = private fields

No.

Private fields are just one tool.

The actual goal is:

Protecting the integrity of an object's state.

An object should control how its data changes.

Why This Becomes Dangerous

In small applications, unrestricted access may not seem like a big deal.

As applications grow, however, data starts being accessed from many places.

Imagine:

A payment module updating balances.
A refund module updating balances.
An admin panel updating balances.
A reporting service reading balances.

Now suppose an issue appears.

A customer's balance becomes negative.

Where did it happen?

Which part of the application modified it?

Was validation skipped?

Did someone accidentally overwrite a value?

The more places that can directly manipulate data, the harder it becomes to reason about the system.

A Better Design

Instead of:

account.balance = -50000;

force all changes through methods:

class BankAccount {
  private balance = 1000;

  deposit(amount: number) {
    this.balance += amount;
  }

  withdraw(amount: number) {
    if (amount > this.balance) {
      throw new Error('Insufficient funds');
    }

    this.balance -= amount;
  }

  getBalance() {
    return this.balance;
  }
}

Now:

account.withdraw(500);

is allowed.

But:

account.balance=-50000;

is impossible.

The object protects itself.

Think Like a Security Guard

Imagine a company database.

Bad design:

Employee Database
      ↑
Everybody can modify it

Good design:

Employee Database
      ↑
HR Department
      ↑
Employees submit requests

Employees don't directly change records.

They request changes.

The HR department validates them.

Encapsulation works exactly like this.

The Idea Behind Encapsulation

Encapsulation is about controlling access to an object's internal state.

Instead of allowing anyone to modify data directly, the object becomes responsible for managing its own data.

Rather than exposing the balance:

account.balance = 5000;

we expose behaviors:

account.deposit(5000);

account.withdraw(5000);

Now every change passes through rules defined by the object itself.

The object protects its own integrity.

This is the real purpose of Encapsulation.

Not hiding data.

Protecting data.

Encapsulation in TypeScript

TypeScript gives us access modifiers.

class User {
  public name: string;

  private password: string;

  protected role: string;
}

public

Accessible everywhere.

user.name

works.

private

Accessible only inside the class.

user.password

❌ Error

protected

Accessible inside:

current class
derived classes

class User {
  protected role = 'user';
}

class Admin extends User {
  checkRole() {
    console.log(this.role);
  }
}

Works.

Important Reality About TypeScript

Many developers are surprised by this.

TypeScript:

private balance = 1000;

is primarily a compile-time restriction.

After compilation to JavaScript:

this.balance = 1000;

still exists.

TypeScript prevents you from accessing it in code, but it's not true runtime privacy.

Modern JavaScript introduced:

#balance

which is actual runtime privacy.

class Account {
  #balance = 1000;
}

Now:

account.#balance

is impossible.

The Key Takeaway

Encapsulation is often described as hiding data.

A more useful way to think about it is this:

Encapsulation ensures that an object controls how its own state changes.

By doing so, it protects business rules, reduces accidental misuse, and makes software easier to maintain as systems grow.

What's Next?

Encapsulation helps us control access to data.

But another challenge still remains.

Even when objects manage their own state correctly, consumers often need to understand too many implementation details to use them.

In the next article, we'll explore Abstraction and see how hiding unnecessary complexity allows us to build systems that are easier to use and easier to change.

Factory Functions vs Classes: If Classes Exist, Why Do We Still Use Factory Functions?

Ashay Tiwari — Wed, 10 Jun 2026 06:03:28 +0000

❓ A Question That Confused Me

As we continue learning Object-Oriented Programming, I want to pause for a moment and discuss something that often comes up for JavaScript developers.

When we hear about OOP, we usually hear about classes.

class User {
  constructor(name) {
    this.name = name;
  }
}

We've discussed that classes are used to create objects.

Fair enough.

But then we look at JavaScript codebases and see something like this:

function createUser(name) {
  return {
    name
  };
}

No class.
No constructor.
No new keyword.

And yet, we're still creating objects.

This raises a very reasonable question:

What is this called? And if these kinds of functions can create objects, why do classes exist?

To answer that, let's first understand the problem developers were trying to solve.

The Simplest Possible Approach

Suppose we're building an application and need user objects.

Our first instinct might be:

const user1 = {
  name: "Ashay",
  email: "ashay@gmail.com"
};

const user2 = {
  name: "Rahul",
  email: "rahul@gmail.com"
};

Looks fine.

Until we realize that every user should also be able to update their email.

const user1 = {
  name: "Ashay",
  email: "ashay@gmail.com",

  updateEmail(newEmail) {
    this.email = newEmail;
  }
};

Then another user.

And another.

Soon, we're repeating the same structure everywhere.

The First Problem: Repetition

The problem isn't creating one object.

The problem is creating hundreds of similar objects.

We don't want to keep rewriting:

{
  name,
  email,

  updateEmail() {
    ...
  }
}

over and over again.

We need a way to create objects consistently.

This is where factory functions come in.

Factory Functions

A factory function is simply a function whose job is to create and return objects.

function createUser(name, email) {
  return {
    name,
    email,

    updateEmail(newEmail) {
      this.email = newEmail;
    }
  };
}

Now creating users becomes easy.

const user1 = createUser("Ashay", "ashay@gmail.com");
const user2 = createUser("Rahul", "rahul@gmail.com");

Instead of manually constructing objects every time, we have a single place responsible for creating them.

Why Developers Loved Factory Functions

At this point many developers thought:

This is great. Why do I need anything more?

And honestly, for many situations, you don't.

Factory functions provide several benefits naturally.

Object creation becomes consistent.

Every user now has the same structure.

No accidental missing fields.

No forgotten methods.

The factory handles everything.

We Can Hide Internal Details

Imagine building a counter.

We don't want other parts of the app directly changing the count.

Without a factory:

const counter = {
  count: 0
};

Anyone can do:

counter.count = 1000;

Maybe that's not what we want.

With a factory:

function createCounter() {
  let count = 0;

  return {
    increment() {
      count++;
    },

    getValue() {
      return count;
    }
  };
}

Now the internal state is protected.

counter.count = 1000;

doesn't affect the actual value.

This was one of the biggest strengths of factory functions.

So Why Were Classes Introduced?

At this point factory functions seem pretty good.

They reduce repetition.

They create objects.

They can even hide internal state.

So why introduce classes?

Because developers encountered a different problem.

Not object creation.

Object organization.

Imagine a large e-commerce system.

You have:

Products
Orders
Customers
Payments
Discounts
Shipments

Suddenly, there are dozens of related entities interacting with each other.

Developers wanted a standardized way to describe:

What a Product is
What an Order is
What behaviors they have
How they relate to one another

Classes provided a structured blueprint for doing this.

The Important Realization

The interesting thing is that classes and factory functions are not enemies.

They're trying to solve similar problems from different angles.

Factory Functions answer:

How can I create objects consistently?

Classes answer:

How can I model and organize complex object-oriented systems?

Both create objects.
Both can be useful.
Both have trade-offs.

Understanding those trade-offs is far more important than blindly choosing one over the other.

What Should You Use?

For small and medium-sized object creation needs, factory functions are often wonderfully simple.

For larger systems with complex relationships, many teams prefer classes because they provide a more familiar structure.

The right choice depends on the problem you're solving.

And that's a recurring theme you'll see throughout this series:

Good software design is rarely about choosing the "best" solution.

It's about understanding the problem and choosing the most appropriate trade-off.

⏭️ What's Next?

Now that we've explored different ways of creating objects, we can return to Object-Oriented Programming itself.

In the next article, we'll start exploring the first major OOP principle: Encapsulation.

We'll look at the problems that arise when an object's internal state can be modified freely and how Encapsulation attempts to solve them.

Why Object-Oriented Programming Was Introduced - Objects and Classes

Ashay Tiwari — Tue, 09 Jun 2026 08:27:38 +0000

In the previous article, we examined the importance of software design, and how all software engineering principles have been defined to address issues rather than creating more complexity.

In this article, we will begin with one of the most significant programming paradigms known as Object Oriented Programming (OOP).

But before moving into definitions, let us examine the issue first.

🤯 The Problem

Imagine you are building a user system.

Without OOP:

const user1Name = "Ashay";
const user1Email = "ashay@gmail.com";

function loginUser1() {}
function logoutUser1() {}

Now imagine:

10 users
100 users
admins
customers
sellers

Everything becomes:

duplicated
disconnected
hard to manage

You have:

data scattered everywhere
behavior scattered everywhere

This is the core problem OOP tries to solve.

🧠 The Core Idea of OOP

OOP says:

"A real-world entity should keep its own data and behavior together."

Example:

A User should contain:

its own properties (name, email)
its own capabilities (login, logout)

That combination becomes an object.

✨ What is an Object REALLY?

An object is:

A self-contained unit of state + behavior.

State = data
Behavior = actions/functions

Example:

const user = {
  name: "Ashay",
  email: "ashay@gmail.com",

  login() {
    console.log(`${this.name} logged in`);
  }
};

Here:

Part	Meaning
name/email	state
login()	behavior
combined together	object

This is the true meaning of an object.

Then Why Do We Need Classes?

Now imagine creating 10,000 users.

You DON'T want:

const user1 = { ... }
const user2 = { ... }
const user3 = { ... }

You need a reusable structure.
That reusable structure is a class.

What is a Class REALLY?

A class is:

A factory/template that defines what an object should contain.

Example:

class User {
  name: string;
  email: string;

  constructor(name: string, email: string) {
    this.name = name;
    this.email = email;
  }

  login() {
    console.log(`${this.name} logged in`);
  }
}

Now you can create objects easily:

const user1 = new User("Ashay","a@gmail.com");
const user2 = new User("Rahul","r@gmail.com");

Deep Understanding of `new`

This is VERY important.

When you do:

const user1 = new User(...)

new does several things internally:

Creates empty object {}
Connects object to class prototype
Binds this to new object
Runs the constructor
Returns object

💡 Important Mental Model

A class is NOT the actual thing.

It is only:

definition
structure
contract

The object is the real runtime entity.

Example:

Real World	OOP
Building map	Class
Actual house	Object
Human DNA structure	Class
Actual person	Object

Common Beginner Mistake

People think:

class User {}

means “doing OOP”.

No.

Real OOP begins when you think:

What responsibility belongs here?
What data should this object own?
What should be hidden?
How should objects communicate?
Who controls what?

That leads to:

Encapsulation
Abstraction
Polymorphism
Dependency Injection
SOLID principles

which we’ll cover one by one.

⏭️ What's Next?

Now that we understand what OOP is and how classes and objects help organize state and behavior, an interesting question naturally arises especially for JavaScript developers.

If JavaScript already allows us to create objects using plain object literals and factory functions, why do we need classes at all?

Are classes simply syntactic sugar, or do they solve a different set of problems?

Before we dive into the core principles of OOP such as Encapsulation, Abstraction, Inheritance, and Polymorphism, we'll take a small detour to explore one of the most common debates in the JavaScript ecosystem:

Factory Functions vs Classes

We'll compare both approaches, understand their trade-offs, and discuss when each one makes sense in real-world applications.

Because before learning how to design good objects, it's worth understanding the different ways we can create them.

Understanding The "Why" Behind Software Design: Introduction

Ashay Tiwari — Mon, 08 Jun 2026 07:04:46 +0000

✨ Why Software Design Matters

If you've been developing software for a while, you've probably come across terms like:

Object-Oriented Programming (OOP)
Encapsulation
Abstraction
Inheritance
Polymorphism
SOLID Principles
Dependency Injection
Design Patterns

There are countless articles, videos, and courses explaining these concepts.

Still, there are plenty of developers, including me, who learn those concepts and forget them very quickly.

We memorize definitions.

We learn syntax.

We understand enough to answer interview questions.

But we rarely stop and ask:

Why were these concepts introduced in the first place?

That realization is the reason I'm starting this series.

🧐 The Problem With How We Learn Software Design

When I first learned OOP, I learned things like:

Encapsulation is data hiding.
Inheritance allows code reuse.
Polymorphism means many forms.
Abstraction hides implementation details.

The definitions were easy enough to remember.

The difficult part was understanding when these concepts actually mattered.

If someone asked:

Why is inheritance considered risky in some situations?
Why do people say composition is often better?
Why was the SOLID principle created?
Why do modern frameworks rely heavily on Dependency Injection?

I could explain the concepts individually, but I couldn't always explain the problems they were trying to solve.

Over time, I realized that software design concepts are much easier to understand when viewed from a different perspective.

Instead of asking:

"What is this concept?"

Ask:

"What problem were developers facing that made this concept necessary?"

Once you understand the problem, the solution becomes much more intuitive.

🛠️ Why Software Design Matters

When we start learning programming, most applications are small.

A few functions.

A few variables.

A few files.

Everything feels manageable.

As projects grow, something interesting happens.

The challenge is no longer writing code.

The challenge becomes managing code.

Features are added.

Requirements change.

Teams grow.

Business logic becomes more complex.

Code that once felt simple starts becoming difficult to understand and modify.

At some point, developers begin encountering questions like:

Why is this logic duplicated in multiple places?
Why does changing one feature break another?
Why is this class responsible for so many things?
Why is testing this code so difficult?
Why does every new feature require modifying existing code?

The software still works.

But it becomes harder to maintain.

Harder to extend.

Harder to reason about.

This is where software design becomes important.

Software design is not about making code look clever.

It's about organizing code in a way that allows systems to evolve without becoming unmanageable.

Most of the concepts we'll discuss throughout this series were created to solve exactly these kinds of problems.

❓ What This Series Is About

This series is not going to focus on memorizing definitions.

Instead, we'll focus on understanding:

What problem exists?
Why the straightforward solution eventually breaks down?
What concept was introduced to solve it?
What trade-offs come with that solution?

We'll use JavaScript and TypeScript examples because that's what I work with most often, but the concepts themselves apply regardless of programming language.

Whether you're writing Java, C#, Python, Go, JavaScript, or something else entirely, the underlying design principles remain largely the same.

↔️ A Small Shift in Perspective

Throughout this series, I'd encourage you to think about concepts differently.

Instead of learning:

"Encapsulation is data hiding."

Think:

"What problems occur when every part of the system can freely modify an object's state?"

Instead of learning:

"Dependency Injection helps decouple code."

Think:

"Why does directly creating dependencies become painful as applications grow?"

The answers to those questions are often more valuable than the definitions themselves.

⏭️ What's Next?

In the next article, we'll begin with Object-Oriented Programming itself.

Not by starting with classes and syntax.

But by understanding the problems developers were facing before OOP became one of the most influential programming paradigms in software development.

Tunneling Made Simple: Exposing Local React and Node Apps with ngrok and LocalTunnel

Ashay Tiwari — Thu, 01 May 2025 20:09:17 +0000

✨ Introduction

Ever wanted to test your local web app on your phone? Share a work-in-progress with a client? Or receive webhooks from services like Stripe or GitHub?

This blog post is your complete guide to securely exposing local development servers to the internet — whether it's a React.js frontend or a Node.js REST API backend.

We’ll explore two popular tools:

🔗 LocalTunnel – simple and open-source
🚀 ngrok – powerful with an interactive dashboard and HTTPS support

🔍 What You’ll Learn

In this guide, you’ll:

Understand the concept and use cases of local tunneling
Set up a basic Node.js REST API and React.js app
Expose both apps securely using LocalTunnel and ngrok
Learn the pros/cons of each tool

🛠️ Project Setup (React + Node)

1️⃣ Node.js REST API

Steps to create a basic Express API:

mkdir backend-app
cd backend-app
npm init -y
npm install express

Create server.js:

const express = require('express');
const app = express();
const PORT = 8000;

app.get('/api/greet', (req, res) => {
  res.json({ message: 'Hello from Backend-App' });
});

app.listen(PORT, () => {
  console.log(`API running at http://localhost:${PORT}`);
});

Run it:

node server.js

2️⃣ React.js Frontend App

Using Create React App:

npx create-react-app frontend-app
cd frontend
npm start

Or, Using Vite (faster):

npm create vite@latest frontend-app -- --template react
cd frontend
npm install
npm run dev

Update App.js as:

import React from 'react';

function App() {

  return <h1>Hello from Frontend-App</h1>;
}

export default App;

🌐 What is a Tunneling System?

When you're developing locally (e.g., http://localhost:3000 or http://127.0.0.1:8000), your apps are only accessible on your machine. If you want someone else — a client, teammate, or even a third-party API like Stripe — to access your local project, you need to expose it to the internet.

That’s where tunneling tools come in.

A tunneling system creates a secure "bridge" between your local server and a public URL that anyone can access — even from outside your network.

Imagine it like building a secure pipe from your computer to the outside world. You don't have to deploy to a remote server or set up complex networking — just run a single command and you're live!

🚀 Setting Up ngrok to Tunnel Your Local React and Node.js Apps

Let’s now walk through how to use ngrok to expose both your local backend and frontend to the internet.

🔧 Step 1: Install ngrok
You can install ngrok globally via npm or download it from the official website.

Option 1 – Install via npm:

npm install -g ngrok

Option 2 – Download from website:

Go to https://ngrok.com/download
Download and unzip the binary
Move it to a directory in your system’s PATH

🔐 Step 2: Sign up and authenticate ngrok (Optional but recommended)

If you're using a free ngrok account, you should sign up and connect your account to unlock features like custom subdomains and higher session limits.

Sign up at https://dashboard.ngrok.com
Copy your authtoken from the dashboard
Run the command:

ngrok config add-authtoken <your-token-here>

Make sure your node and react servers are running locally.

🌍 Step 3: Expose your servers with ngrok

⚠️ Note: ngrok Free Plan supports only one active tunnel at a time. If you want to expose both the React app and Node API simultaneously, you’ll need a Pro plan or use a different tunneling tool for one of them (e.g., LocalTunnel).

Tunnel the Node.js API (port 8000):

ngrok http 8000

You’ll get an output like:

Forwarding     https://1e3f-106-219-85-57.ngrok-free.app -> http://localhost:8000

You can now access your API from this public URL.

Tunnel the React frontend (port 3000):
If you want to expose the React app instead:

ngrok http 3000

And again, ngrok will provide a public HTTPS URL like:

Forwarding     https://6g4f-105-221-92-12.ngrok-free.app -> http://localhost:3000

🚀 Setting Up LocalTunnel for your React and Node.js Application

After covering ngrok, let’s explore another tunneling tool: LocalTunnel — a free and open-source option that lets you share your local development environment via a public URL.

Unlike ngrok, LocalTunnel does not require an account and allows multiple tunnels simultaneously (each on different ports and subdomains).

🔧 Step 1: Install LocalTunnel

Install it globally via npm:

npm install -g localtunnel

Make sure your node and react servers are running locally.

🌍 Step 2: Expose your servers with LocalTunnel

You can create tunnels for both apps using unique ports and optional subdomains.
Tunnel the Node.js API:

lt --port 8000 --subdomain my-node-api

This creates a URL like:

https://my-node-api.loca.lt

Tunnel the React frontend:

lt --port 3000 --subdomain my-react-app

This creates a URL like:

https://my-react-app.loca.lt

⚠️ Subdomains are first-come-first-served, and not guaranteed. If someone else is already using the same subdomain, you’ll get an error. If you omit --subdomain, a random one is generated.

🔁 Realtime Code Changes

LocalTunnel reflects real-time changes, just like ngrok, since it directly proxies your local server. You can continue editing your React or Node app, and the changes are reflected via the public tunnel.

🎉 That’s It!

You’ve now exposed your local apps to the world using ngrok or LocalTunnel. You can share those URLs with clients, test on your phone, or integrate with third-party services that need a public endpoint.

🆚 Comparison: ngrok vs. LocalTunnel

Feature	ngrok (Free Tier)	LocalTunnel
🧰 Installation	`npm install -g ngrok` or native binary	`npm install -g localtunnel`
🔐 Account Required	✅ Yes (for custom subdomains, dashboard access)	❌ No
🔄 Supports Multiple Tunnels	❌ No (only 1 active tunnel at a time)	✅ Yes (multiple tunnels allowed)
🌐 Custom Subdomain	✅ Yes (only with account)	✅ Yes (but not always guaranteed)
🔐 HTTPS Support	✅ Yes (by default)	✅ Yes (by default)
🌍 URL Format	`https://<random>.ngrok-free.app`	`https://<random or subdomain>.loca.lt`
🧑‍💻 Dashboard & Inspect Traffic	✅ Yes (Web dashboard & HTTP request inspector)	❌ No built-in dashboard
💻 Real-time Code Updates	✅ Yes (reflects local changes)	✅ Yes (reflects local changes)
🕐 Session Duration	~8 hours (free account), reconnect needed	Until you manually close the tunnel
📦 Open Source	❌ Proprietary	✅ Yes
💰 Pricing	Free & paid tiers	Fully free
🌐 Use Case Fit	Best for professional demos, webhooks, integrations	Best for quick testing, sharing with teammates

🎯 Conclusion

In this post, we explored how tunneling tools like ngrok and LocalTunnel help developers expose their local applications to the internet. ngrok offers advanced features like custom subdomains and request inspection, making it ideal for professional use, while LocalTunnel is a simpler, free alternative perfect for quick sharing and testing. Both tools provide a secure and real-time connection to your local environment, so you can choose the one that best fits your needs.

Happy coding! 🚀

DEV Community: Ashay Tiwari

Inheritance in OOP: Solving Code Duplication or Creating New Problems?

❓ Why Was Inheritance Invented?

What Does extends Actually Do?

Overriding Methods

🤯 The Biggest Mistake with Inheritance

⚔️ The Double-Edged Sword

✅ When Inheritance Is Actually Good

1. Real IS-A relationship exists

2. Parent behavior is truly shared

3. Hierarchy is shallow

⏭️ What's Next?

Abstraction in OOP: Hiding Complexity Without Hiding Capability

The Problem

A Real-World Example

The Problem with Exposing Everything

The Idea Behind Abstraction

Abstraction Is Not the Same as Encapsulation

What's Next?

Encapsulation in OOP: Protecting an Object's State from Unintended Changes

The Real Problem Encapsulation Solves

Encapsulation is NOT About Hiding

Why This Becomes Dangerous

A Better Design

Think Like a Security Guard

The Idea Behind Encapsulation

Encapsulation in TypeScript

Important Reality About TypeScript

The Key Takeaway

What's Next?

Factory Functions vs Classes: If Classes Exist, Why Do We Still Use Factory Functions?

❓ A Question That Confused Me

The Simplest Possible Approach

The First Problem: Repetition

Factory Functions

Why Developers Loved Factory Functions

We Can Hide Internal Details

So Why Were Classes Introduced?

What Should You Use?

⏭️ What's Next?

Why Object-Oriented Programming Was Introduced - Objects and Classes

🤯 The Problem

🧠 The Core Idea of OOP

✨ What is an Object REALLY?

Then Why Do We Need Classes?

What is a Class REALLY?

Deep Understanding of new

💡 Important Mental Model

Common Beginner Mistake

⏭️ What's Next?

Understanding The "Why" Behind Software Design: Introduction

✨ Why Software Design Matters

🧐 The Problem With How We Learn Software Design

🛠️ Why Software Design Matters

❓ What This Series Is About

↔️ A Small Shift in Perspective

⏭️ What's Next?

Tunneling Made Simple: Exposing Local React and Node Apps with ngrok and LocalTunnel

✨ Introduction

🔍 What You’ll Learn

🛠️ Project Setup (React + Node)

🌐 What is a Tunneling System?

🚀 Setting Up ngrok to Tunnel Your Local React and Node.js Apps

🚀 Setting Up LocalTunnel for your React and Node.js Application

🎉 That’s It!

🆚 Comparison: ngrok vs. LocalTunnel

🎯 Conclusion

What Does `extends` Actually Do?

Deep Understanding of `new`