DEV Community: HARSHITH GADDAM

SQL and Database Fundamentals: From Tables to Transactions and Indexes

HARSHITH GADDAM — Fri, 09 Oct 2026 09:48:22 +0000

SQL and Database Fundamentals: From Tables to Transactions and Indexes

When I started learning databases, I realized that writing SQL queries
is only one part of working with a database. To work with data properly,
we also need to understand how tables are designed, how they are
connected, how duplicate data can be avoided, and how database
operations are kept safe.

In this blog, I am explaining the database concepts I have learned, with
simple examples and SQL queries.

We will cover:

Tables, primary keys, and foreign keys
Relationships between tables
SQL joins: implicit joins vs. explicit joins, INNER/LEFT/RIGHT/FULL
Aggregation functions
Normalization: 1NF, 2NF, 3NF, BCNF, 4NF, and 5NF
Transactions: BEGIN, COMMIT, and ROLLBACK
Primary, unique, and composite indexes
Understanding EXPLAIN

Let's start with the basics.

1. Tables: How Databases Store Data

A relational database stores data in tables. A table contains rows and
columns.

For example, imagine we are building an online shopping application.

We can create a table to store customer information.

CREATE TABLE customers (
    customer_id INT PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(150)
);

Now, let's insert some data.

INSERT INTO customers (customer_id, name, email)
VALUES
    (1, 'Rahul', 'rahul@example.com'),
    (2, 'Priya', 'priya@example.com'),
    (3, 'Arun', 'arun@example.com');

The table now looks like this:

customer_id name email

1 Rahul rahul@example.com
2 Priya priya@example.com
3 Arun arun@example.com

Here:

Table: customers
Columns: customer_id, name, and email
Rows: Individual customer records

We can retrieve the data using:

SELECT * FROM customers;

The * means we want to retrieve all columns.

What I understood: Tables organize related information into rows and
columns, making it easier to store, retrieve, and manage data.

2. Primary Keys and Foreign Keys

When a database contains many tables, we need a way to identify
individual records and connect related records.

This is where primary keys and foreign keys become important.

Primary Key (PK)

A primary key uniquely identifies each row in a table.

For example:

CREATE TABLE products (
    product_id INT PRIMARY KEY,
    product_name VARCHAR(100),
    price NUMERIC(10, 2)
);

Here, product_id is the primary key.

It ensures that: - Every product has a unique ID. - The ID cannot be
NULL. - Two products cannot have the same ID.

For example, we cannot insert two products with product_id = 101.

A table has only one primary key constraint, but that key can contain
multiple columns. We will see this later.

Foreign Key (FK)

A foreign key connects one table to another by referencing a primary key
or another eligible unique key.

Let's create an orders table.

CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    order_date DATE,
    FOREIGN KEY (customer_id)
        REFERENCES customers(customer_id)
);

Here, customer_id is a foreign key.

Suppose we insert an order for customer ID 1. It works because
customer 1 exists in the customers table.

However, an order for customer ID 99 will fail if customer 99 does
not exist.

The foreign key protects the relationship between the tables.

Important difference:

Primary key Foreign key

Identifies a row uniquely Connects related records

Cannot contain NULL Can contain NULL unless
restricted

Must be unique Can contain duplicate values

One primary key constraint per A table can have multiple foreign
table keys

What I understood: A primary key identifies a record, while a
foreign key helps maintain valid relationships between records.

3. Relationships Between Tables

In real applications, data is divided into multiple tables because
different types of information have different purposes.

There are three common types of relationships.

3.1 One-to-One (1:1)

One record in the first table is associated with at most one record in
the second table, and vice versa.

Example: A user and their profile.

CREATE TABLE user_profiles (
    profile_id INT PRIMARY KEY,
    customer_id INT UNIQUE
        REFERENCES customers(customer_id),
    bio TEXT
);

The UNIQUE constraint on customer_id prevents the same customer from
having multiple profile records.

For example:

Customer 1 → Profile 101
Customer 2 → Profile 102

A customer can have no profile or one profile. The UNIQUE constraint
ensures that a customer cannot be linked to multiple profiles through
this column.

3.2 One-to-Many (1:N)

One record in the first table can be associated with many records in the
second table.

Example: One customer can place many orders.

customers
---------
customer_id: 1
name: Rahul

orders
------
order_id: 101, customer_id: 1
order_id: 102, customer_id: 1
order_id: 103, customer_id: 1

Customer Rahul has placed three orders.

We implement this relationship by placing the foreign key in the
orders table.

customer_id INT REFERENCES customers(customer_id)

The foreign key can repeat because many orders can belong to the same
customer.

3.3 Many-to-Many (N:N)

Many records in one table can be associated with many records in another
table.

Example: Students and courses.

One student can enroll in many courses.
One course can have many students.

We use a junction table to represent this relationship.

CREATE TABLE students (
    student_id INT PRIMARY KEY,
    student_name VARCHAR(100)
);

CREATE TABLE courses (
    course_id INT PRIMARY KEY,
    course_name VARCHAR(100)
);

CREATE TABLE enrollments (
    student_id INT REFERENCES students(student_id),
    course_id INT REFERENCES courses(course_id),
    PRIMARY KEY (student_id, course_id)
);

The enrollments table connects students and courses.

student_id course_id

1 101
1 102
2 101

Student 1 is enrolled in two courses, while course 101 has two students.

The composite primary key prevents the same student from being enrolled
in the same course more than once.

What I understood: A 1:1 relationship often uses a foreign key with
a unique constraint, a 1:N relationship uses a foreign key on the many
side, and an N:N relationship uses a junction table.

4. SQL Joins: Implicit and Explicit Joins

We often store related information in separate tables. A JOIN lets us
retrieve related data from multiple tables in one query.

In SQL, explicit and implicit joins are two different syntactical styles used to combine data from two or more tables based on a related column. Both produce the exact same query result and execution plan in modern database engines, but they differ in readability, maintenance, and standards.

Let's use our customers and orders tables.

4.1 Implicit JOIN

An implicit join uses a comma to list tables in the FROM clause. The
matching condition is written in the WHERE clause.

SELECT
    customers.name,
    orders.order_id,
    orders.order_date
FROM customers, orders
WHERE customers.customer_id = orders.customer_id;

The condition customers.customer_id = orders.customer_id tells SQL
which customer matches each order.

This query returns matching customer-order rows, similar to an
INNER JOIN.

What can go wrong? If we forget the matching condition, the database
combines every customer with every order. This is called a Cartesian
product. For example, 3 customers and 10 orders can produce 30 rows,
even when most of those pairs are unrelated.

Implicit join syntax is older and can become difficult to read when a
query uses several tables and conditions.

4.2 Explicit JOIN

An explicit join uses the JOIN keyword and puts the matching condition
next to the tables being joined.

SELECT
    customers.name,
    orders.order_id,
    orders.order_date
FROM customers
INNER JOIN orders
    ON customers.customer_id = orders.customer_id;

This query produces the same matching rows as the previous implicit
join.

Here: - INNER JOIN says that we want matching rows. - ON defines how
the two tables are related.

Why do we prefer explicit JOINs?

Both forms can express an inner join, but explicit joins are usually
better because:

They are easier to read. The relationship between tables is written directly beside the JOIN.
They reduce mistakes. Join conditions are kept separate from other filters, so it is easier to notice a missing condition.
They support outer joins clearly. LEFT JOIN, RIGHT JOIN, and FULL OUTER JOIN are expressed naturally with explicit syntax.
They are easier to maintain. When a query contains several tables, the join logic is easier to follow.

Explicit joins do not automatically make a query faster. The database
optimizer may produce the same execution plan for equivalent queries.
The main benefits are clarity and safer query writing.

4.3 INNER JOIN

An INNER JOIN returns only rows that match in both tables.

SELECT customers.name, orders.order_id
FROM customers
INNER JOIN orders
    ON customers.customer_id = orders.customer_id;

If Rahul has two orders and Priya has one order, the result contains
three rows. If Arun has no orders, Arun does not appear.

