DEV Community: Chinwuba

From Raw SQL Strings to Type-Safe Queries: How I Learned Prisma ORM

Chinwuba — Sun, 07 Jun 2026 17:20:06 +0000

I'm a web design agency CEO teaching myself full-stack development in public.
This is week 7 of a 16-week roadmap I built to go from React-only to full React + Express + PostgreSQL. Last week I finished Express core — routing, middleware, CORS, error handling, full CRUD with in-memory arrays. This week the arrays are gone. I'm talking to a real database now.

This post covers everything I learned about Prisma ORM — what it is, why it exists, how migrations work, how the client works, and how I wired it all into Express. I'll show you the actual code I wrote, the mistakes I made, and what clicked for me along the way.

The problem Prisma solves

Before I touch any Prisma code, I need to explain why it exists. Because if you don't understand the problem, the solution feels like unnecessary abstraction.

When you talk to PostgreSQL from Node.js without any tools, you write raw SQL as strings:

js
const result = await db.query(`SELECT * FROM projects WHERE client_id = ${clientId}`)

This works. But it has real problems that become painful at scale.
No type safety. You typed client_id — but what if the column is actually called clientId? You won't find out until runtime. Your editor has no idea what your database looks like, so it can't warn you. Every query is a guess.

No autocomplete. The result you get back is a plain JavaScript object. You're guessing the shape. Is it result.rows? result.data? Depends on the library. And the object itself carries no type information — autocomplete is completely dead.
No database history. You add a column in development, forget to add it in production, things break at the worst possible time. You need a way to track database structure changes the same way you track code changes — with version control.

Prisma solves all three. Type safety, autocomplete, and a migration system that versions your database schema like git versions your code.

What Prisma actually is

Prisma is an ORM — Object Relational Mapper. It sits between your Express app and your PostgreSQL database. Instead of writing SQL strings, you write JavaScript. Prisma translates that JavaScript into the correct SQL and executes it.
But it's not just a query translator. It has three distinct parts that work together:

Prisma Schema — a single file where you describe your entire database structure. Tables, columns, data types, relationships. Your entire database in one place.
Prisma Migrate — a CLI tool that reads your schema, compares it to the current state of your database, and generates the SQL needed to bring them in sync. Every change is saved as a migration file — a permanent record of how your database evolved.
Prisma Client — an auto-generated, fully typed JavaScript client. Once your schema is defined, Prisma generates a client that knows exactly what your database looks like. Your editor knows your tables, your columns, their types. Full autocomplete, full type safety.

Project setup

I'm using Node.js with CommonJS (require/module.exports), Express, and Supabase for my PostgreSQL database.

bash
mkdir prisma-project && cd prisma-project
npm init -y
npm install express dotenv cors
npm install prisma @prisma/client
npx prisma init

npx prisma init creates two things: a prisma/ folder with a schema.prisma file, and a .env file at the root with a DATABASE_URL placeholder.

I replaced that placeholder with my Supabase connection string from Settings → Database → Connection string → URI.

One issue I hit: I had a prisma.config.ts file auto-generated by Prisma 6 that was intercepting my .env loading. The error was: "Prisma config detected, skipping environment variable loading." Deleting prisma.config.ts fixed it immediately.

The Schema

Everything in Prisma starts with prisma/schema.prisma. This file is your single source of truth for the database.

prisma
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model Client {
  id        Int       @id @default(autoincrement())
  name      String
  email     String    @unique
  createdAt DateTime  @default(now())
  projects  Project[]
}

model Project {
  id        Int      @id @default(autoincrement())
  title     String
  status    String   @default("active")
  createdAt DateTime @default(now())
  clientId  Int
  client    Client   @relation(fields: [clientId], references: [id])
}

Let me break this down piece by piece.
model maps to a database table. Each field inside is a column. The type after the field name (String, Int, DateTime) is Prisma's type system — it maps to the correct PostgreSQL type automatically.

The @ decorators are modifiers:

@id — marks this field as the primary key
@default(autoincrement()) — the database auto-generates an incrementing integer
@unique — no two rows can share this value
@default(now()) — auto-fills with the current timestamp on insert
@default("active") — sets a literal string default

The last two lines of the Project model are the foreign key relationship:

prisma
clientId  Int
client    Client   @relation(fields: [clientId], references: [id])

clientId is the actual column in the database — an integer that stores the id of the related client. The client field below it is not a column — it's a virtual relation field that tells Prisma how to do the join. fields: [clientId] is the foreign key on this model. references: [id] is the primary key it points to on Client.

The projects Project[] field on the Client model is the other side of the same relation — it tells Prisma that one client can have many projects. Again, not a column. Just a relation definition.

Migrations

Once the schema is written, I ran:

bash
npx prisma migrate dev --name init

Prisma reads the schema, generates the SQL to create both tables with the correct columns, constraints, and foreign keys, executes it against my Supabase database, and saves the generated SQL as a migration file in prisma/migrations/.

That migration file is committed to git alongside your code. Every subsequent schema change — adding a column, renaming a field, adding a new model — gets its own migration. You always have a full history of how your database structure evolved.
After the migration ran, both tables appeared in my Supabase dashboard with the correct structure.

The Prisma Client singleton

After migration, I ran npx prisma generate (migrate dev does this automatically). This generates the typed client based on my schema.

The critical thing about Prisma Client: it should be a singleton. Creating a new PrismaClient() in every file that needs database access will open a new connection pool each time, which exhausts your database connections quickly.

The solution is one file that creates the instance and exports it:

js
// lib/prisma.js
const { PrismaClient } = require("@prisma/client")
const prisma = new PrismaClient()

module.exports = prisma

Every route file imports from here. One instance, shared across the whole app.

The routes

My project structure:

prisma-project/
├── lib/
│   └── prisma.js
├── routes/
│   ├── clients.js
│   └── projects.js
└── index.js

clients.js

js
const prisma = require("../lib/prisma")
const express = require("express")
const router = express.Router()

router.post("/", async (req, res, next) => {
  try {
    const { name, email } = req.body
    const newClient = await prisma.client.create({
      data: { name, email }
    })
    res.status(201).json(newClient)
  } catch (err) {
    next(err)
  }
})

router.get("/", async (req, res, next) => {
  try {
    const clients = await prisma.client.findMany()
    res.json(clients)
  } catch (err) {
    next(err)
  }
})

module.exports = router

projects.js

js
const express = require("express")
const prisma = require("../lib/prisma")
const router = express.Router()

router.post("/", async (req, res, next) => {
  try {
    const { title, clientId } = req.body
    const newProject = await prisma.project.create({
      data: { title, clientId }
    })
    res.status(201).json(newProject)
  } catch (err) {
    next(err)
  }
})

router.get("/", async (req, res, next) => {
  try {
    const projects = await prisma.project.findMany({
      include: { client: true }
    })
    res.json(projects)
  } catch (err) {
    next(err)
  }
})

router.put("/:id", async (req, res, next) => {
  const { status } = req.body
  const projectId = Number(req.params.id)
  try {
    const updated = await prisma.project.update({
      where: { id: projectId },
      data: { status }
    })
    res.json(updated)
  } catch (err) {
    next(err)
  }
})

