DEV Community: Bishal Singh

I Built My First Backend API in One Evening — Here's

Bishal Singh — Fri, 29 May 2026 12:43:23 +0000

__I am learning to code. My tutor taught me how to create an HTTP server using Express, and the same evening he gave me a task — build a basic TODO app using that knowledge.
My first thought was — "Is that even possible with this little knowledge?"
The answer, as it turns out, is yes. Completely yes.
Here is everything I learned, explained the way I wish someone had explained it to me.

First, What Even Is a Backend?
Before I wrote a single line of code, I had to understand what a backend actually does.
Think about a restaurant.
You sit down. A waiter comes. You say — "Get me a burger." The waiter goes to the kitchen, gets it, and brings it back.
Now map that to the internet —

You are the browser
The waiter is Express
The kitchen is your backend logic
The burger is the data

When you type a URL in your browser and hit enter, you are placing an order. The server's job is to take that order, do something, and bring back a response.
That's it. That's the entire internet in one analogy.

req and res — What Do They Actually Mean?
When I first saw req in Express code, I thought it meant require. It doesn't. That was my first mistake.
Here's what they actually mean —
req (request) — everything the client sends TO the server. Like when you place a food order with all your details — extra cheese, no onions, table number 5. That whole thing is the request.
res (response) — what the server sends BACK to the client. The food, or maybe "sorry, that's not available."
A simple test — if someone fills a login form with their email and password and hits submit, which one carries that data to the server?
req. Because the user is sending data to the server.

HTTP Methods — The Types of Requests
Not all requests are the same. When a client talks to a server, it has to say what type of request it is making. These are called HTTP Methods.
MethodReal Life MeaningGETI want to read or fetch somethingPOSTI want to create or send something newPATCHI want to update something partiallyDELETEI want to delete something
When you type a URL in your browser and hit enter, your browser is automatically making a GET request — because you just want to see something.
And yes — when you add a new todo, that's a POST — because you are sending new data to the server.

Designing the API Before Writing Code
Here is something I did not expect — you can design your entire backend before writing a single line of code.
A TODO app needs four operations. One for each letter of CRUD — Create, Read, Update, Delete.
GET /todos → fetch all todos
POST /todos → add a new todo
PATCH /todos/:id → mark a todo done or undone
DELETE /todos/:id → remove a todo
See that :id in the last two? That's a dynamic part of the URL. It means the client tells the server which specific todo to update or delete, right in the URL itself — like /todos/3 to target the todo with id 3.

req.body vs req.params
When the server receives a request, it needs to read the data the client sent. There are two main places data can live —
req.body — data the client sends privately inside the request. Like a form submission. You cannot see it in the URL.
req.params — data that is visible in the URL itself. Like /todos/3 — that 3 is a param. You read it as req.params.id.
A simple way to remember it —
Where is the data?req.bodyHidden inside the requestreq.paramsVisible in the URL
So for each route in our TODO app —
RouteUsesGET /todosNothing — just send back all todosPOST /todosreq.body — to get the todo textPATCH /todos/:idreq.params — to know which todoDELETE /todos/:idreq.params — to know which todo

The Code — Every Line Explained
Setup
javascriptconst express = require('express')
const app = express()
const port = 3000
app.use(express.json())

let todos = []

require('express') — import the Express library
express() — create the actual app object
express.json() — this is important. When the client sends data, it arrives as raw text. This line converts it into a proper JavaScript object so req.body actually works. Without it, req.body would be undefined.
let todos = [] — our in-memory "database". Just a plain array. Data resets when the server restarts, but that's fine for a basic app.

GET — Fetch All Todos
javascriptapp.get('/todos', function(req, res) {
res.json(todos)
})
When someone hits GET /todos, send back the entire todos array. No input needed. Simple.

POST — Add a New Todo
javascriptapp.post('/todos', function(req, res) {
const text = req.body.text
const newTodo = {
id: todos.length + 1,
text: text,
done: false
}
todos.push(newTodo)
res.json(newTodo)
})

req.body.text — grab the text the user typed from the request body
id: todos.length + 1 — dynamic id. If 0 todos exist, id is 1. If 1 exists, id is 2. And so on.
done: false — every new todo starts as not completed
todos.push(newTodo) — add it to the array
res.json(newTodo) — send back the created todo

DELETE — Remove a Todo
javascriptapp.delete('/todos/:id', function(req, res) {
const id = Number(req.params.id)
const index = todos.findIndex(function(todo) {
return todo.id === id
})
todos.splice(index, 1)
res.json({ message: "Deleted Successfully" })
})

Number(req.params.id) — req.params always gives a string. But our todo ids are numbers. So "1" === 1 is false in JavaScript — the todo would never be found. Number() converts it properly.
findIndex — goes through the array and returns the position of the matching todo (like 0, 1, 2)
splice(index, 1) — removes 1 item at that position

PATCH — Mark Done or Undone
javascriptapp.patch('/todos/:id', function(req, res) {
const id = Number(req.params.id)
const todo = todos.find(function(todo) {
return todo.id === id
})
todo.done = !todo.done
res.json(todo)
})