4.4 LEFT JOIN

A LEFT JOIN returns every row from the left table and matching rows
from the right table. If there is no match, the right-side columns
contain NULL.

SELECT customers.name, orders.order_id
FROM customers
LEFT JOIN orders
    ON customers.customer_id = orders.customer_id;

Now Arun appears even if he has no orders. His order_id is NULL.

This is useful when we want to find all customers, including those who
have never placed an order.

4.5 RIGHT JOIN

A RIGHT JOIN returns every row from the right table and matching rows
from the left table.

SELECT customers.name, orders.order_id
FROM customers
RIGHT JOIN orders
    ON customers.customer_id = orders.customer_id;

Every order appears, along with its matching customer information. In
this example, the foreign key means every non-null customer ID in
orders must refer to an existing customer.

A RIGHT JOIN can often be rewritten as a LEFT JOIN by switching the
table order.

4.6 FULL OUTER JOIN

A FULL OUTER JOIN returns matching rows, unmatched rows from the left
table, and unmatched rows from the right table.

SELECT customers.name, orders.order_id
FROM customers
FULL OUTER JOIN orders
    ON customers.customer_id = orders.customer_id;

This is useful when we want to see all records from both tables, even
when a matching record does not exist.

Quick comparison

Join What it returns

Implicit join Older comma-separated syntax;
matching conditions are usually in
WHERE

INNER JOIN Only matching rows

LEFT JOIN All left rows and matching right
rows

RIGHT JOIN All right rows and matching left
rows

FULL OUTER JOIN All rows from both sides

What I understood: Implicit and explicit syntax can produce the same
result for an inner join, but explicit joins make the relationship
clearer and are easier to maintain. The type of join determines what
happens to rows that have no match.

5. Aggregation Functions

Sometimes, retrieving individual rows is not enough. We may want to
calculate totals, averages, or counts.

SQL provides aggregate functions for this purpose.

The most common ones are:

COUNT() --- counts rows or non-null values, depending on the expression.
SUM() --- calculates a total.
AVG() --- calculates an average.
MIN() --- finds the smallest value.
MAX() --- finds the largest value.

Suppose we have these orders:

order_id customer_id total_amount

101 1 500
102 1 300
103 2 700

Count the orders

SELECT COUNT(*) AS total_orders
FROM orders;

Result: 3

Calculate total sales

SELECT SUM(total_amount) AS total_sales
FROM orders;

This requires a total_amount column in the orders table. If we add
that column and use the values above, the result is 1500.

Calculate average order value

SELECT AVG(total_amount) AS average_order_value
FROM orders;

The result is 500.

GROUP BY

GROUP BY groups rows with the same value so that we can calculate a
separate result for each group.

For example, we want to know how much each customer has spent.

SELECT
    customer_id,
    SUM(total_amount) AS total_spent
FROM orders
GROUP BY customer_id;

Result:

customer_id total_spent

1 800
2 700

Instead of calculating one total for all orders, SQL calculates a
separate total for each customer.

HAVING

HAVING filters groups after aggregation.

SELECT
    customer_id,
    SUM(total_amount) AS total_spent
FROM orders
GROUP BY customer_id
HAVING SUM(total_amount) > 600;

This returns only customers whose total spending is greater than 600.

What I understood: Aggregate functions calculate summary values,
GROUP BY creates groups, and HAVING filters those groups based on
aggregate results.

6. Database Normalization: 1NF, 2NF, 3NF, BCNF, 4NF, and 5NF

Normalization is the process of organizing data into tables to reduce
unnecessary duplication and avoid data problems.

Imagine storing customer information and all their orders in one table.
Rahul's name may be repeated for every order. If his name changes, we
must update several rows. If we update only some of them, the data
becomes inconsistent.

Normalization helps us place each fact in the right table. Let's go
through the normal forms one by one.

6.1 First Normal Form (1NF)

A table is in First Normal Form when each cell contains a single value
rather than a list of values, and rows can be identified individually.

Consider this table:

student_id student_name courses

1 Rahul Java, SQL
2 Priya Python, Java

The courses column contains multiple values in one cell.

We can instead store one student-course combination per row:

student_id student_name course

1 Rahul Java
1 Rahul SQL
2 Priya Python
2 Priya Java

Now each cell contains one value. In a real application, we would
usually separate students and courses into their own tables and connect
them with an enrollment table.

Main idea: Each cell should contain one value, not a list of
separate values.

6.2 Second Normal Form (2NF)

A table is in 2NF when: 1. It is already in 1NF. 2. Every non-key column
depends on the whole of every candidate key, not just part of a
composite key.

Consider this table, where the primary key is (student_id, course_id):

student_id course_id student_name course_name

1 101 Rahul SQL
1 102 Rahul Java
2 101 Priya SQL

student_name depends only on student_id, and course_name depends
only on course_id. Neither depends on the full two-column key. These
are partial dependencies.

We can split the data into three tables:

Students

student_id student_name

1 Rahul
2 Priya

Courses

course_id course_name

101 SQL
102 Java

Enrollments

student_id course_id

1 101
1 102
2 101

Now student details belong in students, course details belong in
courses, and enrollment records use the combination of both IDs.

Main idea: If a candidate key contains multiple columns, non-key
facts should not depend on only part of that key.

6.3 Third Normal Form (3NF)

A table is in 3NF when it is in 2NF and non-key attributes do not depend
transitively on a candidate key. More precisely, for every non-trivial
functional dependency X → A, either X is a superkey or A is a
prime attribute (an attribute that belongs to at least one candidate
key).

Consider this table:

employee_id employee_name department_id department_name

1 Rahul 10 Engineering
2 Priya 10 Engineering
3 Arun 20 Marketing

Assume employee_id is the key and each department ID determines one
department name.

employee_id determines department_id.
department_id determines department_name.

So, the department name depends on the employee ID indirectly through
department_id. This is a transitive dependency.

We can split the data into:

Employees

employee_id employee_name department_id

1 Rahul 10
2 Priya 10
3 Arun 20

Departments

department_id department_name

10 Engineering
20 Marketing

Now the department name is stored once in the departments table.

Main idea: Avoid storing facts about one entity repeatedly in a
table mainly about another entity.

6.4 Boyce-Codd Normal Form (BCNF)

BCNF is a stronger version of 3NF. A table is in BCNF when, for every
non-trivial functional dependency X → Y, X must be a superkey.

In simple words, every column or group of columns that determines
another fact must be able to identify a row uniquely.

Consider a table with these columns:

Student, Course, Instructor

Assume: - A student can study a course with an instructor. - Each
instructor teaches only one course. - A student can have more than one
instructor.

The important dependency is:

Instructor → Course

The instructor determines the course, but Instructor alone does not
identify a student-instructor row because many students can have the
same instructor. So the determinant is not a superkey, and the table
violates BCNF.

We can separate the facts into tables such as:

InstructorCourses

instructor course

I1 SQL
I2 Java

StudentInstructors

student instructor

Rahul I1
Priya I1
Rahul I2

This stores which course an instructor teaches separately from which
instructor teaches a student.

Main idea: In BCNF, every determinant must be a superkey. BCNF
handles some dependency problems that 3NF can still allow.

6.5 Fourth Normal Form (4NF)

4NF deals with a different problem: independent multi-valued facts in
the same table.

Imagine a student can have several hobbies and speak several languages.
Assume hobbies and languages are independent of each other.

A single table might look like this:

student hobby language

Rahul Cricket English
Rahul Cricket Telugu
Rahul Music English
Rahul Music Telugu

Every hobby is repeated for every language. Every language is repeated
for every hobby. If Rahul adds a hobby, we may need to add a row for
each language.

We can separate these independent facts into two tables.

StudentHobbies

student hobby

Rahul Cricket
Rahul Music

StudentLanguages

student language

Rahul English
Rahul Telugu

A table is in 4NF when it is in BCNF and has no non-trivial multivalued
dependency unless its determinant is a superkey.

Main idea: Keep independent multi-valued facts in separate tables
instead of storing every possible combination.