router.delete("/:id", async (req, res, next) => {
  const projectId = Number(req.params.id)
  try {
    await prisma.project.delete({
      where: { id: projectId }
    })
    res.json({ message: `Project ${projectId} deleted successfully` })
  } catch (err) {
    next(err)
  }
})

module.exports = router

A few things worth noting:
prisma.project.create takes a data object — the fields you want to write. Fields with defaults (status, createdAt) don't need to be included.

prisma.project.findMany with include: { client: true } performs a JOIN under the hood and returns the client object nested inside each project. One line of JavaScript, no SQL join syntax.

prisma.project.update and prisma.project.delete both take a where clause to identify which record to target. where: { id: projectId } maps to WHERE id = $1 in SQL.

req.params.id is always a string — I wrapped it with Number() before passing it to Prisma since the schema expects an Int.

index.js

js
require("dotenv").config()
const cors = require("cors")
const express = require("express")
const clientRouter = require("./routes/clients")
const projectRouter = require("./routes/projects")

const app = express()
const PORT = process.env.PORT || 5000

app.use(express.json())
app.use(cors({ origin: "*" }))
app.use("/clients", clientRouter)
app.use("/projects", projectRouter)

function errMiddleware(err, req, res, next) {
  res.status(err.status || 500).json({
    statusCode: err.status || 500,
    message: err.message || "Something went wrong"
  })
}

app.use(errMiddleware)

app.listen(PORT, () => {
  console.log(`App running on port ${PORT}`)
})

One routing mistake I made: I defined routes as router.post("/clients", ...) inside the router file while also mounting at app.use("/clients", router) in index.js. That made the actual endpoint /clients/clients. The fix is to use "/" inside the router file since the prefix already lives in

index.js.

The error middleware has the 4-argument signature (err, req, res, next) — Express identifies error middleware by that fourth argument. It must be registered after all routes. err.status || 500 ensures you always send a valid status code even if the error object doesn't carry one.

Testing in Postman

All 6 routes tested and working:

POST /clients → returns created client with auto-generated id and timestamp
GET /clients → returns array of all clients
POST /projects → returns created project with status: "active" auto-filled
GET /projects → returns all projects with nested client object from the JOIN
PUT /projects/1 → returns updated project with new status
DELETE /projects/1 → returns success message

Building in public. Sharing everything.

Continuation — Tables, CRUD, and Foreign Keys

Chinwuba — Sat, 06 Jun 2026 16:15:15 +0000

I've been building with React and Supabase for a while now.
I'm currently in Phase 3 of my 16-week Express.js roadmap — the Database + Auth phase — and PostgreSQL was the first thing on the list. Here's what I learned.

Creating a table

Before you write a single query, you need to define the shape of your data. In PostgreSQL that looks like this:

sql
CREATE TABLE clients (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  email VARCHAR(150) UNIQUE NOT NULL,
  budget NUMERIC(12, 2),
  status VARCHAR(20) DEFAULT 'lead',
  created_at TIMESTAMP DEFAULT NOW()
);

A few things worth noting:

SERIAL is PostgreSQL handling your ID auto-increment for you. You never insert it manually.

DEFAULT means if you don't supply a value, PostgreSQL fills it in. status defaults to 'lead', created_at defaults to the current timestamp.

NOT NULL makes a field required. UNIQUE means no two rows can share that value — useful for emails.

CRUD in plain SQL

Once your table exists, the four operations you'll use constantly are INSERT, SELECT, UPDATE, and DELETE.

sql-- Create
INSERT INTO clients (name, email, budget)
VALUES ('Apex Realty', 'contact@apexrealty.com', 750000.00);

-- Read
SELECT * FROM clients WHERE status = 'active' ORDER BY budget DESC;

-- Update
UPDATE clients
SET status = 'active'
WHERE id = 1;

-- Delete
DELETE FROM clients WHERE id = 1;

The one rule that will save you from a painful mistake: always use WHERE on UPDATE and DELETE. Without it, you're modifying or wiping every single row in the table.

Relating tables with foreign keys

A real app has multiple tables that reference each other. A project belongs to a client. An invoice belongs to a project. That relationship is enforced with a foreign key.

sql
CREATE TABLE projects (
  id SERIAL PRIMARY KEY,
  client_id INT REFERENCES clients(id),
  title VARCHAR(150) NOT NULL,
  price NUMERIC(12, 2),
  created_at TIMESTAMP DEFAULT NOW()
);

client_id INT REFERENCES clients(id) tells PostgreSQL that every value in that column must exist as an ID in the clients table. You can't insert a project with a client_id that doesn't exist. The database enforces the integrity for you.

When inserting, you supply the ID manually:

sql
INSERT INTO projects (client_id, title, price)
VALUES (1, 'Apex Realty Website Redesign', 750000.00);
PostgreSQL doesn't guess which client a project belongs to. You always pass it explicitly.

What's next

Prisma, which gives you all of this through a JavaScript API without writing raw SQL by hand.
Building in public. Week 3 of 16.

Databases — Here's What Actually Clicked

Chinwuba — Fri, 05 Jun 2026 16:55:00 +0000

I've been a frontend developer for a while. React, Supabase, Cloudinary — I've used them. But I never actually understood what was happening inside the database. I was just clicking buttons in the Supabase dashboard hoping for the best.
Today that changed. I sat down and wrote raw SQL for the first time. No ORM, no abstraction. Just me and Postgres.
Here's what I learned.

Tables are not spreadsheets

Well, they look like spreadsheets. But the difference is Postgres enforces rules on your data that Excel never would.
When you create a table, every column has a type. And Postgres holds you to it strictly.

sql
CREATE TABLE clients (
  id         UUID      PRIMARY KEY DEFAULT gen_random_uuid(),
  name       TEXT      NOT NULL,
  email      TEXT      UNIQUE NOT NULL,
  phone      TEXT,
  brand_info JSONB,
  created_at TIMESTAMP DEFAULT now()
);

NOT NULL means the field is required. UNIQUE means no two rows can share that value. DEFAULT means Postgres fills it in automatically if you don't provide it.

These constraints catch bad data before it ever touches your application. That's the point.

Relationships are just foreign keys

I was confused about this before. How do you connect two tables?
You add a column to one table that points to the primary key of another. That's it. That column is called a foreign key.

sql
CREATE TABLE projects (
  id         UUID      PRIMARY KEY DEFAULT gen_random_uuid(),
  name       TEXT      NOT NULL,
  status     TEXT,
  stage      TEXT,
  budget     DECIMAL,
  client_id  UUID      REFERENCES clients(id),
  created_at TIMESTAMP DEFAULT now()
);

client_id REFERENCES clients(id) tells Postgres: whatever value goes in this column must exist in the clients table. If it doesn't, the insert gets rejected. The database enforces the relationship, not your application code.

Order matters on inserts

This one bit me. I tried to insert a project before inserting the client it belonged to. Postgres rejected it immediately — the client_id I was referencing didn't exist yet.
The rule: always insert the parent record first.

sql-- First, the client

INSERT INTO clients (id, name, phone, email) 
VALUES (gen_random_uuid(), 'Jeffrey', '09012345678', 'jeffrey@velto.com');