todos.find — unlike findIndex, this returns the actual todo object, not its position
!todo.done — the ! means "opposite of". So false becomes true and true becomes false. One line to flip the status.

Starting the Server
javascriptapp.listen(port, function() {
console.log(Example app listening on port ${port})
})
This starts the server on port 3000. Your app is now running at http://localhost:3000.

find vs findIndex — What's the Difference?
This confused me at first, so let me explain it clearly.
Imagine your todos array as a row of boxes —
Position: 0 1 2
{ id:1, text:"..." } { id:2, text:"..." } { id:3, text:"..." }
find — goes through each box and returns the actual box that matches. You get the object itself.
findIndex — goes through each box and returns the position number of the matching box (0, 1, 2...).
Use find when you want to read or update the object. Use findIndex when you want to remove it with splice — because splice needs to know where to cut.

A Mistake I Made — And Why It Matters
The most frustrating bug I hit was this — my PATCH and DELETE routes were returning errors even though my code looked correct.
The fix was one small thing —
javascript// Wrong — id is a string "1"
const id = req.params.id

// Correct — id is now a number 1
const id = Number(req.params.id)
req.params always gives you a string. But todo ids in our array are numbers. So comparing "1" === 1 always returns false — the todo is never found, and the server crashes.
Always convert req.params.id with Number() when comparing with numeric ids.

Testing With Postman
Once your server is running with node server.js, you cannot test POST, DELETE, or PATCH from a browser — the browser only makes GET requests when you type a URL.
That's where Postman comes in. It lets you make any type of HTTP request and see the response.
Here's what each test looks like —
GET — method: GET, url: http://localhost:3000/todos → returns [] initially
POST — method: POST, url: http://localhost:3000/todos, body (raw JSON): { "text": "Buy groceries" } → returns the created todo
DELETE — method: DELETE, url: http://localhost:3000/todos/1 → returns { "message": "Deleted Successfully" }
PATCH — method: PATCH, url: http://localhost:3000/todos/1 → returns the todo with done flipped to true

The Pattern Behind Every Route
After writing all four routes, I noticed something. Every single route follows the exact same pattern —

Get the input → req.body or req.params
Do something → read, create, update, or delete from the array
Send a response → res.json() That's it. Every backend route you will ever write follows this pattern. Just with different logic in the middle.

What I'm Learning Next
This basic app has one big limitation — every time the server restarts, all the data is gone. That's because we're storing todos in a plain JavaScript array in memory.
The next steps are —

Nodemon — automatically restarts the server when you save a file, so you don't have to do it manually every time
A real database — like MongoDB, so todos persist even after restarting
A frontend — connecting this backend to an actual HTML page so real users can interact with it

Final Thoughts
When my tutor assigned this, I genuinely didn't know if I could do it. I didn't even know what req meant a few hours earlier.
But breaking it down step by step — the restaurant analogy, understanding req and res, designing the routes before coding, writing one route at a time — made it completely approachable.
If you're a beginner reading this, the biggest thing I'd tell you is this — don't try to understand everything at once. Understand one concept, then the next. The code will start making sense faster than you think.
The whole backend is just 40 lines of code. But understanding why every line is there? That's the real learning.

Written by a beginner, for beginners. Still learning — one route at a time.

async/await Finally Made Sense When I Stopped Treating It as Something New

Bishal Singh — Tue, 26 May 2026 07:36:37 +0000

It is not a replacement for promises. It is just promises wearing a cleaner outfit. Here is how that clicked for me.

If you have already understood promises — what they are, why they exist, and how errors travel through a chain — then async/await is genuinely one step away. Not a big step. One small step.

The problem is most explanations treat it like an entirely new concept. It is not. Once I understood that, everything fell into place.

What promises already solved
Before getting into async/await, it helps to remember what promises fixed. Callbacks nested badly and errors stayed isolated — each function had no idea when something else in the chain failed. Promises fixed both of those things.

But promises still had their own friction. Every step needed a .then. Reading a chain of five operations still required some mental effort to follow. It worked, but it did not feel natural.

async/await did not come to fix a broken system. It came to make an already good system easier to read.

Two keywords. One job each.
async does one thing — it marks a function as one that contains waiting inside it. And it makes that function always return a promise, even if you return a plain value.

await does one thing — it pauses that line, waits for the promise to resolve, and hands you the actual value directly. Then moves to the next line.

That is the entire feature. Two keywords, two jobs.

The moment it clicks
Look at these two blocks of code. They do the exact same thing.

promises
fetchUser()
.then(user => fetchPosts(user))
.then(posts => fetchComments(posts))
.catch(err => handleError(err))
async/await
async function getData() {
try {
const user = await fetchUser()
const posts = await fetchPosts(user)
const comments = await fetchComments(posts)
} catch(err) {
handleError(err)
}
}
Same logic. Same behavior. Same error handling. The second one just reads like normal top to bottom code. No chaining, no callbacks, no mental gymnastics.