6.6 Fifth Normal Form (5NF)

5NF deals with join dependencies. It helps when a table can be split
into smaller tables and reconstructed exactly by joining them, without
creating incorrect combinations.

Imagine a business records which suppliers provide which parts for which
projects. The table has three columns:

Supplier, Part, Project

In some systems, the business rules may mean that a valid
supplier-part-project combination can be determined entirely from three
pairwise relationships:

Which parts a supplier can provide
Which projects a supplier works on
Which parts a project uses

If---and only if---the business rules guarantee that these pairwise
relationships are enough to determine every valid three-way combination,
we can store them in three tables:

SupplierParts(Supplier, Part)
SupplierProjects(Supplier, Project)
ProjectParts(Project, Part)

Joining the three tables can reconstruct the original combinations
without adding invalid combinations.

This decomposition is not safe for every supplier-part-project dataset.
It is valid only when the required join dependency holds.

A table is in 5NF (also called Project-Join Normal Form) when every
non-trivial join dependency is implied by its candidate keys.

Main idea: 5NF handles cases where a table can be split into smaller
relationship tables and joined back together without losing information
or creating extra rows.

Quick comparison of normal forms

Normal form Main idea

1NF Each cell contains a single value

2NF No partial dependency on part of a
candidate key

3NF No disallowed transitive dependency
of non-key attributes

BCNF Every determinant in a non-trivial
functional dependency is a superkey

4NF No non-trivial multivalued
dependency unless its determinant
is a superkey

5NF No non-trivial join dependency
remains except those implied by
candidate keys

In practice, 1NF through 3NF are common starting points for relational
database design. BCNF, 4NF, and 5NF address more specific dependency
problems. The right design depends on the real business rules; splitting
tables without understanding those rules can cause incorrect results
when the tables are joined again.

What I understood: Normalization is about understanding which facts
depend on which keys or relationships, then organizing tables so that
each fact is stored in the right place with less unnecessary repetition.

7. Transactions: BEGIN, COMMIT, and ROLLBACK

A transaction is a group of database operations treated as one unit of
work.

Consider a bank transfer.

Rahul transfers ₹500 to Priya.

Two operations are required:

Subtract ₹500 from Rahul's account.
Add ₹500 to Priya's account.

What happens if the first operation succeeds but the second fails?

Money would be deducted from Rahul without being added to Priya.

A transaction helps prevent this partial update.

BEGIN

BEGIN starts a transaction.

COMMIT

COMMIT saves the transaction's changes permanently.

ROLLBACK

ROLLBACK cancels the uncommitted changes made by the current
transaction.

Let's implement the bank transfer.

Assume an accounts table with account_id and balance columns
already exists.

BEGIN;

UPDATE accounts
SET balance = balance - 500
WHERE account_id = 1;

UPDATE accounts
SET balance = balance + 500
WHERE account_id = 2;

COMMIT;

If both operations succeed and the transaction commits, the transfer is
saved.

Now suppose we detect an error before committing.

BEGIN;

UPDATE accounts
SET balance = balance - 500
WHERE account_id = 1;

-- An error is detected before the transfer is completed.

ROLLBACK;

The uncommitted balance change is undone.

In a real banking system, we would also validate the account IDs, check
that the sender has enough money, and handle failures correctly. A
database transaction alone does not automatically enforce all business
rules.

Important: ROLLBACK cannot normally undo a transaction after it
has been committed.

ACID properties

Transactions are commonly explained using ACID.

Atomicity: Either all required changes happen, or none do.
Consistency: The transaction preserves the database's defined rules and constraints.
Isolation: Concurrent transactions are controlled so they do not interfere in unacceptable ways.
Durability: Once committed, changes survive normal failures covered by the database's durability guarantees.

What I understood: Transactions protect related database operations
from being saved only partially. BEGIN starts the work, COMMIT saves
it, and ROLLBACK cancels uncommitted changes.

8. Indexes: Primary, Unique, and Composite

An index is a data structure that helps a database find rows without
scanning the entire table in many situations.

Think of a book's index. Instead of reading every page to find a topic,
you can use the index to locate the relevant pages.

Database indexes work in a similar way.

However, indexes also require storage and can make INSERT, UPDATE,
and DELETE operations more expensive because the indexes may need to
be updated.

8.1 Primary Key Index

When we create a primary key, PostgreSQL automatically creates a unique
B-tree index to enforce it, unless the constraint is implemented using
an already-existing suitable index.

CREATE TABLE products (
    product_id INT PRIMARY KEY,
    product_name VARCHAR(100)
);

PostgreSQL uses the primary key's unique index to enforce uniqueness and
help find products by ID.

We do not need to create another index on product_id for the same
purpose.

8.2 Unique Index

A unique index prevents duplicate indexed key values.

CREATE UNIQUE INDEX idx_customers_email
ON customers(email);

Now, two customers cannot have the same non-null email.

In PostgreSQL, a normal unique index allows multiple NULL values by
default because NULL values are treated as distinct for uniqueness.
Different options can change this behavior.

Difference: A primary key is a table constraint that requires
unique, non-null values. A unique index enforces uniqueness, but it does
not by itself make the column NOT NULL.

A table can have only one primary key constraint, but it can have
multiple unique constraints or unique indexes.

8.3 Composite Index

A composite index contains more than one column.

Suppose we frequently retrieve a customer's orders, sorted by date.

CREATE INDEX idx_orders_customer_date
ON orders(customer_id, order_date);

This index can help queries such as:

SELECT *
FROM orders
WHERE customer_id = 1
ORDER BY order_date;

The order of columns matters.

An index on (customer_id, order_date) is generally most useful when a
query filters or sorts using the leading column, customer_id.

It can also support searches on both columns, but it is not generally as
useful for filtering only by order_date.

For example, a query that filters only by order_date may benefit more
from an index that starts with order_date.

What I understood: Indexes can speed up data retrieval, but we
should create them based on actual query patterns rather than indexing
every column.

9. EXPLAIN: Understanding How SQL Queries Run

We can write a correct SQL query, but that does not mean it will always
run efficiently.

For example:

SELECT *
FROM orders
WHERE customer_id = 1;

If the orders table contains millions of rows, PostgreSQL needs a way
to find the matching orders.

It may choose to scan the whole table or use an index.

How can we understand which approach PostgreSQL chooses?

We can use EXPLAIN.

EXPLAIN
SELECT *
FROM orders
WHERE customer_id = 1;

PostgreSQL displays the query plan it expects to use.

Two common plan operations are:

Sequential Scan

Seq Scan on orders

A sequential scan means PostgreSQL reads the table's rows to find
matching records.

This is not always bad. If the table is small or the query needs a large
part of the table, scanning it can be the most efficient option.

Index Scan

Index Scan using idx_orders_customer_date on orders

An index scan means PostgreSQL uses an index to locate relevant rows.

This can be faster when the query needs only a small portion of a large
table.

The actual plan depends on the table size, data distribution, available
indexes, and the query itself.

EXPLAIN ANALYZE

EXPLAIN shows the planned operations and estimated costs.

EXPLAIN ANALYZE actually executes the query and reports the operations
performed along with execution measurements.

EXPLAIN ANALYZE
SELECT *
FROM orders
WHERE customer_id = 1;

It helps us compare estimated and actual row counts and execution time.

Be careful: EXPLAIN ANALYZE executes the query. For a SELECT, it
runs the read query; for an UPDATE or DELETE, it performs the
change. Use caution with write queries, and use a transaction with
ROLLBACK when appropriate for controlled testing.

What should we look at?

When reading a query plan, pay attention to:

Scan type: Is PostgreSQL using a sequential scan or an index?
Estimated rows vs. actual rows: Are the estimates close to reality?
Execution time: How long did the query take in this run?
Buffers: With EXPLAIN (ANALYZE, BUFFERS), how much data was read from or found in memory?

Do not assume that every sequential scan should be replaced with an
index scan. The goal is to understand why PostgreSQL selected a
particular plan.