-- Then, the project — using the client's UUID

INSERT INTO projects (id, name, status, stage, budget, client_id) 
VALUES (gen_random_uuid(), 'Velto', 'ongoing', 'development', 500.00, 'your-client-uuid-here');

`JOIN` pulls data across tables

The whole point of relationships is being able to query related data together. That's what JOIN does.

sql
SELECT 
  clients.name AS client_name,
  clients.email,
  projects.name AS project_name,
  projects.status
FROM projects
JOIN clients ON projects.client_id = clients.id;

Notice the AS aliases — both tables had a name column. Without aliases, Postgres would just show one of them. Aliasing gives each column a unique label in the result.

What I'm building toward

This is Phase 3 of my 16-week Express.js roadmap. The end goal is a Velto Client Portal — client login, project tracking, file uploads, invoices, and Paystack integration.

Understanding raw SQL first, before Prisma abstracts it away, is what makes the difference between a developer who debugs confidently and one who guesses and prays.

Next up: Prisma ORM — same concepts, cleaner syntax, and proper migrations.

Understanding PostgreSQL Tables, Relationships, and Foreign Keys: A Beginner's Journey

Chinwuba — Thu, 04 Jun 2026 18:01:36 +0000

Today I moved beyond JavaScript arrays and started learning how real applications store data using PostgreSQL.

If you're just getting into backend development, here's a practical explanation of what I learned.

What Is PostgreSQL?

PostgreSQL is a relational database.

Instead of storing data in temporary variables that disappear when your server restarts, PostgreSQL stores data permanently in tables.

Think of it like a highly structured spreadsheet that can handle millions of records and enforce rules on your data.

Understanding Tables

A table contains:

Columns → Define the structure
Rows → Store the actual data

Example:

| id | name     | email                                               |
| -- | -------- | --------------------------------------------------- |
| 1  | Chinwuba | [chinwuba@example.com](mailto:chinwuba@example.com) |
| 2  | John     | [john@example.com](mailto:john@example.com)         |

Each row represents one record.

Each column represents a specific attribute of that record.

Data Types Matter

Unlike spreadsheets, PostgreSQL enforces data types.

sql
CREATE TABLE clients (
    id UUID PRIMARY KEY,
    name TEXT NOT NULL,
    email TEXT UNIQUE NOT NULL,
    phone TEXT,
    brand_info JSONB,
    created_at TIMESTAMP DEFAULT now()
);

Some common data types:

TEXT → Strings
UUID → Unique identifiers
TIMESTAMP → Date and time
BOOLEAN → True or false
JSONB → Structured JSON data
DECIMAL → Money and financial values

One important lesson:

Phone numbers should be stored as TEXT, not numbers.

Why?

Because numbers like:

08012345678

can lose their leading zero when treated as numeric values.

CRUD Operations

Most database interactions fall into four categories.

Create

INSERT INTO clients (name, email)
VALUES ('Chinwuba', 'chinwuba@example.com');

Read

SELECT * FROM clients;

Update

UPDATE clients
SET email = 'new@email.com'
WHERE id = '123';

Delete

DELETE FROM clients
WHERE id = '123';

Always use a WHERE clause when updating or deleting records.

Without it, every row gets modified.

Understanding Relationships

The biggest concept I learned today was relationships.

One-to-Many

One client can have many projects.

Example:

Client
  └── Project A
  └── Project B
  └── Project C

To model this relationship:

CREATE TABLE projects (
    id UUID PRIMARY KEY,
    name TEXT NOT NULL,
    status TEXT NOT NULL,
    stage TEXT NOT NULL,
    budget DECIMAL NOT NULL,
    client_id UUID REFERENCES clients(id),
    created_at TIMESTAMP DEFAULT now()
);

The key piece here is:

client_id UUID REFERENCES clients(id)

This is called a foreign key.

It tells PostgreSQL:

"Every client_id inside projects must exist inside the clients table."

If it doesn't exist, PostgreSQL rejects the insert.

A Database Design Mistake I Made

Initially, I wanted my clients table to contain:

status
stage
budget
invoice

It sounded reasonable until I asked:

"What happens when one client has multiple projects?"

Each project can have:

Different status
Different budget
Different stage

That means those fields describe a project, not a client.

This was my first lesson in data modeling:

Store data where it logically belongs.

Why Foreign Keys Are Important

Foreign keys enforce integrity.

Without them, you could accidentally create a project linked to a client that doesn't exist.

With foreign keys:

client_id UUID REFERENCES clients(id)

PostgreSQL guarantees the relationship remains valid.

The Error That Taught Me the Most

When inserting data, I got this error:

null value in column "id" violates not-null constraint

The reason?

I defined:

id UUID PRIMARY KEY

but never told PostgreSQL how to generate UUIDs automatically.

This taught me an important lesson:

Creating a column and configuring its behavior are two different things.

Final Thoughts

Today's session wasn't really about SQL syntax.

It was about learning how to model real-world relationships in a database.

The biggest takeaway:

A good database design mirrors how things relate in reality.

Clients have projects.

Projects belong to clients.

Relationships matter more than tables.

And every error message is an opportunity to understand how the database thinks.

Next up: inserting data, querying related records, and exploring JOINs.

I built a REST API from scratch with no database here's everything I learned

Chinwuba — Wed, 03 Jun 2026 15:19:52 +0000

I'm 2 weeks into learning Express.js. No bootcamp, no course. Just a roadmap, a goal, and 2-3 hours a day.

This week I hit my Phase 2 checkpoint: build a REST API with at least 5 routes, no database, using in-memory arrays. I built a Velto Projects API — a backend for my real estate web design agency.

Here's everything I learned, including the bugs I hit and why they happened.

The folder structure

Before writing a single line of code, I set up this structure:

velto-api/
├── src/
│   ├── routes/
│   │   └── projects.js
│   ├── middleware/
│   │   ├── logger.js
│   │   └── errorHandler.js
│   ├── data/
│   │   └── store.js
│   └── app.js
├── .env
├── .gitignore
└── package.json

Most beginners throw everything into one file. That works until it doesn't. This structure means each file has one job. When I add Prisma in Phase 3, I only touch store.js and route logic. Everything else stays.

The in-memory store

js
const projects = [
  { id: 1, client: "Apex Realty", status: "in_progress", stage: "design", budget: 2500 },
  { id: 2, client: "Pinnacle Homes", status: "completed", stage: "delivered", budget: 4000 },
];

module.exports = { projects };

Node.js caches modules. Every file that imports this array is referencing the same object in memory. So when a route mutates it, every other file sees the change instantly. That's your fake database behavior right there.

Custom middleware

Logger first:

js
const logger = (req, res, next) => {
  console.log(`[${new Date().toISOString()}] ${req.method} ${req.url}`);
  next();
};

The next() call is everything. Without it the request dies here. Middleware is a chain — each link decides whether to pass the request forward or kill it.

Error handler:

js
const errHandler = (err, req, res, next) => {
  const statusCode = err.status || 500;
  const errMsg = err.message || "Something went wrong";
  res.status(statusCode).json({ statusCode, errorMessage: errMsg });
};

Notice the 4-argument signature — err, req, res, next. That's how Express identifies this as an error handler, not regular middleware. The order matters. err must come first.