JavaScript is converting your async/await into promises behind the scenes anyway. You are not writing something different. You are writing something cleaner.

A question I had about async functions
When I first saw this:

example
async function greet() {
return "hello"
}

greet().then(val => console.log(val)) // "hello"
My first question was — does console.log actually print "hello" here? Yes it does. The async keyword secretly wraps your returned value in a resolved promise. The .then just unwraps it and gives you the value back.

In real code you would never write it that way. You would just use await inside another async function to get the value cleanly. But that example showed me something important — async functions always return a promise, even when it does not look like they do.

Error handling is just try/catch
With promises you used .catch at the end of a chain. With async/await you use the same try/catch you already know from regular JavaScript.

error handling
async function getData() {
try {
const user = await fetchUser()
const posts = await fetchPosts(user)
} catch(err) {
console.log(err) // catches anything that fails
}
}
Same behavior as .catch on a promise chain. If anything inside the try block fails, the error travels straight to catch. Nothing isolated, nothing silent.

The one performance mistake worth knowing early
Because await pauses execution, it is easy to accidentally write slow code without realizing it.

slow — runs one by one
const user = await fetchUser()
const posts = await fetchPosts()
const photos = await fetchPhotos()
If these three do not depend on each other, you are making them wait in a queue for no reason. The fix is Promise.all — it runs all of them at the same time and waits for all of them together.

fast — runs all at once
const [user, posts, photos] = await Promise.all([
fetchUser(),
fetchPosts(),
fetchPhotos()
])
Same result. Much faster. This is the one thing worth keeping in the back of your mind as you start building real projects.

The one line summary
async/await is just promises, written so it reads like normal top to bottom code. Nothing new underneath. No new mental model required. If promises made sense, this is just the cleaner version of the same thing.

The syntax will become muscle memory as you build things. What matters now is knowing you are not learning something entirely new — you are just learning a better way to write something you already understand.

I Finally Understood Callbacks and Promises. Here is What Actually Clicked.

Bishal Singh — Sun, 24 May 2026 10:24:41 +0000

I had read about callbacks and promises multiple times. I understood the words. But I kept feeling like I was missing something underneath — like everyone else had a mental model I did not have yet.

Then two things clicked, and everything made sense. This post is about those two things.

First: both are async. That is not the difference.
When I first compared callbacks and promises, I thought the problem with callbacks was timing — that functions were somehow "not ready" when they needed to be. That was wrong.

Both callbacks and promises handle timing just fine. That is literally what async code is for. The problem with callbacks has nothing to do with when things run. It is about what happens when things go wrong — and how readable your code stays as it grows.

The waiter analogy that actually made sense
Think about ordering food at a restaurant.

With callbacks, you hand the waiter a note with instructions: "when the food is ready, bring it to table 4, then refill the water, then bring the bill." You have handed over control. The waiter runs your instructions. You are just waiting.

With promises, the waiter gives you a buzzer and walks away. When it goes off, you decide what to do next. You are the one in control.

Callbacks hand control away. Promises hand it back to you. That is the real difference.

Problem one: nesting
When you need multiple async operations in sequence, callbacks nest inside each other. Every new step lives inside the previous one.

callback hell
fetchUser(function(user) { fetchPosts(user, function(posts) { fetchComments(posts, function(comments) { // your actual logic is buried here }) }) })
This is not just ugly. It is genuinely hard to debug. You cannot easily see the flow, and changing one step risks breaking the ones around it.

Promises flatten this completely:

promises
fetchUser()
.then(user => fetchPosts(user))
.then(posts => fetchComments(posts))
.catch(err => handleError(err))
Same logic. Flat, readable, easy to follow from top to bottom.

Problem two: functions do not know when others fail
This was the one I almost missed — and it is arguably more important than the nesting issue.

In a callback chain, each function is isolated. It only knows about itself. So if something breaks in the middle, the functions around it have no idea. The error does not travel. It just disappears silently unless you manually handle it at every single level.

silent failure
fetchUser(function(user) {
fetchPosts(user, function(posts) { // fails here
fetchComments(posts, function() { // never runs
// nobody knows what went wrong
})
})
})
With promises, a failure anywhere in the chain automatically travels down to the nearest .catch. You do not have to do anything extra. One handler covers everything.

error travels automatically
fetchUser()
.then(user => fetchPosts(user)) // fails here
.then(posts => fetchComments()) // skipped
.catch(err => handleError(err)) // caught here, automatically
With callbacks, one forgotten error handler means a silent failure. With promises, errors bubble down on their own.

So to summarize what actually changed
Promises were not invented to replace callbacks for style reasons. They were invented because two specific things were genuinely painful:

One — deeply nested callbacks made code hard to read and maintain as projects grew. Two — errors in a callback chain were isolated, invisible, and easy to miss entirely.

Promises fix both. The chain stays flat, and failures propagate automatically.

The syntax will become second nature as you build things. What matters first is understanding why promises exist at all — because once that is clear, the rest starts making sense on its own.

Written by someone who just figured this out, for anyone else who is still figuring it out.