What I understood: EXPLAIN helps us understand the planned
execution of a query, while EXPLAIN ANALYZE lets us compare that plan
with actual execution results.

10. Putting Everything Together

Let's connect these concepts to a real application.

Imagine we are developing an online shopping website.

We need to:

Store customer and order information in separate tables.
Use primary keys to identify records.
Use foreign keys to connect orders to customers.
Use joins to retrieve customer details with their orders.
Use aggregation functions to calculate total sales.
Normalize tables to avoid unnecessary duplication.
Use transactions to ensure that related operations succeed or fail together.
Create indexes for frequently used search conditions.
Use EXPLAIN ANALYZE to investigate slow queries.

Each concept solves a different problem, but all of them work together
to make a database reliable and efficient.

For example, when a customer places an order, the application might
validate the request, insert the order and its items inside a
transaction, and update inventory. Foreign keys can protect
relationships, constraints can prevent invalid data, and indexes can
help the application find the necessary records efficiently.

That is why learning database design and query execution is just as
important as learning SQL syntax.

Conclusion

Learning these database concepts helped me understand that databases are
not simply places where we store data. We must also think about how the
data is connected, how it can be retrieved, how duplication can be
avoided, and how changes can be performed safely.

Here are the key lessons I took away:

Tables and keys help us organize and identify data.
Relationships and joins help us connect information across tables.
Aggregations help us summarize data.
Normalization (1NF, 2NF, 3NF, BCNF, 4NF, and 5NF) helps reduce unnecessary duplication and dependency problems.
Transactions protect related operations.
Indexes can improve query performance.
EXPLAIN helps us understand how a database executes queries.

I am continuing to build my understanding of SQL and database design by
practicing these concepts with real examples.

I hope this article helps other beginners understand these topics more
easily.

What about you? Which database concept took you the longest to
understand? Share your experience in the comments!

TypeScript Basics, Jest Mocking, and Git Etiquette

HARSHITH GADDAM — Thu, 27 Aug 2026 14:26:29 +0000

From Types to Testing: TypeScript Basics, Jest Mocking, and Git Etiquette

When learning modern full-stack development, knowing a programming language is not enough. We also need to write clean code, test our code, and work properly with Git.

In this post, we will look at some important basics of TypeScript, Jest testing, Git workflows, and code review etiquette.

1. TypeScript Basics: Types, Interfaces & Generics

TypeScript is JavaScript with static typing.

It helps us find many errors before running our code.

Basic Types

We can specify the type of a variable:

const developerName: string = "Harshith";
const experienceYears: number = 2;
const isDeveloper: boolean = true;

Here:

string → text
number → numbers
boolean → true or false

Interfaces

An interface defines the structure of an object.

interface User {
  readonly id: number;
  name: string;
  email: string;
  role?: string;
}

Now we can create a User object:

const currentUser: User = {
  id: 101,
  name: "Harshith",
  email: "harshith@example.com",
};

Important Interface Features

readonly

readonly id: number;

The value cannot be changed after the object is created.

Optional property

role?: string;

The role property is optional.

So this is also valid:

const user: User = {
  id: 102,
  name: "Rahul",
  email: "rahul@example.com",
};

2. Why TypeScript Is Useful

JavaScript allows this:

let age = 20;
age = "twenty";

TypeScript can prevent this mistake:

let age: number = 20;

// Error
age = "twenty";

This makes large applications easier to maintain and debug.

3. Jest Testing Basics

Jest is a JavaScript testing framework.

It allows us to check whether our functions are working correctly.

For example:

function add(a, b) {
  return a + b;
}

We can test it using Jest:

test("adds two numbers", () => {
  expect(add(2, 3)).toBe(5);
});

Here:

test() defines a test.
expect() checks the result.
toBe() compares the actual value with the expected value.

Testing helps us find bugs before they reach production.

4. Jest Mocking

Sometimes our function depends on another function or service.

Instead of calling the real service during a test, we can use a mock.

For example:

const getUser = jest.fn();

getUser.mockReturnValue({
  name: "Harshith"
});

Now getUser() returns our test data instead of calling a real database or API.

Mocking is useful because tests become:

Faster
More predictable
Independent of external services

5. Git Feature Branches

When working on a project, we should avoid making every change directly on the main branch.

Instead, we can create a feature branch:

git checkout -b feature/typescript-basics

Then make our changes and commit them:

git add .
git commit -m "feat: add TypeScript basics"

Finally, push the branch:

git push origin feature/typescript-basics

We can then create a Pull Request and ask other developers to review our changes.

6. Code Review Etiquette

Code reviews are not about finding mistakes in someone's code to criticize them.

The main goal is to improve the code together.

Instead of saying:

"This code is bad."

We can say:

"Could we simplify this function to make it easier to maintain?"

Good code review comments should be:

Clear
Respectful
Specific
Helpful

We should also explain why we are suggesting a change.

Conclusion

Today I learned that modern development involves more than just writing JavaScript.

TypeScript helps us write safer code with types and interfaces.

Jest helps us test our code and find problems early.

Git branches help us work safely without directly changing the main branch.

Code review etiquette helps teams communicate and improve code together.

Learning these concepts will help me write cleaner code and work more effectively in a professional development environment.

My Javascript Learning Journey:Async,Await,iterators & Generators

HARSHITH GADDAM — Sat, 15 Aug 2026 13:03:36 +0000

Today I learned several important JavaScript concepts related to asynchronous programming and iteration. Instead of only learning how these features work, I focused on understanding why they were introduced, the problems they solve, and where they are used in real-world applications.

Async/Await – Syntax Sugar over Promises

One of the biggest things I learned today is that async/await does not replace Promises. It is simply a cleaner and more readable way to work with them.

When we write:

async function getUser() {
    const user = await fetchUser();
    return user;
}

JavaScript is still using Promises internally. The await keyword pauses the execution of the async function until the Promise settles, making asynchronous code look very similar to synchronous code.

Without async/await, the same logic would require multiple .then() calls, making complex asynchronous code harder to read and maintain.

Handling Async Errors with try...catch

When using Promises directly, errors are usually handled with .catch().

fetchUser()
    .then(user => console.log(user))
    .catch(err => console.error(err));

With async/await, the same error handling becomes much cleaner using try...catch.

async function loadUser() {
    try {
        const user = await fetchUser();
        console.log(user);
    } catch (err) {
        console.error(err);
    }
}

I learned that try...catch only works with await inside an async function. If the awaited Promise rejects, JavaScript throws that rejection as an exception, which is then caught by the catch block.

This makes asynchronous error handling look just like normal synchronous error handling.

Promise.all()

Promise.all() is used when multiple asynchronous tasks need to finish before continuing.

For example, imagine a dashboard that needs to load:

User Profile
Orders
Shopping Cart
Recommendations

All these requests can start at the same time, but the dashboard should only be shown after every request is completed.

await Promise.all([
    fetchProfile(),
    fetchOrders(),
    fetchCart(),
    fetchRecommendations()
]);

I also learned that Promise.all() does not start the promises. The promises begin executing when they are created (or when the function calls are evaluated). Promise.all() simply waits for all of them to settle successfully.

Can We Display Data One by One?

Yes!

Instead of waiting for every request, each section of a webpage can be displayed as soon as its data arrives.

For example:

Show the profile first.
Then show the orders.
Then display the cart.
Finally load the recommendations.

Many websites like YouTube and Amazon use this approach to improve the user experience.

Promise.allSettled()

Sometimes we don't want the whole operation to fail just because one task fails.

For example, while uploading five files:

File 1 ✔️
File 2 ❌
File 3 ✔️
File 4 ✔️
File 5 ❌

Using Promise.all(), the first failure rejects the entire operation.

Using Promise.allSettled(), JavaScript waits for every promise to finish and tells us which ones succeeded and which ones failed.

This is useful for:

File uploads
Data synchronization
Background jobs
Health checks

Promise.race()

Promise.race() returns the result of the first promise that settles.

A common example is implementing request timeouts.

Promise.race([
    fetch("/user"),
    timeoutPromise
]);