The key thing I learned here: always set the HTTP status code with .status() AND include it in the body. The HTTP status is what Postman and browsers read in the header. The body is what your frontend reads. You need both.

The routes

GET all projects with optional filtering:

js
router.get("/", (req, res) => {
  const status = req.query.status;
  const result = status ? projects.filter((i) => i.status === status) : projects;
  res.status(200).json(result);
});

The ternary removes the need for an if/else entirely. When the logic is this simple, one line is cleaner than four.

GET single project:

js
router.get("/:id", (req, res, next) => {
  const found = projects.find((i) => i.id === Number(req.params.id));
  if (!found) {
    return next({ status: 404, message: "Project not found" });
  }
  res.status(200).json(found);
});

req.params.id comes in as a string. Your IDs are numbers. Direct comparison will always fail. Convert with Number() first.

POST a new project:

js
router.post("/", (req, res, next) => {
  const { client, budget, status, stage } = req.body;
  if (!client || !budget) {
    return next({ status: 400, message: "Client and budget are required" });
  }
  const newProject = { id: projects.length + 1, client, budget, status, stage };
  projects.push(newProject);
  res.status(201).json(newProject);
});

Validate before you build. And 201 not 200 — 201 means something was created.

PUT update a project:

js
router.put("/:id", (req, res, next) => {
  const projectIndex = projects.findIndex((i) => i.id === Number(req.params.id));
  if (projectIndex === -1) {
    return next({ status: 404, message: "Project not found" });
  }
  const updated = { ...projects[projectIndex], ...req.body };
  projects[projectIndex] = updated;
  res.status(200).json(updated);
});

The spread operator is the cleanest way to merge objects. { ...existing, ...incoming } means: take everything from the existing project, then overwrite only the fields that were sent. Fields not included in the request body stay untouched.

DELETE a project:

js
router.delete("/:id", (req, res, next) => {
  const projectIndex = projects.findIndex((i) => i.id === Number(req.params.id));
  if (projectIndex === -1) {
    return next({ status: 404, message: "Project not found" });
  }
  projects.splice(projectIndex, 1);
  res.status(200).json({ message: "Project deleted successfully" });
});

splice() mutates the array in place. Don't reassign it. Just call it and let it do its job.

Wiring it all together in app.js

js
require("dotenv").config();
const express = require("express");
const cors = require("cors");
const logger = require("./middleware/logger");
const errorHandler = require("./middleware/errorHandler");
const projectsRouter = require("./routes/projects");

const app = express();
const PORT = process.env.PORT || 5000;

app.use(cors({ origin: "*" }));
app.use(express.json());
app.use(logger);
app.use("/projects", projectsRouter);
app.use(errorHandler);

app.listen(PORT, () => console.log(`App is running on ${PORT}`));

module.exports = app;

The order here is intentional. express.json() must come before your routes — without it req.body is always undefined. errorHandler must come last — it only catches errors that fall through from routes above it.

The bugs that taught me the most

return next(err) vs next(err) — if you don't return, execution continues after passing the error. Your route will try to send two responses and crash.

app.use(logger) vs app.use(logger()) — passing without parentheses hands Express the function to call later. With parentheses you're calling it immediately and passing the return value, which is undefined.

const { projects } = require("../data/store") vs const projects = require("../data/store") — the second one imports the whole module object. Calling .find() on an object will always fail.

What's next
Phase 3: PostgreSQL, Prisma ORM, JWT authentication. Same structure, real database. The in-memory array gets replaced.

CORS Broke My App — Here's What Nobody Told Me

Chinwuba — Tue, 02 Jun 2026 12:06:14 +0000

I was connecting my React frontend to my Express backend and ran into this:

"Access to fetch at 'http://localhost:5000/message' from origin 'http://localhost:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present."

I panicked. I thought my server was broken. It wasn't.

What CORS actually is

CORS stands for Cross-Origin Resource Sharing. An "origin" is your protocol + domain + port combined. localhost:5173 and localhost:5000 are two different origins — even on the same machine.

Browsers have a built-in rule: JavaScript cannot read responses from a different origin unless that origin explicitly allows it. This exists to prevent malicious websites from making requests to other sites using your credentials without you knowing.

The part that confused me

My Express server was receiving the request. It was sending back a response. The browser just refused to give that response to my JavaScript because the response didn't include an Access-Control-Allow-Origin header.

CORS is entirely browser-enforced. That's why Postman never throws CORS errors — it's not a browser.

The fix

bash
npm install cors
javascriptconst cors = require('cors');

app.use(cors({
  origin: 'http://localhost:5173'
}));

That's it. Express now attaches the right header to every response, and the browser releases it to your JavaScript.

What about POST and DELETE?

For anything beyond simple GET requests — or when you add an Authorization header — the browser first sends an OPTIONS "preflight" request asking your server if the operation is allowed. The cors package handles this automatically, so you don't need extra configuration for basic cases.

For production

Never use origin: '*' in production. Lock it to your actual domain:

js
app.use(cors({
  origin: process.env.NODE_ENV === 'production'
    ? 'https://yourdomain.com'
    : 'http://localhost:5173'
}));

CORS isn't complicated once you understand the browser is the one enforcing it — not your server.

How I Stopped Writing Error Handling in Every Route (Express Error Middleware)

Chinwuba — Sun, 31 May 2026 16:10:13 +0000

I used to handle errors like this:

js
app.get('/api/projects/:id', (req, res) => {
  const project = projects.find(p => p.id === Number(req.params.id))
  if (!project) {
    return res.status(404).json({ message: 'Project not found' })
  }
  res.json(project)
})

Fine for one route. But when you have 15 routes, that pattern is scattered across your entire codebase. Change the error format? Edit 15 files. Miss one? Inconsistent API responses.
There's a better way.

What is error middleware?

Express has a special type of middleware built specifically for handling errors. The only thing that makes it different from regular middleware is the number of arguments — it takes four instead of three, with err as the first parameter.

js
app.use((err, req, res, next) => {
  // all errors in your app land here
})

Express identifies it by that signature. If you write three parameters, Express treats it as regular middleware. Four parameters — it's an error handler. That's it.

How errors reach it

You already know next() — it passes control to the next middleware. When you call next() with something inside it, Express skips every remaining route and middleware and jumps straight to your error handler.

js
app.get('/api/projects/:id', (req, res, next) => {
  const project = projects.find(p => p.id === Number(req.params.id))
  if (!project) {
    next(new Error('Project not found')) // triggers error middleware
  }
  res.json(project)
})

Whatever you pass into next() becomes the err object your handler receives.

Building a custom error class

The native Error object doesn't carry a status code. So the first thing I built was a custom class:

js
class AppError extends Error {
  constructor(message, statusCode) {
    super(message)
    this.statusCode = statusCode
    this.isOperational = true
  }
}

module.exports = AppError

isOperational is the important part. It flags errors I deliberately threw — like "project not found" or "missing fields" — as different from unexpected crashes like a database going down. You don't want to expose internal error details to the client. This flag lets you control that.

The centralized handler