If the server responds first, we use the response.

If the timeout finishes first, we stop waiting.

Promise.any()

Promise.any() returns the first successful promise.

Rejected promises are ignored unless every promise fails.

This is useful when working with:

Multiple mirror servers
Backup APIs
CDN replicas

The application simply uses the first successful response.

Promise Combinators Summary

Method	Purpose
Promise.all()	Wait for every promise to fulfill
Promise.allSettled()	Wait for every promise to settle, whether fulfilled or rejected
Promise.race()	Use the first promise that settles
Promise.any()	Use the first successful promise

Iterators

I learned that JavaScript needed a common way to loop through different types of collections like arrays, strings, maps, and sets.

An iterator is simply an object with a next() method.

Each call to next() returns:

{
    value,
    done
}

for...of internally uses iterators to retrieve values one by one.

Generators

Writing iterators manually requires managing state and keeping track of the current position.

Generators make this much easier.

A generator is declared using:

function* numbers() {
    yield 1;
    yield 2;
    yield 3;
}

The yield keyword pauses execution and remembers the current state.

Each call to next() resumes execution from where it previously stopped.

Generators automatically create iterators, making iteration much simpler.

Async Iterators

Normal iterators work only with values that are immediately available.

But what if the next value comes from:

A server
A database
A file
A WebSocket

In these situations, JavaScript introduced async iterators.

Unlike normal iterators, next() returns a Promise that eventually resolves to:

{
    value,
    done
}

This allows JavaScript to wait until the next value becomes available.

Async Generators

Just as generators simplify iterators, async generators simplify async iterators.

They are declared like this:

async function* stream() {
    yield "First";
    yield "Second";
    yield "Third";
}

They can be consumed using:

for await (const item of stream()) {
    console.log(item);
}

This makes working with asynchronous streams much easier.

Where Async Iterators Are Used

Some real-world examples include:

Streaming large files
Reading database records in batches
Live chat messages
WebSocket communication
AI response streaming (like ChatGPT)
Video or audio streaming

Instead of loading everything into memory, data is processed one piece at a time.

My Biggest Takeaways

async/await is syntax sugar over Promises and makes asynchronous code easier to read.
try...catch provides clean error handling for asynchronous code written with async/await.
Promise.all() waits for every promise and fails if any one fails.
Promise.allSettled() gives the result of every promise, whether it succeeds or fails.
Promise.race() returns whichever promise settles first.
Promise.any() returns the first successful promise.
Promises begin running when they are created; Promise.all() only waits for them.
A webpage doesn't always need to wait for every API before showing content—independent sections can be rendered progressively.
Iterators provide a standard way to access values one by one.
Generators automatically create iterators and use yield to pause and resume execution.
Async iterators return promises from next(), allowing values to arrive over time.
Async generators combine async and yield, making asynchronous data streams much easier to work with.

My JavaScript Learning Journey: CommonJS vs ESM,Design Patterns

HARSHITH GADDAM — Fri, 14 Aug 2026 10:24:42 +0000

JavaScript Architecture, Design Patterns, Memory Mechanics.

Today I learned about core JavaScript architecture, modules, design patterns, memory mechanics.

Understanding how JavaScript handles files, memory, and software design makes it much easier to write clean, scalable, and maintainable applications.

1. CommonJS (CJS) vs. ES Modules (ESM)

JavaScript uses modules to split code across multiple files and avoid polluting the global scope.

CommonJS (CJS)

CommonJS is the traditional module system used heavily in Node.js.

It uses:

require() for importing
module.exports for exporting

// greet.js
module.exports = function greet(name) {
    return `Hello, ${name}`;
};

Importing it:

const greet = require("./greet.js");

console.log(greet("Harshith"));

CommonJS module loading is generally synchronous.

ES Modules (ESM)

ES Modules are the modern JavaScript module standard and are supported by both browsers and modern Node.js.

They use:

export
export default
import

// greet.js
export function greet(name) {
    return `Hello, ${name}`;
}

Importing:

import { greet } from "./greet.js";

console.log(greet("Harshith"));

ESM uses static module declarations, allowing JavaScript engines and tooling to analyze module dependencies before execution.

Named Export vs. Default Export

Feature	Named Export	Default Export
Number per file	Multiple	One
Import syntax	`{}` required	No `{}`
Import name	Must match exported name	Can be any name
Example	`import { add } from "./math.js"`	`import

Calculator from "./Calculator.js"` |

For example:

// Named exports
export function add(a, b) {
    return a + b;
}

export function subtract(a, b) {
    return a - b;
}

Importing:

import { add, subtract } from "./math.js";

A default export:

export default function User() {
    // ...
}

can be imported as:

import User from "./User.js";

Important: Named imports use curly braces because they refer to specific named exports. They are not simply the same thing as ordinary object destructuring.

2. Garbage Collection, Closures, and Memory Leaks

JavaScript automatically manages memory using garbage collection.

Garbage Collection

A common model used by JavaScript engines is Mark-and-Sweep.

The engine starts from reachable roots, such as global references, and follows references to determine which objects are still reachable.

Objects that are no longer reachable can eventually be removed from memory.

let user = {
    name: "Harshith"
};

user = null;

After assigning null, the object previously referenced by user may become unreachable and eligible for garbage collection, assuming nothing else references it.

Closures

A closure occurs when an inner function retains access to variables from its outer lexical scope even after the outer function has finished executing.

function createCounter() {
    let count = 0;

    return function () {
        count++;
        return count;
    };
}

const counter = createCounter();

console.log(counter()); // 1
console.log(counter()); // 2

Even though createCounter() has finished executing, the returned function still has access to count.

Memory Leaks

A memory leak occurs when data that is no longer logically needed remains reachable, preventing garbage collection.

Common causes include:

Uncleared timers
Event listeners that are never removed
Long-lived references to large objects
Closures that unintentionally retain large data

For example:

function setupListener() {
    const heavyData = new Array(1000000).fill("📦");

    document.getElementById("btn").addEventListener("click", () => {
        console.log("Clicked!");
    });
}

The important lesson is that closures themselves are not memory leaks. A closure becomes a problem when it keeps references alive longer than necessary.

3. Four Essential Design Patterns

Design patterns are reusable approaches for solving common software design problems.

A. Module Pattern

The Module Pattern encapsulates internal state and exposes only the functionality that should be public.

A closure can be used to create private state:

const BankModule = (function () {

    let balance = 1000;

    return {
        withdraw(amount) {
            balance -= amount;
            return balance;
        }
    };

})();

Here, balance cannot be accessed directly from outside the module.

Analogy: An ATM hides the internal banking system while exposing only operations such as withdraw and check balance.

B. Singleton Pattern

The Singleton Pattern ensures that only one instance of a particular object is used.

class DatabaseConnection {

    constructor() {

        if (DatabaseConnection.instance) {
            return DatabaseConnection.instance;
        }

        this.connectionString = "mongodb://localhost:27017";

        DatabaseConnection.instance = this;
    }
}

const db1 = new DatabaseConnection();
const db2 = new DatabaseConnection();

console.log(db1 === db2); // true

Both variables refer to the same instance.

Analogy: Think of a single shared resource that the application should coordinate through one instance.

C. Factory Pattern

The Factory Pattern centralizes object creation.

Instead of spreading object-creation logic throughout the application, a factory decides which object to create.

class UserFactory {

    static createUser(type, name) {

        if (type === "admin") {
            return new User(name, ["READ", "WRITE"]);
        }

        if (type === "guest") {
            return new User(name, ["READ"]);
        }
    }
}

const admin = UserFactory.createUser("admin", "Sarah");

The caller doesn't need to know all the details required to create each type of user.

Analogy: A fast-food kitchen receives your order and handles the details of assembling the meal.

D. Observer Pattern

The Observer Pattern creates a one-to-many relationship where subscribers are notified when an event occurs.

class EventEmitter {

    constructor() {
        this.events = {};
    }

    on(event, listener) {

        if (!this.events[event]) {
            this.events[event] = [];
        }

        this.events[event].push(listener);
    }

    emit(event, data) {

        if (this.events[event]) {
            this.events[event].forEach(fn => fn(data));
        }
    }
}

Multiple listeners can subscribe to an event:

Event occurs
     ↓
EventEmitter
     ↓
 ┌───┼───┐
 ↓   ↓   ↓
L1  L2  L3

This helps create loosely coupled systems.

4. Functional Strategy Pattern

The Strategy Pattern allows us to choose between different algorithms without changing the main logic that uses them.

In functional JavaScript, strategies can simply be functions.

const fedexStrategy = (pkg) => {
    return pkg.weight * 1.5 + 5;
};

const uspsStrategy = (pkg) => {
    return pkg.weight * 0.9 + 3;
};

We can create a function that accepts a strategy:

const createShippingCalculator = (strategy) => (pkg) => {
    return strategy(pkg);
};

Then create a pre-configured calculator:

const calculateFedex =
    createShippingCalculator(fedexStrategy);

console.log(
    calculateFedex({ weight: 10 })
);

The important idea is:

Shipping Calculator
       ↓
   Strategy
   ↙     ↘
FedEx    USPS

We can change the strategy without changing the calculator itself.

Understanding `(strategy) => (pkg) => ...`

This syntax means that the outer function returns another function.

const createShippingCalculator = (strategy) => (pkg) => {
    return strategy(pkg);
};

Conceptually:

const createShippingCalculator = (strategy) => {

    return (pkg) => {
        return strategy(pkg);
    };

};

The returned function remembers strategy through a closure.

5. The SOLID Principles

SOLID is a collection of five principles that help us design maintainable and extensible software.

S — Single Responsibility Principle (SRP)

A class or function should have one clear responsibility and one main reason to change.

Instead of:

class User {
    saveToDatabase() {}
    sendEmail() {}
    generateReport() {}
}

we can separate responsibilities:

class UserRepository {

    save(user) {
        // Save user
    }
}

class EmailService {

    sendWelcomeEmail(email) {
        // Send email
    }
}

Each class focuses on a specific responsibility.

O — Open/Closed Principle (OCP)

Software should be open for extension but closed for modification.

For example:

class CreditCardPayment {

    pay(amount) {
        console.log(`Paid $${amount} with Credit Card`);
    }
}

class PayPalPayment {

    pay(amount) {
        console.log(`Paid $${amount} with PayPal`);
    }
}

class PaymentProcessor {

    process(amount, paymentStrategy) {
        paymentStrategy.pay(amount);
    }
}

We can add another payment strategy without modifying PaymentProcessor.

PaymentProcessor
       ↓
   Strategy
   ↙  ↓  ↘
Card PayPal UPI

L — Liskov Substitution Principle (LSP)

A subclass should be usable wherever its parent type is expected without breaking the application's behavior.

A problematic design would be:

class Bird {
    fly() {}
}

class Ostrich extends Bird {
    fly() {
        throw new Error("Cannot fly");
    }
}

The parent class promises that birds can fly, but Ostrich cannot satisfy that expectation.

A better hierarchy is:

class Bird {}

class FlyingBird extends Bird {

    fly() {
        return "Flying";
    }
}

class Duck extends FlyingBird {}

class Ostrich extends Bird {}

Now Ostrich doesn't inherit behavior it cannot support.

I — Interface Segregation Principle (ISP)

Clients should not be forced to depend on methods they don't need.

The general idea is:

Prefer small, focused interfaces or contracts rather than one large interface containing everything.

JavaScript doesn't have traditional interfaces like some languages, but the principle still applies when designing classes, objects, and APIs.

D — Dependency Inversion Principle (DIP)

High-level modules should not be tightly coupled to specific low-level implementations.

Instead, dependencies can be provided from outside.

class OrderProcessor {

    constructor(database) {
        this.db = database;
    }

    process(order) {
        this.db.save(order);
    }
}

Here, OrderProcessor doesn't create the database itself.

The dependency is injected:

const database = new Database();

const processor = new OrderProcessor(database);

This makes the code easier to test and replace with another implementation.

javascript #webdevelopment #programming #softwareengineering #designpatterns #solidprinciples #nodejs #learninginpublic

My JavaScript Learning Journey: Call Back Hell & Promises

HARSHITH GADDAM — Tue, 04 Aug 2026 11:54:33 +0000

Today I learned one of the most important concepts in JavaScript—asynchronous programming with Promises. Initially, Promises seemed confusing, but after understanding how they work internally, the concept became much clearer.

1. What is Callback Hell?

A callback is a function passed to another function that executes after an asynchronous operation completes.

When multiple asynchronous operations depend on each other, callbacks become deeply nested.

getUser(userId, function(user) {
    getOrders(user.id, function(orders) {
        getOrderDetails(orders[0].id, function(details) {
            processOrder(details, function(result) {
                console.log(result);
            });
        });
    });
});

This deeply nested structure is called Callback Hell or the Pyramid of Doom.

Problems with Callback Hell

Difficult to read
Hard to debug
Difficult to maintain
Error handling becomes complicated

To solve these problems, JavaScript introduced Promises.

2. What is a Promise?

A Promise is an object that represents the eventual result of an asynchronous operation.

It promises that it will either:

Complete successfully
Fail with an error

A Promise starts in the Pending state and eventually becomes either Fulfilled or Rejected.

3. Promise States

Every Promise has three possible states.

Pending

The asynchronous operation is still running.

Fulfilled

The operation completed successfully.

Rejected

The operation failed.

A Promise can change its state only once.

Pending
   |
   | resolve()
   ▼
Fulfilled

OR

Pending
   |
   | reject()
   ▼
Rejected

4. Creating a Promise

A Promise is created using the Promise constructor.

const promise = new Promise((resolve, reject) => {

});

One important thing I learned today is that I do not create resolve and reject myself.

JavaScript automatically provides these two functions to the Promise executor.

Conceptually, it works like this:

new Promise((resolve, reject) => {

});

Here,

resolve() is used when the operation succeeds.
reject() is used when the operation fails.

5. Using resolve() and reject()

Example:

const promise = new Promise((resolve, reject) => {

    const marks = 80;

    if (marks >= 35)
        resolve("Pass");
    else
        reject("Fail");

});

If the condition is true, the Promise becomes Fulfilled.

Otherwise, it becomes Rejected.

6. Handling Promises

then()

.then() executes only when the Promise is fulfilled.

promise.then(result => {
    console.log(result);
});

catch()

.catch() executes only when the Promise is rejected.

promise.catch(error => {
    console.log(error);
});

finally()

.finally() executes whether the Promise succeeds or fails.

It is useful for cleanup operations like hiding loading indicators or closing connections.

promise.finally(() => {
    console.log("Finished");
});

7. Promise Chaining

Every .then(), .catch(), and .finally() returns another Promise.

This allows us to chain multiple asynchronous operations.

Promise.resolve(10)
    .then(value => value * 2)
    .then(value => value + 5)
    .then(value => console.log(value));

Output:

Each .then() receives the value returned by the previous .then().

8. Error Propagation

One of the most interesting concepts I learned today is Error Propagation.

If an error occurs inside any .then() callback, JavaScript automatically skips all remaining .then() callbacks and jumps directly to the nearest .catch().

Promise.resolve(10)
    .then(value => {
        throw new Error("Something went wrong");
    })
    .then(() => {
        console.log("This will never execute");
    })
    .catch(error => {
        console.log(error.message);
    });

Output:

Something went wrong

This makes error handling much simpler because a single .catch() can handle errors from multiple Promise operations.

9. Practical Promise Example

function login(username, password) {

    return new Promise((resolve, reject) => {

        setTimeout(() => {

            if (username === "harshith" && password === "1234") {
                resolve("Login Successful");
            } else {
                reject("Invalid Username or Password");
            }

        }, 2000);

    });

}

login("harshith", "1234")
    .then(message => console.log(message))
    .catch(error => console.log(error));

This example helped me understand when to call resolve() and reject() based on a condition.

10. Key Takeaways