js
app.use((err, req, res, next) => {
  const statusCode = err.statusCode || 500
  const message = err.isOperational ? err.message : 'Something went wrong'

  res.status(statusCode).json({
    status: statusCode,
    message: message
  })
}).

Two things to note:
err.statusCode || 500 — if the error doesn't have a status code (unexpected crash), default to 500. If you deliberately threw it with new AppError('...', 404), it'll use 404.

err.isOperational — if it's an error you threw on purpose, send the actual message. If it's something unexpected, send a generic message. Your users don't need to see your stack trace.
Important: this has to go after all your routes. Express reads top to bottom. Register it last.

The full project I built

A Velto Projects API with in-memory data, three routes, and one error handler covering everything:

js
require('dotenv').config()
const express = require('express')
const AppError = require('./AppError')
const app = express()

app.use(express.json())

const projects = [
  { id: 1, clientName: 'Velto', status: 'complete', budget: '300k' },
  { id: 2, clientName: 'Nigachu', status: 'complete', budget: '300k' },
  { id: 3, clientName: 'Leona', status: 'complete', budget: '300k' },
]

app.get('/api/projects', (req, res) => {
  res.json(projects)
})

app.get('/api/projects/:id', (req, res, next) => {
  const project = projects.find(p => p.id === Number(req.params.id))
  if (!project) return next(new AppError('Project not found', 404))
  res.json(project)
})

app.post('/api/projects', (req, res, next) => {
  const { clientName, budget } = req.body
  if (!clientName || !budget) {
    return next(new AppError('clientName and budget are required', 400))
  }
  const newProject = {
    id: projects.length + 1,
    status: 'Ongoing',
    clientName,
    budget
  }
  projects.push(newProject)
  res.status(201).json(newProject)
})

app.use((err, req, res, next) => {
  const statusCode = err.statusCode || 500
  const message = err.isOperational ? err.message : 'Something went wrong'
  res.status(statusCode).json({ status: statusCode, message })
})

app.listen(process.env.PORT || 3000)

What this actually gives you

Every error in the API — wrong ID, missing fields, future database failures — goes to one place. One function controls the entire error response contract. Change the format once, it changes everywhere.
That's the point. Not just catching errors, but owning how your API fails.
I'm 13 days into learning Express.js from scratch, documenting everything as I go.

Environment Variables in Node.js — What They Are, How dotenv Works, and Why Getting This Wrong Can Ruin You

Chinwuba — Sat, 30 May 2026 14:56:55 +0000

If you've been hardcoding API keys in your JavaScript files, you're one public GitHub push away from a bad day.

I'm Jeffrey — I run a web design agency called Velto and I'm currently 16 weeks deep into learning Express.js properly, starting from the JavaScript foundations most tutorials skip.

The problem environment variables solve

When your app runs, it needs configuration: what port to listen on, what database to connect to, what API keys to use. The naive approach is hardcoding these values directly in your code:

js
const PAYSTACK_KEY = "sk_live_xxxxxxxxxxx";
const DB_URL = "postgresql://jeffrey:password@localhost:5432/velto";

This creates two immediate problems.
First, security. If this code ever touches a version control system — especially a public one — those secrets are exposed. GitHub has bots scraping repos for leaked credentials around the clock. This is not paranoia. It happens.
Second, portability. Your local database URL is different from your production database URL. Your dev Paystack key is different from your live one. If these values are in your code, you're changing code every time you deploy. That's a broken workflow.
Environment variables are the solution. Instead of values in your code, you store them in the environment where your code runs — your OS, your shell session, or your hosting platform. Your code reads them at runtime using process.env.

process.env

Node.js exposes all environment variables through a global object called process.env. No imports, always available.

js
console.log(process.env.HOME); // /home/jeffrey
console.log(process.env.PATH); // long string of directories
You can set variables in your terminal session:
bashexport MY_SECRET=hello123
node -e "console.log(process.env.MY_SECRET)" // hello123

But that's tedious and they disappear when you close the terminal. For a real project, you use a .env file.

The .env file

A .env file is a plain text file at your project root. One key=value pair per line:

PORT=3000
DATABASE_URL=postgresql://jeffrey:password@localhost:5432/velto_db
JWT_SECRET=long_random_string_here
PAYSTACK_SECRET_KEY=sk_live_xxxxxx
NODE_ENV=development

Important syntax rules:
No spaces around =
No quotes needed unless the value contains spaces
Comments with #
Never use commas or semicolons

This file never gets committed to version control. Add it to .gitignore before you write anything else.
dotenv — what it actually does

dotenv is a small npm package that reads your .env file and injects the values into process.env at runtime.

bash
npm install dotenv

js
require('dotenv').config(); // This must be the first thing that runs

Here's the internal logic of what .config() does:

Finds .env in the current working directory
Parses each line as KEY=VALUE
For each key, if process.env.KEY is not already set, it adds it
Returns { parsed: { ... } } with what it loaded

That third step is crucial. dotenv does not overwrite existing environment variables. This is intentional. On your hosting platform (Render, Railway, etc.), variables are set at the system level before your app starts. dotenv won't touch them. Your production config always wins.

The .env.example pattern

Since .env is gitignored, you need a way to communicate what variables are required. The standard solution: .env.example. A copy with values blanked out. This one you DO commit.

PORT=
NODE_ENV=
DATABASE_URL=
JWT_SECRET=
PAYSTACK_SECRET_KEY=
CLOUDINARY_CLOUD_NAME=
CLOUDINARY_API_KEY=
CLOUDINARY_API_SECRET=

Anyone cloning the repo knows exactly what to fill in.
A config module — the pattern worth copying
Instead of sprinkling process.env.WHATEVER throughout your codebase, centralize it:

js
// config.js
require('dotenv').config();

const config = {
  port: process.env.PORT || 3000,
  nodeEnv: process.env.NODE_ENV || 'development',
  jwtSecret: process.env.JWT_SECRET,
  databaseUrl: process.env.DATABASE_URL,
  paystackKey: process.env.PAYSTACK_SECRET_KEY,
};

// Crash loud if required variables are missing
const required = ['jwtSecret', 'databaseUrl', 'paystackKey'];
required.forEach((key) => {
  if (!config[key]) {
    throw new Error(`Missing required env variable: ${key}`);
  }
});

module.exports = config;

This pattern:
Gives you one place to see all your config
Validates required variables at startup instead of silently failing later
Makes it easy to set default values
Keeps process.env out of your business logic

The gotchas
Env vars are always strings. MAINTENANCE_MODE=true in your .env is the string "true", not a boolean. Convert explicitly:

js
const maintenanceMode = process.env.MAINTENANCE_MODE === 'true';

dotenv reads once at startup. Change .env, nothing updates until you restart the server.
Don't log process.env. It dumps every secret to your terminal, and in production those logs can be stored and accessed elsewhere.
Always fallback on PORT. Platforms like Render assign PORT dynamically. process.env.PORT || 3000 ensures your app starts whether you're local or on a server.

The build
Here's a minimal Express app that demonstrates all of this:

env-demo/
  .env
  .env.example
  .gitignore
  server.js
  package.json

.env:
PORT=3000
APP_NAME=Velto API
SECRET_MESSAGE=This came from your environment
MAINTENANCE_MODE=false

server.js:
js
require('dotenv').config();

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

app.use(express.json());

const PORT = process.env.PORT || 3000;
const APP_NAME = process.env.APP_NAME || 'My API';
const SECRET_MESSAGE = process.env.SECRET_MESSAGE;
const MAINTENANCE_MODE = process.env.MAINTENANCE_MODE === 'true';

// Maintenance middleware — checks on every request
app.use((req, res, next) => {
  if (MAINTENANCE_MODE) {
    return res.status(503).json({
      status: 'error',
      message: 'Down for maintenance.',
    });
  }
  next();
});

app.get('/', (req, res) => {
  res.json({
    app: APP_NAME,
    environment: process.env.NODE_ENV || 'development',
    status: 'running',
  });
});

app.get('/secret', (req, res) => {
  if (!SECRET_MESSAGE) {
    return res.status(500).json({ error: 'SECRET_MESSAGE not configured.' });
  }
  res.json({ message: SECRET_MESSAGE });
});

app.get('/health', (req, res) => {
  res.json({ status: 'ok', uptime: process.uptime() });
});

app.listen(PORT, () => {
  console.log(`[${APP_NAME}] Listening on port ${PORT}`);
});

Try: flip MAINTENANCE_MODE=true, restart, hit any route. All 503. Flip it back. Normal again. That's real feature-flag behavior with zero code changes.

Remove SECRET_MESSAGE from your .env, restart, hit /secret. The missing variable is handled gracefully. Your app doesn't crash silently or expose undefined as a response.

In production
On Render, you never upload a .env file. Go to your service → Environment tab → add variables there. Render injects them before your app starts. dotenv effectively becomes a no-op in production — variables are already in process.env. That's the design working correctly.

I'm documenting every step of this 16-week Express.js journey publicly. Next up: routing and middleware — the actual backbone of how Express works.

I Built a Contact Form API to Understand Express Request & Response Objects

Chinwuba — Fri, 29 May 2026 19:12:19 +0000

I learn best by building. So instead of reading another article about Express, I built a small Contact Form API with two endpoints and forced myself to use req.body, req.params, req.query, and res.json() in a real context.

Here's what I built and what I actually learned.

The Setup
Two endpoints:

POST /contact — accepts name, email, message. Saves to an array. Returns the created entry.
GET /contacts — returns all submissions, with optional name filtering.

No database. Just an in-memory array. Simple enough to stay focused, real enough to surface actual problems.

req.body — The Envelope
When a client sends a POST request with JSON data, that data lives in req.body. But Express doesn't read it automatically — you have to tell it to:

app.use(express.json())
Without that line, req.body is undefined. I think of it as opening the envelope before reading the letter.

req.query — The Optional Extras
For the GET route, I added filtering by name. Someone hits /contacts?name=Jeffrey and gets back only their submission.

js
if (!req.query.name) {
  res.json(submissions)
} else {
  const found = submissions.filter(sub => sub.name === req.query.name)
  res.json(found)
}

The key lesson: check for undefined, not "". When no query param is sent, req.query.name is undefined — not an empty string.

req.params — The URL Placeholder

I added a third endpoint — GET /contact/:id — to fetch a single submission. The :id is a named placeholder. Whatever the client puts there, Express captures it as req.params.id

One gotcha: req.params.id is always a string. My IDs were numbers. So I had to convert:

js
const id = Number(req.params.id)
const found = submissions.find(sub => sub.id === id)

if (!found) return res.status(404).json({ error: "Not found" })
res.json(found)

Also — use find for single items, not filter. Filter always returns an array. Find returns the object itself.

res.status().json() — Talking Back Properly
Status codes are not optional decoration. They tell the client exactly what happened:

201 — something was created
200 — request succeeded
404 — resource doesn't exist
400 — the client sent bad data

js
res.status(201).json({
  message: "Submission received",
  data: newSubmission
})

Wrapping your response in a { message, data } shape is a clean pattern that scales as your API grows.

What the In-Memory Array Taught Me
Every time the server restarted, the array wiped. Frustrating at first, clarifying after — it made the need for a database concrete, not abstract. You feel the limitation before you learn the solution. That's a better order than most tutorials give you.

If you're learning backend, build something broken first. It teaches faster than building something perfect.

Express Middleware — What It Actually Is and How It Really Works

Chinwuba — Thu, 28 May 2026 18:54:29 +0000

If you've been writing Express apps for a while, you've used middleware. app.use(express.json()), app.use(cors()), the usual suspects. But there's a difference between using something and understanding it. This post is about the latter.

What Express Actually Is

Before middleware makes sense, you need to understand what Express is at its core.

Express is built on top of Node's built-in http module. When you do const app = express(), app is a function — specifically, a function that Node's HTTP server uses as a request handler. When you call app.listen(3000), Express tells Node: "spin up an HTTP server and every time a request comes in, run it through me."

Node's raw HTTP server hands you this:

  http.createServer((req, res) => {
    // no routing
    // no req.body
    // no req.params
    // you're completely on your own
  })

Express wraps that and adds a middleware pipeline on top. That pipeline is the entire point of the framework.

The Pipeline
When a request hits your server, Express doesn't run a single function. It maintains an internal array of middleware functions, built up as you call app.use() and define routes.

  app.use(middlewareA)
  app.use(middlewareB)
  app.use(middlewareC)

Internally: [middlewareA, middlewareB, middlewareC]

When a request arrives, Express starts at index 0 and works forward. next() is the mechanism that moves the index forward. When you call next(), you're saying "increment the pointer, run the next function in the array."

This is why order matters — you're building the array sequentially, and requests walk through it in the same sequence.

The Middleware Function

  function middleware(req, res, next) {}

req — Not Node's raw request object. Express extends it. On top of req.url, req.method, req.headers, you get req.params, req.query, req.body, req.ip, req.path. Express added all of those.

res — Same story. Express extends Node's raw response. That's where res.json(), res.send(), res.status(), res.redirect() come from. None of those exist in raw Node.

next — A function Express generates internally and passes to each middleware. It knows the current position in the middleware array and how to advance it.

How next() Really Works

Basic call — move forward:

  next()

Advances to the next middleware. Nothing else.

Call with an argument — trigger error handling:

  next(new Error('something failed'))

When you pass anything into next, Express skips every remaining normal middleware and route handler, jumping straight to your error-handling middleware. This is how you centralize error handling instead of writing res.status(500) in fifty different places.

One thing that trips people up — never call next() after you've already sent a response:

// dangerous
res.send('Done')
next() // still runs, can cause "cannot set headers after they are sent"

// correct
return res.send('Done') // function exits, nothing else runs

app.use() vs app.get()

These are not the same thing.

app.use(path, middleware) — matches any HTTP method, and matches the path as a prefix. app.use('/api', handler) fires for /api, /api/users, /api/anything/nested. The path is optional — omit it and it defaults to /, meaning it matches every incoming request.

app.get(path, handler) — matches only GET requests, and the path must match exactly.

app.use() is for broad middleware. app.get/post/put/delete is for actual route handling.

How express.json() Works Internally

When a POST request comes in with a JSON body, that body arrives as a raw stream of bytes. Node doesn't collect or parse it automatically. express.json() does three things:

Checks the Content-Type header. If it's not application/json, it does nothing and calls next() immediately.
Reads the entire body stream into memory, collecting all the chunks.
Once the stream ends, it runs JSON.parse() on the collected data and attaches the result to req.body.

If the JSON is malformed, it calls next(err) with a 400 error automatically. You don't have to handle that yourself.

  app.use(express.json({ limit: '10kb' })) // reject large payloads

Middleware Scope

Middleware doesn't have to be global. Three levels:

Application level — runs for everything:

  app.use(express.json())
  app.use(logger)

Route level — only runs for specific routes:

  app.get('/dashboard', requireAuth, (req, res) => {
    res.send('Private')
  })

Router level — scoped to a group of routes:

  const router = express.Router()
  router.use(requireAuth)
  router.get('/profile', handler)
  router.get('/settings', handler)
  app.use('/user', router)

Now every route under /user requires auth, without touching global middleware.

Mutating req — The Pattern You'll See Everywhere

req is just a JavaScript object. It lives for the lifetime of a single request. Any middleware can add properties to it, and anything downstream can read those properties.

  function attachUser(req, res, next) {
    const token = req.headers.authorization
    const decoded = verifyToken(token)
    req.user = decoded
    next()
  }

  app.get('/profile', attachUser, (req, res) => {
    res.json(req.user) // available because middleware put it here
  })

This is how authentication works in every serious Express app. Decode the token, attach the user, every route handler just reads req.user.

Error Middleware

  app.use((err, req, res, next) => {
    res.status(500).json({ error: err.message })
  })

The four-parameter signature isn't a convention — Express checks function.length (the number of declared parameters) to decide if something is error middleware. If it sees 4, it registers it as an error handler. If it sees 3, it's normal middleware.

This is why you must declare all four parameters even if you don't use next in your error handler. And it goes at the very bottom of your file, after all routes.

The Full Picture

  Incoming request
        |
        ↓
  [express.json()]   reads body, attaches to req.body, calls next()
        |
        ↓
  [logger]           logs method + url, calls next()
        |
        ↓
  [requireAuth]      checks token
        |              no token → res.status(401) ← STOPS HERE
        ↓              token exists → calls next()
  [route handler]    does the actual work, sends response

If any middleware sends a response, the chain stops. If any middleware calls next(err), it jumps to the error handler. If every middleware calls next() and no route matches, Express sends a default 404.

Middleware isn't magic. It's a function array, a pointer, and a convention. Once you see it that way, debugging Express apps becomes a lot less frustrating — you can always trace exactly where in the chain a request gets stuck or misdirected.

Express.js Routing — A Practical Guide with a Real Project

Chinwuba — Wed, 27 May 2026 15:12:30 +0000

If you've just started with Express, routing is the first concept that makes everything feel real. This isn't a theory post — we're going to break it down and build something with it.

What is Routing

Routing is how your Express server decides what to do when a request comes in. Every request has two things — an HTTP method and a URL path. Routing matches those two things to a specific piece of code.

HTTP Methods

Before writing any routes, understand what each method represents:
GET → Fetch data
POST → Create something new
PUT → Update something
DELETE → Remove something

These aren't Express rules. They're the internet's conventions. Express just gives you a clean way to hook into them.

Writing Your First Routes

javascript
const express = require('express');
const app = express();

app.use(express.json());

app.get('/users', (req, res) => {
  res.send('All users');
});

app.post('/users', (req, res) => {
  const newUser = req.body;
  res.send(`Created: ${newUser.name}`);
});

app.put('/users', (req, res) => {
  res.send('Updated user');
});

app.delete('/users', (req, res) => {
  res.send('Deleted user');
});

app.listen(3000);

Same URL, four completely different behaviors based on the method. That's the core idea.

Route Params

What if you need to target a specific user, not all of them? Route params handle that.

javascript
app.get('/users/:id', (req, res) => {
  const userId = req.params.id;
  res.send(`User: ${userId}`);
});

The colon makes :id a dynamic placeholder. Hit /users/42 and Express captures 42 and hands it to you via req.params.id.

Query Strings

Query strings are the ?key=value parts of a URL. They're optional extras used for filtering or sorting.

javascript
app.get('/users', (req, res) => {
  const { role, active } = req.query;
  res.send(`Role: ${role}, Active: ${active}`);
});

The difference between params and query strings is simple — params are required for the route to match, query strings are optional.

Route Grouping with Router()

As your app grows, dumping every route into app.js becomes unmanageable. Router() lets you split routes by feature into separate files.

routes/users.js

javascript
const express = require('express');
const router = express.Router();

router.get('/', (req, res) => res.send('All users'));
router.get('/:id', (req, res) => res.send(`User ${req.params.id}`));
router.post('/', (req, res) => res.send('Created'));
router.delete('/:id', (req, res) => res.send(`Deleted ${req.params.id}`));

module.exports = router;

index.js
javascript
const express = require('express');
const UserRouter = require('./routes/users');

const app = express();
app.use(express.json());
app.use('/users', UserRouter);

app.listen(3000);

Everything in UserRouter is now prefixed with /users automatically. You create a separate file for each feature — users, posts, products — and app.js stays clean.
Building a Real Example
Let's wire this up with a fake database — just a JavaScript array — so the routes actually do something.

javascript
const express = require('express');
const router = express.Router();

let users = [
  { id: 1, name: "Jeffrey" },
  { id: 2, name: "Chidi" },
  { id: 3, name: "Amara" }
];

// GET all users
router.get('/', (req, res) => {
  res.json({ users });
});

// GET single user
router.get('/:id', (req, res) => {
  const userId = Number(req.params.id);
  const user = users.find(u => u.id === userId);
  if (user) {
    res.json(user);
  } else {
    res.status(404).send('User not found');
  }
});

// POST create user
router.post('/', (req, res) => {
  const newUser = { id: users.length + 1, name: req.body.name };
  users.push(newUser);
  res.json(newUser);
});

// PUT update user
router.put('/:id', (req, res) => {
  const userId = Number(req.params.id);
  const user = users.find(u => u.id === userId);
  if (user) {
    user.name = req.body.name;
    res.json(user);
  } else {
    res.status(404).send('User not found');
  }
});

// DELETE user
router.delete('/:id', (req, res) => {
  const userId = Number(req.params.id);
  users = users.filter(u => u.id !== userId);
  res.send(`Deleted user ${userId}`);
});

module.exports = router;

A few things worth noting from building this:

The client should never send an ID on POST — your server generates it. Use users.length + 1 or a proper ID generator like uuid in production.
When you filter an array in your DELETE route, reassign it back — users = users.filter(...) — otherwise nothing actually gets deleted.
Always convert req.params.id to a Number before comparing with ===. Route params come in as strings by default, and "1" === 1 is false in JavaScript.
The Mental Model
Method + URL = one specific action

GET /users → list all
POST /users → create one
GET /users/:id → get one
PUT /users/:id → update one
DELETE /users/:id → delete one
This pattern is REST. Almost every API you'll ever build or consume follows it. Once it's in your head, reading and building APIs becomes second nature.

What Express.js Is Hiding From You: I Built a Raw Node.js Server From Scratch