Callback Hell makes asynchronous code difficult to read and maintain.
Promises solve Callback Hell by making asynchronous code cleaner.
Every Promise has three states: Pending, Fulfilled, and Rejected.
JavaScript automatically provides the resolve() and reject() functions when creating a Promise.
resolve() changes a Promise to Fulfilled.
reject() changes a Promise to Rejected.
.then() handles successful results.
.catch() handles errors and rejected Promises.
.finally() executes regardless of success or failure.
Promise chaining makes complex asynchronous operations easier to manage.
Errors automatically propagate through the Promise chain until they are handled by the nearest .catch().

Conclusion

Today's learning helped me understand how JavaScript manages asynchronous operations using Promises.I learned why callback hell occurs, how Promises improve code readability, how Promise states work, how resolve() and reject() are provided by JavaScript, and how .then(), .catch(), .finally(), Promise chaining, and error propagation make asynchronous programming much cleaner and easier to maintain.

Understanding these concepts has also given me a much stronger foundation for learning async/await, since it is built on top of Promises.

My JavaScript Learning Journey:Object-Oriented Programming (OOP) in JavaScript

HARSHITH GADDAM — Mon, 27 Jul 2026 17:08:59 +0000

JavaScript supports Object-Oriented Programming (OOP) through objects, prototypes, and classes. ES6 introduced a cleaner class syntax, making OOP easier to understand and write. In this blog, I'll explain the four pillars of OOP and some useful class features in JavaScript.

1. Inheritance

Inheritance allows one class to reuse the properties and methods of another class.

Example:

class Animal {
eat() {
console.log("Eating");
}
}

class Dog extends Animal {}

const dog = new Dog();

dog.eat();

Since Dog extends Animal, it inherits the eat() method.

This helps us avoid writing the same code again.

2. Polymorphism

Polymorphism means one method can behave differently depending on the object that calls it.

In JavaScript, this is usually achieved by overriding a parent class method in a child class.

Example

class Animal {
speak() {
console.log("Animal makes a sound");
}
}

class Dog extends Animal {
speak() {
console.log("Dog barks");
}
}

class Cat extends Animal {
speak() {
console.log("Cat meows");
}
}

const dog = new Dog();
const cat = new Cat();

dog.speak();
cat.speak();

Output:

Dog barks
Cat meows

Here, all classes have the same speak() method, but each class provides its own implementation. This is called polymorphism.

3. Abstraction

Abstraction means showing only the necessary functionality and hiding the internal implementation.

For example, when we start a car, we only press the start button. We don't need to know how the engine, fuel system, and battery work internally.

JavaScript allows us to achieve abstraction using classes and private methods or private fields.

Example

class Car {
start() {
this.#checkFuel();
console.log("Car Started");
}

#checkFuel() {
    console.log("Checking Fuel...");
}

}

const car = new Car();

car.start();

Output:

Checking Fuel...
Car Started

The user only calls start(). The internal method #checkFuel() remains hidden from outside the class. This makes the code easier to use and protects the internal implementation.

4. Static Members

Normally, we create an object before calling a method.

const obj = new Person();

But some methods belong to the class itself, not to its objects.

These are called static methods.

Example:

class MathUtil {
static add(a, b) {
return a + b;
}
}

console.log(MathUtil.add(5, 3));

Notice that we didn't create an object.

5. Getters and Setters

Getters and setters allow us to control how properties are read and updated.

Example:

class Person {
constructor(name) {
this._name = name;
}
get name() {
return this._name;
}

set name(value) {
    if (value.length >= 3) {
        this._name = value;
    }
}

}

This helps us validate data before updating it.

6. Encapsulation Using Closures

Encapsulation means bundling data and methods into a single unit.And Closure means accessing the outer methods variables inside inner methods after outer function(method) has completed its execution.

Example:

function BankAccount() {
let balance = 1000;
return {
deposit(amount) {
balance += amount;
},

    getBalance() {
        return balance;
    }
};

}
const account = BankAccount();
account.deposit(500);
console.log(account.getBalance());
//console.log(account.balance); will throw an error

The variable balance cannot be accessed directly from outside the function.

In the above Example you can see balance,deposit(),getBalance() are bundled together.

7. Private Fields (`#field`)

Modern JavaScript provides another way to hide data using private fields.

Example:

class BankAccount {
#balance = 1000;
deposit(amount) {
this.#balance += amount;
}
getBalance() {
return this.#balance;
}
}
const account = new BankAccount();
account.deposit(500);
console.log(account.getBalance());
Trying to access:
account.#balance;

will cause an error because private fields can only be accessed inside the class.

Conclusion

Now I know that JavaScript's OOP system is built on prototypes, and classes simply make the syntax cleaner and easier to read. Understanding these concepts gives a strong foundation for writing better JavaScript code.

My JavaScript Learning Journey:Prototypes

HARSHITH GADDAM — Mon, 27 Jul 2026 12:17:05 +0000

JavaScript is different from many other programming languages when it comes to Object-Oriented Programming (OOP) because it is prototype-based. Instead of using classes as its foundation, JavaScript uses prototypes.

In this blog, I'll explain the topics I learned today.

1. What is a Prototype?

A prototype is a shared object that stores common methods and properties.

Instead of creating a separate copy of the same method for every object, JavaScript stores it once in the prototype, and all objects created from the same constructor or class share it.

Example

function Person(name) {
this.name = name;
}

Person.prototype.greet = function () {
console.log(Hello, I'm ${this.name});
};

const p1 = new Person("Harshith");
const p2 = new Person("Rahul");

p1.greet();
p2.greet();

Here, both p1 and p2 use the same greet() method from Person.prototype.

This saves memory because JavaScript doesn't create multiple copies of the same function.

2. Prototype vs `proto`

This topic confused me at first, but here's the difference.

`prototype`

Exists on functions.
Used when creating new objects with the new keyword.
Stores shared methods.

Example:

function Person(name) {
this.name = name;
}

Person.prototype.greet = function () {};
const p1 = new Person("Harshith");
p1 will have a property called "proto" there it stores the prototype of Person
p1.proto=Person.prototype;

`proto`

Exists on objects.
Points to the object's prototype.
JavaScript follows this link while searching for properties.

Example:

const person = new Person("Harshith");

console.log(person.proto === Person.prototype);

A simple way to remember:

prototype belongs to functions.
__proto__ belongs to objects.

3. Prototype Chain

When JavaScript cannot find a property inside an object, it searches its prototype.

If it is still not found, it continues searching through the next prototype until it reaches null.

Example:

const animal = {
eat() {
console.log("Eating");
}
};

const dog = Object.create(animal);

dog.eat();

JavaScript searches like this:

dog

↓

animal.prototype

↓

null

This searching process is called the Prototype Chain.

4. Object.create()

Object.create() creates a new object whose prototype is another object.

Example:

const animal = {
eat() {
console.log("Eating");
}
};

const dog = Object.create(animal);

dog.eat();

The dog object doesn't have its own eat() method.

It inherits it from animal.

5. Classes are Syntactic Sugar

Before ES6, constructor functions were used to create objects.

function Person(name) {
this.name = name;
}
Person.prototype.greet=function (){
console.log(this.name);
}

Now we can write:

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

greet() {
    console.log(this.name);
}

}

Both work almost the same internally.

A class is simply a cleaner and easier syntax built on top of JavaScript's prototype system.

conclusion

At first, JavaScript prototypes can feel confusing because there are terms like prototype, __proto__, constructor functions, and classes. But once I understood that objects inherit methods through prototypes, everything started making sense.

My JavaScript Learning Journey:Understanding the JavaScript Event Loop and Concurrency Model

HARSHITH GADDAM — Tue, 21 Jul 2026 13:31:11 +0000

Today, I learned one of the most important concepts in JavaScript: the Event Loop and the Concurrency Model.

JavaScript is Single-Threaded

JavaScript is a single-threaded language. This means it can execute only one piece of JavaScript code at a time.

For example:

console.log("A");
console.log("B");
console.log("C");

Output:

A
B
C