Chinwuba — Tue, 26 May 2026 19:29:36 +0000

We've all done it.(if you haven't jokes on you)

JavaScript
const express = require('express');
const app = express();
app.use(express.json());

app.get('/', (req, res) => res.send('Hello World'));
app.listen(3000);

Five lines of code, and boom—you have a fully functioning backend server. Express.js makes routing, parsing, and sending HTTP headers look trivial.

Today, I decided to take off the path never threaded on. I built a server using nothing but Node’s native http module. No third-party frameworks, no npm packages, no abstractions.

Here is what I discovered when I moved closer to the metal.

The Bare-Minimum Architecture
When you use raw Node, your entire server runs inside a single callback function passed to http.createServer(). There is no app.get() or app.post(). Every single request—regardless of the URL path or the HTTP method—hits the exact same bottleneck.

JavaScript
const http = require('http');

const app = http.createServer((req, res) => {
  // Every single request passes through here
});

app.listen(3000, () => console.log("Server running on port 3000"));

This immediately forced me to confront two things that Express completely abstracts away.

The Browser is Sneaky (/favicon.ico) When I set up a basic console.log(req.url) and hit localhost:3000 in Chrome, my terminal registered two separate requests.

The first was my expected target: GET /.
The second was a ghost request: GET /favicon.ico.

As it turns out, modern web browsers automatically fire off a hidden, secondary request behind your back to look for the website's tab icon. Express quietly ignores or handles this via middleware, but when you are dealing with raw Node, you are exposed to every single network event.

The Danger of Leaving a Browser on Read In Express, when you finish a route, you type res.send(). In raw Node, if you simply log the request and don't explicitly terminate the interaction, your browser tab will spin forever.

An HTTP interaction is a strict contract: a request must receive a formal response. To break the silence without Express, you have to write low-level transactions manually:

JavaScript
res.writeHead(200, { 'Content-Type': 'text/plain' });
res.write("Welcome to the home page");
res.end(); // If you forget this, the browser hangs forever

Building a Manual Router
Without app.get() or app.post(), how do you handle routing? You don't use a router object; you use plain old JavaScript conditional logic.

I had to build an if/else control-flow chain evaluating req.url and req.method. It looks like this:

JavaScript
if (req.url === "/" && req.method === "GET") {
  res.writeHead(200, { "Content-Type": "text/plain" });
  res.write("Welcome to the homepage!");
  res.end();
} else if (req.url === "/about" && req.method === "GET") {
  res.writeHead(200, { "Content-Type": "text/plain" });
  res.write("About Page");
  res.end();
} else {
  res.writeHead(404, { "Content-Type": "text/plain" });
  res.write("404 Not Found");
  res.end();
}

Seeing this made me realize that Express routers are essentially beautifully packaged switch statements matching strings under the hood.

The Final Boss: Parsing a POST Body

The biggest eye-opener of this experiment was handling incoming request data (like a JSON object or form data sent via a POST request).

In Express, you just type req.body, and your data is waiting for you. In raw Node, req.body is completely undefined.

Why? Because Node.js handles data using Streams. If a client sends a massive chunk of data (like an image upload), holding the entire file in the server's RAM all at once could cause a massive memory bottleneck or crash the system entirely.

Instead, Node handles incoming data like a conveyor belt, breaking the request payload into tiny binary packets called chunks. To get the full dataset, you have to listen to network events, collect the pieces as they fly in, and stitch them back together manually:

JavaScript
if (req.url === '/echo' && req.method === 'POST') {
  let body = [];

  // 1. Catch the binary packets as they arrive over the network
  req.on('data', (chunk) => {
    body.push(chunk);
  });

  // 2. Wait for Node to signal that the data stream is completely finished
  req.on('end', () => {
    // 3. Glue the binary buffers together and translate them into a string
    const fullBody = Buffer.concat(body).toString();

    // 4. Send the response *inside* the event listener
    res.writeHead(200, { 'Content-Type': 'text/plain' });
    res.write(`Echoed data: ${fullBody}`);
    res.end();
  });
}

Why the Architecture Matters

Because data streams in over time, you cannot handle a POST request synchronously. If you put res.end() outside of those event listeners at the bottom of the block, Node's asynchronous engine will fire off an empty response to the client before the data chunks have even finished downloading.

When you call app.use(express.json()) in an Express application, the library is writing this exact req.on('data') loop behind the scenes, catching the buffers, converting them to strings, running JSON.parse(), and cleaning up the interface for you.

Conclusion: Why You Should Try This
Is anyone going to build a massive enterprise API using raw Node.js if/else blocks? Absolutely not. Express, Fastify, and NestJS exist for a reason—they keep our code clean, maintainable, and dry.

However, spending an afternoon wrestling with network streams, manual header configurations, and hanging browser threads changes the way you look at frameworks. It bridges the gap between writing code and understanding system architecture.

If you haven't done it yet, open a blank folder, write a naked server.js file, and see what happens. It’s the best way to truly appreciate the tools we use every day.

DEV Community: Chinwuba

From Raw SQL Strings to Type-Safe Queries: How I Learned Prisma ORM

The problem Prisma solves

What Prisma actually is

Project setup

The Schema

Migrations

The Prisma Client singleton

The routes

clients.js

projects.js

index.js

index.js.

Testing in Postman

Continuation — Tables, CRUD, and Foreign Keys

Creating a table

A few things worth noting:

CRUD in plain SQL

Relating tables with foreign keys

What's next

Databases — Here's What Actually Clicked

Tables are not spreadsheets

Relationships are just foreign keys

Order matters on inserts

JOIN pulls data across tables

What I'm building toward

Understanding PostgreSQL Tables, Relationships, and Foreign Keys: A Beginner's Journey

What Is PostgreSQL?

Understanding Tables

Data Types Matter

CRUD Operations

Create

Read

Update

Delete

Understanding Relationships

One-to-Many

A Database Design Mistake I Made

Why Foreign Keys Are Important

The Error That Taught Me the Most

Final Thoughts

I built a REST API from scratch with no database here's everything I learned

The folder structure

The in-memory store

Custom middleware

The routes

Wiring it all together in app.js

The bugs that taught me the most

CORS Broke My App — Here's What Nobody Told Me

What CORS actually is

The part that confused me

What about POST and DELETE?

For production

How I Stopped Writing Error Handling in Every Route (Express Error Middleware)

What is error middleware?

How errors reach it

Building a custom error class

The centralized handler

The full project I built

What this actually gives you

Environment Variables in Node.js — What They Are, How dotenv Works, and Why Getting This Wrong Can Ruin You

The problem environment variables solve

process.env

The .env file

The .env.example pattern

I Built a Contact Form API to Understand Express Request & Response Objects

Express Middleware — What It Actually Is and How It Really Works

What Express Actually Is

Mutating req — The Pattern You'll See Everywhere

Error Middleware

Express.js Routing — A Practical Guide with a Real Project

What is Routing

HTTP Methods

Writing Your First Routes

Route Params

Query Strings

Route Grouping with Router()

A few things worth noting from building this:

What Express.js Is Hiding From You: I Built a Raw Node.js Server From Scratch

The Final Boss: Parsing a POST Body

`JOIN` pulls data across tables