JavaScript executes these statements one after another.

What is the Call Stack?

The Call Stack is where JavaScript executes functions. Whenever a function is called, it is added to the stack. After the function finishes executing, it is removed from the stack.

Example:

function one() {
two();
}

function two() {
console.log("Hello");
}

one();

Execution order:

one()
↓
two()
↓
console.log()
↓
Stack becomes empty

The Call Stack follows the Last In, First Out (LIFO) principle.

What are Web APIs and Node APIs?

Some operations take time, such as:

Waiting for a timer
Making an API request
Reading a file
Listening for button clicks

JavaScript itself cannot perform these operations.

Instead, it asks the runtime to handle them.

In Browsers

The browser provides Web APIs such as:

setTimeout()
setInterval()
fetch()
addEventListener()
DOM APIs
localStorage

In Node.js

Node.js provides Node APIs such as:

fs.readFile()
fs.writeFile()
path
os
http

These APIs perform asynchronous work outside the JavaScript engine.

Callback (Macrotask) Queue

When an asynchronous operation like setTimeout() finishes, its callback does not execute immediately.

Instead, it is placed into the Callback Queue, also called the Macrotask Queue.

Example:

setTimeout(() => {
console.log("Timer");
}, 1000);

After one second Call back function added to Callback Queue.
It waits there until the Event Loop moves it to the Call Stack.

Microtask Queue

The Microtask Queue has a higher priority than the Callback Queue.

The following callbacks are added to the Microtask Queue:

Promise.then()
Promise.catch()
Promise.finally()
await
queueMicrotask()

Example:

Promise.resolve().then(() => {
console.log("Promise");
});

The callback is placed in the Microtask Queue.

Event Loop

The Event Loop is responsible for checking whether the Call Stack is empty.

When the Call Stack becomes empty, it:

Executes all Microtasks
Executes one Callback (Macrotask)
Again checks call stack is empty or not and does 1&2.

It does not execute code itself. It simply moves callbacks from the queues to the Call Stack.

Why do Promises execute before setTimeout()?

Consider this example:

console.log("Start");

setTimeout(() => {
console.log("Timeout");
}, 0);

Promise.resolve().then(() => {
console.log("Promise");
});

console.log("End");

Output:
Start
End
Promise
Timeout

Why?

Promise.then() goes to the Microtask Queue.
setTimeout() goes to the Callback (Macrotask) Queue.
The Event Loop always executes all Microtasks first before executing Macrotasks.

Does setTimeout() execute exactly on time?

A common misunderstanding is that:

setTimeout(callback, 1000);

means the callback will execute exactly after one second.

This is not true.

It means:

Execute the callback after at least one second.

If the Call Stack is busy with synchronous code, the callback has to wait.

Example:

setTimeout(() => {
console.log("Done");
}, 1000);

// Imagine this loop takes 3 seconds
for (let i = 0; i < 1e10; i++) {}

console.log("Finished");

Output:
Finished
Done

Even though the timer finished after one second, the callback waited until the Call Stack became empty.

What is the JavaScript Concurrency Model?

JavaScript can execute only one line of code at a time, but it can still handle many asynchronous operations.

For example:

A timer can be counting.
A network request can be downloading.
The browser can listen for button clicks.

All these operations are handled by the browser or Node.js while JavaScript continues executing other code.

When these operations finish, their callbacks are added to the appropriate queue.

This ability to make multiple operations progress during the same period of time is called the Concurrency Model.

Cooperative Concurrency vs True Parallelism

These two terms are often confused.

Cooperative Concurrency

Only one JavaScript task runs at a time.

Tasks take turns executing.

Example:

One chef starts cooking rice, then makes tea while the rice cooks.

The chef is not doing both tasks at the exact same moment, but both tasks are progressing.

JavaScript works like this.

True Parallelism

Multiple tasks execute at the exact same time using different CPU cores or threads.

Example:

Chef 1 cooks rice.
Chef 2 makes tea.
Chef 3 cuts vegetables.

All three are working simultaneously.

Conclusion

Learning the Event Loop and the Concurrency Model helped me understand how JavaScript performs asynchronous operations without blocking the main thread. These concepts explain why Promise callbacks execute before setTimeout(), why timers are not always exact, and how browsers and Node.js work together with JavaScript to build responsive applications.

Understanding these fundamentals is essential for writing efficient JavaScript code.
Thank you for reading! If you're also learning JavaScript, I hope this summary helps you understand these concepts more clearly. Happy coding!

My JavaScript Learning Journey: Understanding How JavaScript Really Works

HARSHITH GADDAM — Tue, 21 Jul 2026 11:32:29 +0000

During this learning session, I focused on JavaScript's internal working, including Execution Context, Variables, Scope, Closures, Hoisting, this binding, Call Stack, and Clean Code Principles like DRY and KISS.

JavaScript Execution Context

The first topic I learned was Execution Context.

An Execution Context is the environment in which JavaScript executes code. Whenever JavaScript runs a script or calls a function, it creates an execution context.

Each execution context has two phases:

i)Memory Creation Phase
Before executing the code, JavaScript scans it and allocates memory.

During this phase:

var variables are initialized with undefined.
let and const are allocated memory but remain uninitialized (Temporal Dead Zone).
Function declarations are stored completely in memory.

Example:

console.log(a);
var a = 10;
Output:
undefined

Because var is initialized with undefined during the memory phase.

ii)Code Execution Phase

After memory allocation, JavaScript starts executing the code line by line.

Example:
var a = 10;
console.log(a);
Output:
10

Variables in JavaScript

I learned the differences between var, let, and const.

a)var
-Function scoped
-Can be redeclared
-Can be reassigned
-Hoisted with undefined

b)let
Block scoped
Cannot be redeclared in the same scope
Can be reassigned
Exists in the Temporal Dead Zone before initialization

c)const
Block scoped
Cannot be redeclared
Cannot be reassigned
Must be initialized during declaration

Lexical Scope

One important concept I learned is Lexical Scope.

Lexical Scope means a function can access variables from the scope where it was created.

Example:

let name = "Harshith";

function greet() {
console.log(name);
}

greet();

The function accesses name because it was created inside the same scope.

Closures

A Closure is created when a function remembers variables from its outer scope even after the outer function has finished executing.

Example:

function counter() {

let count = 0;

return function () {
    count++;
    console.log(count);
};

}

const increment = counter();

increment();
increment();
increment();

Output:
1
2
3

The variable count remains available because of the closure.

Closures are commonly used to create private variables and implement the module pattern.

Hoisting

Hoisting is JavaScript's behavior of moving declarations to the top of their scope before execution.

Example:

console.log(a);
var a = 10;

Output:
undefined

For let and const:

console.log(a);
let a = 10;

Output:
ReferenceError

because the variable is inside the Temporal Dead Zone until it is initialized.

Understanding this Binding

One of the most interesting topics I learned was how JavaScript decides the value of this.

a)Default Binding
function greet() {
console.log(this);
}

greet();

In non-strict mode, this refers to the global object.

b)Implicit Binding
const person = {
name: "Harshith",

greet() {
    console.log(this.name);
}

};

person.greet();

Here, this refers to person.

c)Explicit Binding

JavaScript allows us to manually set this using call(), apply(), and bind().

function greet(city) {
console.log(this.name, city);
}

const person = {
name: "Harshith"
};

greet.call(person, "Hyderabad");

d)new Binding

When a function is called using the new keyword, JavaScript creates a new object and binds this to it.

function Person(name) {
this.name = name;
}

const p = new Person("Harsh");

Writing Better Code with DRY and KISS

Besides JavaScript internals, I also learned two important software engineering principles.

a)DRY (Don't Repeat Yourself)

Instead of repeating the same logic multiple times, create reusable functions.

This makes code easier to maintain.

b)KISS (Keep It Simple, Stupid)

Write simple, readable code instead of overly complex solutions.

Simple code is easier to understand, debug, and maintain.

Thank you for reading! If you're also learning JavaScript, I hope this summary helps you understand these core concepts more clearly. Happy coding!