Backend Engineering from Zero to Production

1. The Restaurant Analogy 🍽️

You sit in the dining area, look at the menu, and tell the waiter your order. You never walk into the kitchen. The kitchen cooks, follows the rules, and fetches ingredients from the storeroom.

A web application works the same way:

You never need to know how the kitchen works to enjoy your meal, and the kitchen never lets customers walk in and cook for themselves. That separation is the whole idea of a backend.

In short: Frontend is what users see. Backend is the hidden part that does the real work.

2. Client and Server 🖥️

A client is anything that asks for something, like your browser or a phone app.

A server is a computer that stays on and connected, waiting for requests and answering them.

The client sends a request, the server processes it, and the response goes back to be shown to the user.

A server isn't magic. It's just a computer running a program that listens for requests. Here is a complete one in a few lines of Node.js (we will build this properly on Day 11 and Day 12):

Run it and open http://localhost:3000. Your browser is the client, this little program is the server.

Key insight: "Server" can mean the program that answers requests or the machine it runs on. Both meanings are common.

In short: Client asks, server answers. That's the request-response model, and nearly everything online uses it.

3. What Lives Where? 🗺️

Here's a twist that surprises most beginners: the backend is also a client. When it needs data, it sends its own request to the database server. So one server can act as both client and server at the same time.

In short: Frontend shows, backend decides, database remembers.

4. Static vs Dynamic 📄

A static server sends stored files exactly as they are. Everyone who asks for about.html gets the same file.

A dynamic server has extra software, usually an application server and a database, that builds the page before sending it.

Instagram can show your feed because a backend builds it for you each time. Sites like Wikipedia are mostly a few templates plus a huge database, rather than millions of separate pages written by hand.

In short: Static means the same file for everyone. Dynamic means built fresh per request, and that needs a backend.

5. Why Not Let the Frontend Talk to the Database Directly? 🔐

It sounds simpler to skip the backend. Here's why we don't:

One honest nuance: services like Firebase or Supabase do let apps talk to a database-like service. But that works because a secured gateway enforces rules on the server side, not because the browser reaches a raw database. A backend is still doing the guarding.

Key insight: Anything shipped to the user's device can be read and changed by the user. Keys and rules belong on the server.

In short: The backend is the gatekeeper. It protects data, enforces rules, and lets many apps share one system.

6. What Breaks Without This? 💥

Imagine putting this in your frontend JavaScript:

Now open the site, press Ctrl + U (View Source) or check the Sources tab in DevTools. The password is right there for everyone to read. Anyone can now connect to your database and read, change or delete everything.

The fix is the backend: the frontend calls GET /api/orders, and only the server, which nobody else can see, holds the database password.

Common mistakes

• Thinking "nobody will look at my JavaScript". Anyone can, in one click.
• Hiding a secret in an environment variable that the build tool still ships to the browser.
• Believing a request is safe because it came from your frontend. Requests can be sent by anyone.

🧪 Try it yourself

1. Open any website, press F12, and go to the Network tab. Reload the page. Every line you see is the client sending a request and the server answering.
2. Click one request and look at Response. That is exactly what the backend sent back.
3. Open the Sources tab and browse the JavaScript files. Everything there is public, which is why secrets never go in the frontend.

🎯 Day 1 in one line

Frontend shows things, backend makes decisions, and the database stores data. You never trust the client with the keys.

You type youtube.com into your browser. How does your request find the right server, out of millions of machines on the internet?

Let's break it down.

1. IP Address: Where Is the Server? 📍

An IP address identifies a network interface and helps route data to its destination.

Think of it as a building's address. Without it, the internet would not know where to deliver your request.

Your browser uses the server's IP address to communicate with it.

The example above is an IPv4 address (four numbers separated by dots). You will also see longer IPv6 addresses, such as 2001:db8::1. They do the same job, there are just far more of them available.

Key insight: Computers do not find each other by name. They find each other by IP address.

In short: An IP address tells the network where the destination is.

2. DNS: Finding the IP Address 🔎

Humans remember domain names. Networks use IP addresses to route traffic.

DNS (Domain Name System) translates a domain name into its associated IP address.

Think of DNS as your phone's contact list. You search for "Mom" instead of remembering her number. DNS lets you type youtube.com instead of remembering a string of digits.

DNS answers are usually cached for a while, by your browser, your operating system and the DNS resolver. That is why the lookup is often instant the second time you visit a site.

In short: DNS answers the question "Which IP belongs to this domain?"

3. Ports: Which Application Gets the Traffic? 🚪

A single server can run multiple applications at the same time: a web server, a Node.js API, a database, and more. Ports help the operating system direct incoming traffic to the right service.

An IP address and a port are often written together:

• IP = Building address
• Port = Specific room inside the building

When you leave the port out of a URL, the browser uses the default. So https://example.com really means https://example.com:443.

In your own backend, you choose the port your app listens on:

Key insight: The IP gets traffic to the right machine. The port gets it to the right program on that machine.

In short: A port tells the server which service should receive the traffic.

4. What Happens When You Open a Website? 🌐

Let's say you visit https://example.com.

1. DNS lookup: Your browser finds the IP address.
2. Connection: Your device establishes a connection to the server.
3. Port: The connection reaches the HTTPS service, typically on port 443.
4. Request: Your browser sends an HTTP request.
5. Response: The server sends back a response.

All of this usually happens in a fraction of a second.

In short: Find the IP, connect to the right port, send a request, get a response.

5. Localhost vs Public IP 🏠

When developing a backend, you will often see:

• localhost refers to your own device. It usually points to the loopback address 127.0.0.1 (or ::1 in IPv6).
• 3000 is the port where your application is listening.

A public IP can make a server reachable over the internet, subject to network and firewall configuration.

Common mistakes

• Opening localhost:3000 on your phone to reach the server on your laptop. On your phone, localhost means the phone itself. Use your laptop's local network IP instead (if your firewall and server settings allow it).
• Forgetting the port. http://localhost goes to port 80, not to your app on port 3000.
• Two apps on one port. Only one program can listen on a given port at a time. If you see an error like EADDRINUSE, something is already using that port.
• Thinking a domain is the server. The domain is just a name. DNS points it to an IP, and the server lives at that IP.

6. The Big Picture 🧠

That's the foundation of how your backend becomes reachable over a network.

🧪 Try it yourself

1. Do a DNS lookup in your terminal and see the IP addresses behind a domain:

   bash

   nslookup youtube.com

   You may see several IPs. Large sites use many servers.

2. Start the Express server above, then open http://localhost:3000 in your browser. Now try http://localhost:3001. Nothing is listening there, so the connection fails.

3. Watch a full request with curl. The -v flag shows the connection to the IP and port, then the request and response:

   bash

   curl -v https://example.com

🎯 Day 2 in one line

DNS turns a domain name into an IP address, the IP address tells you where the server is, and the port tells you which service on that server should receive your request.

1. The Shop With Self-Written Price Tags 🏷️

Imagine a shop where customers write the price on an item themselves, and the cashier charges whatever the tag says.

Someone picks up a laptop, writes ₹1, and walks away with it.

Absurd? That's exactly what happens when a backend trusts the price sent by the frontend.

In short: The backend must check the real price, never trust the customer's tag.

2. What the Frontend Is Responsible For 🎨

The frontend runs on the user's device. Its job is to provide the experience:

• Layout, design and animations
• Clicks, forms and navigation
• Instant feedback, like "Invalid email"
• Managing local UI state (is this menu open? which tab is selected?)
• Sending requests to the backend and displaying the results

Frontend validation improves usability, but it does not guarantee security. It's there to help honest users, not to stop dishonest ones.

In short: The frontend makes things convenient. It cannot enforce security on its own.

3. What the Backend Is Responsible For ⚙️

The backend runs on a server you control. Its job is correctness, security and business logic:

In short: The backend enforces the rules that matter.

4. Why You Can Never Trust the Client 🚫

Everything running on a user's device is under their control:

• Browser DevTools can inspect frontend code.
• The Network tab exposes every request and response.
• Requests can be replayed or modified using external tools.
• Anyone can call a publicly reachable API without using your frontend at all.

An attacker does not need to use your nice checkout form. They can send a request directly to your server.

This line between the untrusted client and your server is called the trust boundary. Every request that crosses it must be treated as untrusted input.

Key insight: Your backend can't tell whether a request came from your beautiful UI or from someone typing it by hand. So it must check everything, every time.

In short: Never assume a request is safe just because your frontend generated it.

5. Four Things You Must Never Trust the Client For 🛑

A. Validation

The frontend checks whether an email looks valid. The backend validates it again before processing the request. Client-side checks can be bypassed, so security must not depend on them.

B. Prices and money

Never trust a price or discount supplied by the client.

The client should send the product ID and quantity. The backend retrieves the authoritative price and calculates the total.

C. Permissions

Hiding an Admin button does not prevent someone from calling an admin API directly. The backend must check permissions on every relevant request and deny access by default.

D. Identity

A request claiming userId: 42 or role: "admin" proves nothing.

The backend must verify the user's session or token and establish their identity and permissions using trusted server-side data.

In short: Validate data, calculate money, enforce permissions and establish identity on the server.

6. Secrets Never Belong in the Frontend 🔑

Frontend code is delivered to the user's device, so anything embedded in it can potentially be inspected.

For example, Vite exposes variables prefixed with VITE_ to client-side code:

Never put database passwords, private API keys or signing secrets in those variables. If the frontend needs a secret operation, it should call your backend, which uses the secret securely.

In short: If a secret reaches the browser, treat it as exposed.

7. Who Decides What? ⚖️

The rule: The frontend can guide the user, but only the backend can enforce trusted decisions.

8. What Breaks Without This? 💥

Imagine your checkout request contains:

A user opens DevTools, changes the price to 1 and resends the request. If the backend blindly trusts that value, the order could be processed at the wrong price.

The correct approach:

1. Receive only the product ID and quantity.
2. Retrieve the current authoritative price from trusted server-side data.
3. Validate the quantity and check stock.
4. Calculate the total on the server.
5. Process the order using the validated values.

Here's what that looks like in Express:

The same principle applies to discounts, permissions and user identity.

Common mistakes

• Sending price, discount or isAdmin from the frontend and using it as-is.
• Checking permissions only in the UI ("the button is hidden, so it's safe").
• Reading userId from the request body instead of from the verified session or token.

🧪 Try it yourself

1. Open any shop or form on a site you own, press F12 → Network, and submit something.
2. Right-click the request → Copy as cURL. Paste it in a terminal and change a value before sending.
3. Notice that the server can't tell the difference. That's why every check must live on the backend.

🎯 Day 3 in one line

The frontend provides the experience. The backend enforces the rules. Never trust the client to make decisions that affect security, money or data.

How does a chat message appear instantly? How does Razorpay notify your backend that a payment succeeded?

Different problems need different ways to communicate. Let's understand them.

1. The Ways to Communicate 🗣️

Think of communication like everyday life:

Each solves a different communication problem.

In short: There is no universal best method. Choose based on who needs to communicate and how frequently.

2. HTTP: The Default 🧾

Most web interactions follow a simple pattern:

1. The client sends a request.
2. The server processes it.
3. The server returns a response.

Example: You open a product page, and your backend returns the product details.

The exchange is straightforward, but the server cannot use an ordinary completed HTTP request to spontaneously deliver a new message to the browser.

What if the client needs updates without refreshing? That's where other techniques help.

In short: HTTP request and response is the foundation of most web communication.

3. Polling vs Long Polling 🔁

Imagine tracking a food delivery order.

Polling: Your app asks the server every 2 seconds, "Where is my order?"

If 1,000 clients do this, they can generate around 500 requests per second, even when nothing changes.

Long polling: Your app asks once, and the server holds the request until an update is available or a timeout occurs. The client then makes another request.

This reduces repeated empty responses, but holding many requests open still consumes server resources.

Use cases: Basic live dashboards, delivery tracking, or environments where persistent connections are unavailable.

In short: Polling repeatedly asks. Long polling waits for an answer before asking again.

4. SSE: The Radio 📻

Server-Sent Events (SSE) allow a server to send a continuous stream of events to a browser over HTTP.

The client opens a connection. The server sends updates whenever something changes.

• Direction: Server to client
• Supports automatic reconnection in browsers using EventSource
• Best for notifications, live feeds, progress updates and AI text streaming

Example: An AI response appears word by word as the server generates it.

The client can still send separate HTTP requests, but the SSE connection itself is one-way.

In short: Use SSE when the server needs to push updates and the client rarely needs to send messages through the same connection.

5. WebSockets: The Phone Call 📞

WebSockets provide a persistent, two-way communication channel. After the connection is established, both client and server can send messages independently.

• Direction: Both ways
• Low overhead for repeated messages
• Supports text and binary data
• Requires connection management and reconnection logic

Example: In a chat app, you send a message and receive incoming messages without repeatedly requesting updates.

In short: Use WebSockets when both sides need frequent, real-time communication.

6. Webhooks: The Doorbell 🔔

Webhooks are different. They typically let one service notify another server about an event.

Example: A customer pays through Razorpay.

1. Your backend creates a payment order.
2. The payment provider processes the payment.
3. The provider sends an event to your webhook URL.
4. Your backend verifies the webhook signature.
5. Your backend safely updates the order status.

Even if the customer closes the browser, the provider can still notify your server.

Important: Webhooks can be retried or delivered more than once. Your handler must verify authenticity and safely handle duplicate events. Processing the same event twice must be harmless.

In short: Webhooks let services notify your backend when something happens, without your backend repeatedly asking.

7. gRPC: Service to Service ⚙️

gRPC is a framework commonly used for communication between backend services.

It uses Protocol Buffers by default to define structured messages and serialize them efficiently. It commonly runs over HTTP/2 and supports streaming.

Example: An order service communicates with an inventory service to check stock. Both sides share a .proto file that defines exactly what a stock request and reply look like.

gRPC is particularly useful when services need strongly defined contracts and efficient communication. Browsers generally need a compatible intermediary such as gRPC-Web.

In short: gRPC is a strong option for structured, efficient communication between backend services.

8. Which One Should You Use? 🧭

Key insight: Start with ordinary HTTP. Add another communication method only when your requirements justify it.

Common mistakes

• Using WebSockets for everything. This is the most common beginner mistake. A product page does not need a live connection.
• Skipping webhook signature checks. Anyone can send a POST to a public URL.
• Not handling duplicate webhooks. The same event can arrive twice, and must not ship two orders.

9. What Breaks Without the Right Approach? 💥

Imagine a chat app built only with normal HTTP requests. A new message might not appear until the user refreshes or requests updates again.

Or imagine a payment system that relies on the browser to tell the backend that payment succeeded. The customer closes the tab, and the notification never arrives.

The solution is to choose the correct communication pattern. For payment confirmation, a verified webhook can notify your backend independently of the browser.

🧪 Try it yourself

1. Stream SSE in the terminal. Run the SSE server above, then:

   bash

   curl -N http://localhost:3000/api/notifications/stream

   -N turns off buffering, so events appear live.

2. Spot a WebSocket. On a web app with live chat, filter the Network tab to WebSocket connections and click one to see its messages.

🎯 Day 4 in one line

HTTP handles request and response. Polling and streaming techniques deliver updates. WebSockets enable two-way real-time communication. Webhooks notify servers about events. gRPC connects services efficiently.

Imagine you're building an e-commerce application.

Should everything live in one application, or should you split it into multiple independent services?

Let's understand the trade-offs.

1. The Single Kitchen: Monolith 🍳

Imagine a restaurant where one kitchen handles everything: orders, cooking, billing and inventory.

A monolithic backend works similarly. Different features live inside one application, which is built and deployed as a unit.

For example, your e-commerce backend might contain:

• Authentication
• Products
• Cart
• Orders
• Payments

All these modules run as part of the same application.

In short: One application, multiple responsibilities.

2. Separate Kitchens: Microservices 🏪

Now imagine a restaurant chain where separate teams handle billing, inventory and orders through independently operated systems.

With microservices, an application is split into smaller services. Each service owns a specific business capability and can be developed and deployed independently.

An e-commerce system might have:

• Auth Service
• Product Service
• Order Service
• Payment Service
• Notification Service

These services communicate over a network, and each can have its own codebase and data ownership.

In short: Multiple independent services, each responsible for a specific capability.

3. What's the Actual Difference? ⚖️

The communication row is the big one. Compare:

The second version must handle timeouts, errors and a service that is down. The first one doesn't.

In short: Microservices provide flexibility, but they also introduce distributed-system complexity.

4. What Happens When Traffic Increases? 📈

Suppose your e-commerce application receives 100,000 requests, and most of them are for product browsing.

• In a monolith, you can run multiple instances of the application, but each instance generally contains all its modules. You may end up scaling more of the application than necessary.
• With microservices, you could scale the Product Service independently from the Order Service.

For example:

But there's a catch: independent scaling is useful only when the architecture and workload justify the extra complexity.

In short: Microservices can scale individual capabilities independently. A monolith can also scale by running multiple instances.

5. What Happens When Something Fails? 🧯

Imagine the Notification Service goes down while a customer places an order.

In a well-designed microservices architecture, the order may still succeed even if sending the notification fails.

However, this isolation does not happen automatically. Services must be designed to handle failures, timeouts and retries correctly. In code, that means deciding which steps are critical and which are not:

In a monolith, a notification-related bug could also affect the application if it disrupts shared resources or crashes the process. But a well-designed monolith can isolate failures too.

In short: Architecture alone does not guarantee reliability. How you design failure handling matters.

6. When Should You Choose Each? 🧭

Choose a monolith when:

• You're building your first product or startup
• The team is small
• Requirements are still changing
• You want simpler development and deployment
• You don't yet have a clear reason to split services

Consider microservices when:

• Different business capabilities need independent scaling
• Multiple teams need independent ownership and releases
• The system has clear service boundaries
• You can support distributed tracing, monitoring and failure handling
• The benefits outweigh the operational cost

In short: Start simple. Split services when you have a concrete reason, not just because the architecture looks impressive.

7. Monolith Doesn't Mean Messy 🧩

A common misconception: a monolith does not have to mean messy code.

You can build a modular monolith, where authentication, products, orders and payments are separated into well-defined modules but deployed as one application.

Each module exposes a small public interface, and other modules use only that:

This gives you simpler operations while keeping the code organized. If a module later needs to become an independent service, a clear boundary makes that transition easier.

In short: Good architecture starts with clear boundaries, not with more servers.

Common mistakes

• Starting with microservices for a small app "because big companies do it".
• Splitting without clear boundaries. Services that must call each other for every request give you the costs of both designs.
• Assuming microservices are automatically more reliable. Without timeouts and retries, one slow service can drag down others.
• Letting a monolith turn into a ball of mud. Any module reaching into any other module's internals makes change painful.

🧪 Try it yourself

Feel the difference between a function call and a network call:

1. Save this as inventory.js and run it with node inventory.js (in a project with Express installed and "type": "module" in package.json):

   js

   import express from "express"; const app = express(); app.get("/stock/:id", (req, res) => res.json({ id: req.params.id, available: 5 })); app.listen(3001, () => console.log("Inventory service on port 3001"));

2. Call your tiny "service" from another terminal:

   bash

   curl http://localhost:3001/stock/42

3. Stop the service with Ctrl+C and run the same curl again. You get a connection error. That is the kind of failure every microservice has to plan for, and a direct function call inside a monolith never sees.

🎯 Day 5 in one line

A monolith is one deployable application. Microservices are independently deployable services. Start with the simplest architecture that meets your needs.

Phase 1 complete! 🎯 You now know how the web fits together: clients and servers, how requests find a server, who decides what, how frontends and backends communicate, and how a backend can be structured. Phase 2 begins next.

You call an API, but how does the backend know what resource you want and what action you're trying to perform?

Let's break down the basics.

1. Anatomy of a URL 🧭

Consider this API URL:

Here's what each part means:

Notice there is no port in this URL. As you saw in Day 2, https uses port 443 by default.

The URL tells the client where to send the request and identifies the resource or information being requested.

In short: A URL identifies the destination and the requested resource.

2. HTTP Methods: What Action Do You Want? 🛠️

The same resource can support different operations. Imagine /products/42:

Here is what a real PATCH request looks like on the wire:

Only the price is sent. With PUT, you would send the whole product, because PUT replaces it.

The method and path work together to describe the operation. In Express, each method gets its own route:

Key insight: Same path, different method, completely different action.

In short: The path identifies the resource. The method describes the intended operation.

3. Path Parameters: Which Specific Resource? 🎯

Path parameters identify a particular resource or a position within a resource hierarchy.

Fetch user 17.

Fetch order 92 belonging to user 17.

In Express, you can access them using req.params. You define the route with a placeholder:

For /products/42, the backend receives:

Remember, a path parameter is just input. The backend must still validate it and check whether the user is allowed to access that resource.

In short: Path parameters identify which resource the request refers to.

4. Query Parameters: How Should Results Be Selected? 🔍

Query parameters commonly control filtering, searching, sorting and pagination. They come after the ?, and each pair is separated by &.

This could mean:

• Show products in the phones category.
• Sort by price.
• Return page 2.

In Express, access them through req.query:

Query values usually arrive as strings, so validate and convert them when necessary. A query value can even be missing, or arrive as an array if the same key is repeated.

In short: Path parameters identify a resource. Query parameters commonly control which results you want and how they are returned.

5. Can We Use Both Together? 🤝

Absolutely. Consider:

One request, multiple pieces of information.

6. A Common Beginner Mistake ⚠️

These two URLs are not equivalent:

The first uses a path parameter. The second uses a query parameter.

Both designs can be valid, but your backend must define and implement the expected route. In Express, routes match on the path only, so /products?id=42 is handled by app.get("/products"), not by app.get("/products/:id").

Also, never assume that a valid-looking ID grants access to the corresponding resource. Changing /users/17/orders to /users/18/orders must not show someone else's orders.

Common mistakes

• Treating params as numbers. req.params.id and req.query.page are strings. "2" + 1 is "21", not 3.
• Skipping validation because "the frontend only sends valid IDs". Anyone can type any URL (remember Day 3).
• Skipping the access check. A valid ID only says which resource, not who is allowed to see it.
• Using GET to change data. GET should retrieve. Use POST, PUT, PATCH or DELETE for changes.
• Mixing up PUT and PATCH. PUT replaces the whole thing. PATCH updates only the fields you send.

🧪 Try it yourself

JSONPlaceholder is a free fake API for practice. It pretends to save changes but never actually does.

1. Path parameter, fetch one post:

   bash

   curl https://jsonplaceholder.typicode.com/posts/1

2. Query parameter, filter posts by user:

   bash

   curl "https://jsonplaceholder.typicode.com/posts?userId=1"

3. A different method on the same path:

   bash

   curl -X PATCH https://jsonplaceholder.typicode.com/posts/1 \ -H "Content-Type: application/json" \ -d '{"title":"Updated title"}'

Notice the quotes around the URL in step 2. Without them, your shell may treat ? or & as special characters.

🎯 Day 6 in one line

HTTP methods describe the intended action, paths identify resources, path parameters specify particular resources, and query parameters refine the request.

When your frontend sends data to a backend, how does the server know what the data means and how to interpret it?

Let's break it down.

1. HTTP Headers: Labels on a Package 🏷️

Headers carry metadata about an HTTP request or response.

Think of them as a label attached to a package. They describe the package, but they aren't the contents inside it.

Common headers

Headers can appear in both requests and responses.

Example:

This tells the receiver that the body contains JSON data.

What a full request looks like

Here is a raw HTTP request with its headers and body. A blank line separates the headers from the body:

Header names are case-insensitive, so content-type and Content-Type mean the same thing.

In short: Headers describe a message and provide information needed to interpret or handle it.

2. Request Body: The Actual Data 📦

When creating a user, placing an order, or updating a profile, the client often sends data in the request body.

Example:

The backend receives this data and processes it according to the application's rules.

Not every request needs a body. A typical GET request retrieves data without one.

In Express, you turn on a body parser so the JSON body appears on req.body:

In short: The request body carries the data being submitted to the server.

3. Content-Type: What Format Is the Body In? 📄

The same information can be represented in different formats.

JSON

URL-encoded form data

Multipart form data

Commonly used when submitting form fields along with files, such as a profile picture. In a real request, this header also includes a boundary=... value that separates the parts. Browsers and HTTP libraries add it for you.

Comparing the three

These formats aren't interchangeable. The server needs to interpret the body according to its actual format.

In short: Content-Type tells the receiver how the message body is represented.

4. When the Content-Type Is Wrong ❌

Imagine sending this body, but declaring the wrong type:

The server may treat the body as plain text instead of parsing it as JSON.

Depending on the server's implementation, the expected data may not be available in the format the application needs, or the request may be rejected. For example, express.json() only parses JSON content types, so req.body.quantity will not be there. Some APIs reject the request with 415 Unsupported Media Type.

In short: The body format and Content-Type must agree, and the server must support that format.

5. Content-Type vs Accept 🔄

These two headers are easy to confuse.

Example:

The client sends JSON and indicates that it can accept a JSON response.

Content-Type also appears on responses. When the server replies, it uses Content-Type to describe the body it is sending back.

Key insight: One describes the data being sent. The other expresses a preference for the response format.

6. Putting It All Together 🛒

Imagine adding a product to your cart.

Request:

Here's what each part contributes:

This is how the frontend would send that request with fetch:

Key insight: The backend must still validate the incoming data. Correct formatting does not make the data trustworthy.

Common mistakes

• Passing a plain object as the fetch body without JSON.stringify(). The browser sends the text [object Object] instead of JSON.
• Declaring Content-Type: application/json but sending form data, or the other way round.
• Setting Content-Type by hand when uploading FormData. This drops the boundary, so let the browser set it.
• Forgetting the body parser (express.json()), then wondering why req.body is empty.
• Mixing up Content-Type (what I'm sending) and Accept (what I want back).
• Trusting the body just because it parsed correctly.

🧪 Try it yourself

1. Look at real response headers. The -i flag shows them above the body:

   bash

   curl -i https://example.com

   Find the Content-Type line. For a web page, it will be something like text/html.

2. Send JSON to an echo service that shows what it received:

   bash

   curl -X POST https://httpbin.org/post \ -H "Content-Type: application/json" \ -d '{"productId": "p123", "quantity": 2}'

   The json field in the reply shows your parsed body. Now remove the -H line and run it again. Without it, curl labels the body as application/x-www-form-urlencoded by default, so the server tries to read your JSON as form data. Compare the form and json fields in the two replies.

3. Open DevTools, go to the Network tab, and click any request. Under Headers, compare the request headers with the response headers.

🎯 Day 7 in one line

Headers describe the message, the body carries the data, and Content-Type tells the receiver how to interpret it.

Your API returns 404, 401, or 500.

What do these numbers actually mean, and when should your backend return each one?

Let's break it down.

1. What Are HTTP Status Codes? 🔢

An HTTP status code is a three-digit number sent by the server to indicate the result of a request.

It is the very first thing in a response, on the status line:

Status codes are grouped into five categories:

As a backend developer, you'll mostly work with 2xx, 4xx, and 5xx.

In short: Status codes tell the client how the server handled a request.

2. 2xx: Success ✅

The request succeeded.

A successful request does not always mean the server returns data. 204 is a good example.

In Express, you set the code with res.status():

3. 3xx: Redirection 🔁

The client needs to follow a redirect or use a different location.

Example: A browser requests an old URL, and the server redirects it to a new URL. The new address goes in the Location header:

In short: Redirection helps clients find resources or reuse cached responses.

4. 4xx: Client Errors ⚠️

The request cannot be fulfilled because of something about the request or the client's permissions.

401 vs 403: the classic mix-up

Think of an office building. No badge at the door is a 401. A valid badge that doesn't open the server room is a 403.

In short: 4xx codes indicate that the request cannot be fulfilled as submitted. The exact code depends on the situation.

5. 5xx: Server Errors 🔥

The server failed to fulfil an otherwise valid request.

Example: Your API depends on another service, which fails to respond before the gateway's timeout. The client receives 504 Gateway Timeout.

In short: 5xx codes indicate a server-side or upstream failure, not necessarily a bug in your own application code.

6. Which Status Code Should I Return? 🧭

A simplified guide for an endpoint that requires login. Real APIs may order these checks differently, and any unexpected failure becomes a 500.

Two more to keep in mind: 409 Conflict when the request clashes with existing data (like a duplicate email), and 429 Too Many Requests when a client hits your rate limit.

7. Common Mistakes Backend Developers Make 🚫

• Returning 200 OK for every outcome, including failures.
• Using 401 when the user is authenticated but lacks permission. Usually, that calls for 403.
• Returning 500 for ordinary validation errors that should be represented by an appropriate 4xx code.
• Returning 201 Created when no resource was created.
• Returning detailed stack traces or internal error information to clients.

Choose a status code that accurately represents the outcome.

8. A Real API Example: Registration 📝

Imagine a registration endpoint: POST /users.

Key insight: The status code should describe what actually happened, not simply whether your code executed.

🧪 Try it yourself

1. Ask a test service to return any status code you like. The status line is the first line of the output:

   bash

   curl -i https://httpbin.org/status/404 curl -i https://httpbin.org/status/201

2. See a redirect. GitHub sends plain http:// requests to HTTPS, and Location shows where:

   bash

   curl -I http://github.com

3. Open DevTools, go to the Network tab, and reload a page. Look at the Status column. You may spot 304 for files your browser already had cached.

🎯 Day 8 in one line

2xx means success, 3xx means redirection, 4xx means a client-side request problem, and 5xx means a server-side or upstream failure.

Your browser loads a website with dozens of images, scripts, and API calls.

How does HTTP handle all those requests? And what makes HTTPS secure?

Let's break it down.

1. First, What Is HTTP? 🌐

HTTP (Hypertext Transfer Protocol) is the protocol clients and servers use to exchange requests and responses.

Your frontend sends a request. The server processes it and returns a response.

But websites became more complex. One page could require dozens of resources, and performance became increasingly important.

That's why HTTP evolved.

The meaning of a request like GET /products stays the same in every version. What changes is how the messages travel.

In short: HTTP defines how clients and servers communicate. Newer versions improve how that communication works.

2. HTTP/1.1: One Connection, Limited Concurrency 🚶

HTTP/1.1 introduced persistent connections, allowing multiple requests to reuse a TCP connection instead of opening a new one every time.

However, responses on a single connection generally need to be delivered in order. A slow response can delay later responses on that connection.

Think of a single checkout lane. If one customer takes a long time, everyone behind them waits.

Browsers often work around this by opening multiple connections to the same server (commonly around six per host).

Example: A product page requests an HTML document, several images, CSS, and JavaScript files. The browser manages these requests using a combination of persistent and multiple connections.

In short: HTTP/1.1 supports connection reuse, but handling many concurrent resources can be less efficient.

3. HTTP/2: More Efficient Communication 🚀

HTTP/2 introduced multiplexing, allowing multiple request and response streams to share a single connection.

It also uses binary framing and compresses HTTP headers with HPACK.

Instead of needing separate connections for many concurrent requests, a browser can send multiple streams over one TCP connection.

Example: A page requests 20 product images. HTTP/2 can carry those requests concurrently over one connection.

The remaining problem: TCP head-of-line blocking

One limitation remains: HTTP/2 typically runs over TCP. If a TCP packet is lost, delivery of later data on that connection can be delayed while the missing data is recovered.

TCP delivers bytes strictly in order. So even if the lost packet belonged to image 3, data for images 4 to 20 can be held back until it is resent. All streams share that one ordered pipe.

In short: HTTP/2 improves concurrency and reduces overhead, but it still inherits TCP-level head-of-line blocking.

4. HTTP/3: Built on QUIC ⚡

HTTP/3 changes the underlying transport.

Instead of TCP, it uses QUIC, which runs over UDP and provides reliable streams, encryption, and connection management.

HTTP/3 allows independent streams to make progress without one lost packet blocking all the others at the transport layer.

It can also improve connection establishment and connection migration when network conditions change.

Example: You're using a website on your phone and switch from Wi-Fi to mobile data. QUIC can support connection migration, provided the connection and network conditions permit it.

In short: HTTP/3 uses QUIC to improve transport behavior, particularly for multiplexing and changing network conditions.

5. HTTP/1.1 vs HTTP/2 vs HTTP/3 📊

Here is how the layers stack up:

Important: HTTP/3 is not automatically faster in every situation. Actual performance depends on the network, server, client, and workload.

6. HTTP vs HTTPS 🔒

HTTP defines how messages are exchanged. HTTPS is HTTP protected by TLS.

With ordinary HTTP, traffic is not encrypted by the protocol. It is like sending a postcard: anyone handling it along the way can read it.

With HTTPS, TLS provides:

Example:

In short: HTTPS protects HTTP communication against eavesdropping and tampering and helps authenticate the server.

7. What Is TLS? 🤝

TLS (Transport Layer Security) is the security protocol used by HTTPS.

At a high level:

1. The client connects to the server.
2. They negotiate security parameters and establish shared cryptographic keys.
3. The client verifies the server's certificate.
4. HTTP messages are exchanged over the protected connection.

Who handles TLS?

You generally don't need to implement TLS yourself. Your web server, reverse proxy, hosting platform, or load balancer usually handles it.

When a proxy decrypts the traffic before passing it to your app, we say it terminates TLS:

In this setup, your app may see a plain http request even though the user connected over HTTPS. In Express, you tell the app to trust the proxy's forwarded information:

In short: TLS creates a secure channel through which HTTP messages can travel.

8. What Should a Backend Developer Know? 🧰

When building and deploying APIs:

• Use HTTPS for production traffic.
• Understand whether your server or reverse proxy terminates TLS.
• Know which HTTP versions your infrastructure supports.
• Don't assume every client supports HTTP/3.
• Remember that HTTPS encrypts traffic in transit, not data automatically stored in your database.
• Never treat HTTPS as a replacement for authentication, authorization, or input validation.

Key insight: HTTPS protects the road, not the destination. Once data reaches your server, your own code is responsible for checking and protecting it.

Common mistakes

• Thinking HTTPS tells you who the user is. TLS lets the client verify the server. You still need login and permissions.
• Loading http:// scripts or images on an https:// page (mixed content). Browsers block or warn about this.
• "Fixing" certificate errors by turning off verification in code, for example with NODE_TLS_REJECT_UNAUTHORIZED=0. This removes the protection HTTPS gives you.

🧪 Try it yourself

1. Ask for HTTP/2 and check what the server agrees to. The first line shows the version used:

   bash

   curl -I --http2 https://example.com

   If the server supports it, you'll see HTTP/2 200.

2. Watch the TLS handshake. The lines starting with * describe the TLS version and the server's certificate:

   bash

   curl -v https://example.com

3. In your browser, open DevTools, go to the Network tab, right-click a column header and enable Protocol. Reload the page and you'll see values like http/1.1, h2 or h3.

🎯 Day 9 in one line

HTTP/1.1 uses persistent connections, HTTP/2 adds multiplexing over TCP, HTTP/3 uses QUIC over UDP, and HTTPS uses TLS to secure HTTP communication.

You log in to a website, close the browser, and open it again later. Sometimes you're still logged in.

How does the server remember you between requests?

And why does your browser sometimes block an API request even when the backend is working perfectly?

Let's understand three important concepts.

1. The Problem: HTTP Is Stateless 🧠

HTTP is a stateless protocol.

This means the server doesn't automatically remember previous requests.

Imagine:

1. You log in to an application.
2. The server verifies your credentials.
3. You request your profile.
4. The server receives another request.

How does it know that the second request belongs to the user who just logged in?

HTTP doesn't automatically maintain that relationship. We need a mechanism to maintain state across requests.

In short: HTTP treats each request independently. Cookies and sessions help applications maintain state.

2. Cookies: Small Data Stored in the Browser 🍪

A cookie is a small piece of data that a server asks the browser to store.

The server sends a Set-Cookie response header:

The browser stores the cookie and automatically sends it with matching future requests:

1. Server sends a cookie.
2. Browser stores it.
3. Browser makes another request to the matching domain and path.
4. Browser includes the cookie in the request's Cookie header.

Important cookie attributes

That last row explains the opening question: a cookie with a long Max-Age survives closing the browser, so you stay logged in.

In Express, setting a cookie looks like this:

In short: Cookies allow browsers to store and automatically send small pieces of data with requests.

3. Sessions: How the Server Remembers You 🗂️

A session is a way for the server to maintain information about a user's interaction across multiple requests.

A common session-based approach works like this:

Example:

Browser cookie:

Server-side session data:

The browser holds the session ID. The actual session data is maintained on the server.

The session store could be memory, Redis or a database. Memory is fine for learning, but it is wiped when the server restarts and isn't shared between multiple servers.

In short: The cookie carries the session ID. The server uses that ID to find the user's session.

4. Cookies vs Sessions 🏨

These are related, but they aren't the same thing.

Think of a hotel: the cookie is your room key card. The session is your actual booking information stored in the hotel's system.

Because the session lives on the server, logging out can truly end it. The server deletes the session, and the old session ID becomes useless.

In short: Cookies are a browser storage mechanism. Sessions are a way to maintain server-side state.

5. CORS: Why Is the Browser Blocking My API? 🚧

Imagine:

• Your frontend runs at http://localhost:3000
• Your backend runs at http://localhost:5000
• You try to call http://localhost:5000/api/users

The browser may block your frontend JavaScript from accessing the response.

Why? Because these are different origins.

An origin consists of:

• Scheme: http or https
• Host: localhost
• Port: 3000 or 5000

Even though both applications run on localhost, their ports are different, so their origins are different.

This is where CORS comes in. CORS stands for Cross-Origin Resource Sharing.

It is a browser-enforced mechanism that allows servers to specify which origins can access their responses.

This is the error you'll typically see in the browser console:

In short: CORS controls which cross-origin responses browser JavaScript is allowed to access.

6. How CORS Works ✈️

Your frontend sends a request to another origin. The backend can respond with a header such as:

This tells the browser that the specified origin is allowed to access the response.

If the origin is not allowed, the browser prevents JavaScript from accessing the response.

One important detail: preflight requests

For certain cross-origin requests, the browser first sends an OPTIONS request. This is called a preflight request. It asks the server whether the actual request is permitted.

The server responds with the appropriate CORS headers:

If the preflight succeeds, the browser proceeds with the actual request.

Not every cross-origin request requires a preflight:

In short: CORS uses HTTP headers, and sometimes an OPTIONS preflight, to control cross-origin browser access.

7. CORS Is Not Authentication 🛑

Suppose your backend allows:

Does this mean everyone is authorized to access your API? No.

CORS is not an authentication or authorization mechanism. It primarily controls whether browser JavaScript from another origin can read a response.

A request made through Postman, curl or another backend server isn't restricted by browser CORS enforcement:

Your backend must still authenticate users, authorize operations and protect sensitive resources.

In short: CORS controls browser access to responses. It does not secure your API by itself.

8. Cookies and CORS Together 🤝

Now imagine your frontend and backend run on different origins, and you want to use session cookies.

Three things matter:

1. The browser must be configured to include credentials in the cross-origin request.
2. The backend must allow the specific frontend origin and credentials.
3. The cookie's SameSite, Secure and other attributes must permit it to be sent.

For example, with fetch:

And the backend needs appropriate CORS response headers, including:

In Express, the cors package sets these headers and answers preflights for you:

Key insight: When credentials are allowed, the server cannot use * as the allowed origin.

One more nuance: app.example.com and api.example.com are different origins but the same site. If your frontend and API are on completely different sites (say myapp.com and myapi.net), the cookie usually needs SameSite=None; Secure, and some browsers restrict these third-party cookies further.

In short: Cross-origin cookie-based sessions require coordination between browser settings, cookie attributes and backend CORS configuration.

Common mistakes

• Using Access-Control-Allow-Origin: * together with credentials. The browser rejects it.
• Forgetting credentials: "include" in fetch, so cross-origin cookies are never sent or stored.
• Trying to "fix" CORS in frontend code. CORS is configured on the server.
• Leaving HttpOnly off session cookies, so any injected script can read them.
• Using an in-memory session store in production with multiple servers.

🧪 Try it yourself

1. Open DevTools on a site you're logged in to. In Chrome, go to Application → Cookies (in Firefox, Storage → Cookies). Check the HttpOnly, Secure and SameSite columns.

2. In the Console of the same site, type document.cookie. Cookies marked HttpOnly won't appear in the result.

3. Run a local API and pretend to be a browser sending a preflight:

   bash

   curl -i -X OPTIONS http://localhost:5000/api/users \ -H "Origin: http://localhost:3000" \ -H "Access-Control-Request-Method: POST" \ -H "Access-Control-Request-Headers: Content-Type"

   Look for the Access-Control-Allow-* headers. Then try an Origin your server doesn't allow.

🎯 Day 10 in one line

Cookies store data in the browser, sessions maintain state on the server, and CORS controls which cross-origin responses browser JavaScript can access.

Ever wondered what actually happens when you write app.get("/users", ...) in Express?

What if I told you that Node.js can create an HTTP server without Express?

Let's build the understanding from scratch.

1. What Is an HTTP Server? 🖥️

An HTTP server is a program that listens for incoming HTTP requests and sends back HTTP responses.

In Node.js, you don't need Express to create one. Node provides a built-in module called http. It gives you the basic tools to:

• Create an HTTP server
• Receive incoming requests
• Read request information
• Send HTTP responses
• Listen on a specific port

Because http is built into Node.js, there is nothing to install.

In short: Express is not required to create an HTTP server. Node.js already provides the underlying functionality.

2. Your First Node.js Server 🚀

Let's create a basic HTTP server. Save this as server.js:

Run it with node server.js, then visit http://localhost:3000. You'll see:

What happened?

Key insight: You never call the callback yourself. Node calls it for you, once per request, and hands you fresh req and res objects each time.

In short: Node creates the server, receives requests, and gives you the objects needed to construct responses.

3. Understanding req and res 📨

These two objects are fundamental to backend development.

req (IncomingMessage)

Contains information about the incoming request.

If you visit GET /users, you can inspect the method, URL and headers received by your server in the terminal.

res (ServerResponse)

Used to construct and send the HTTP response.

Notice that with the raw http module, you have to set the Content-Type header and turn the object into a JSON string yourself.

In short: req gives you the incoming request. res lets you construct and send the response.

4. Routing Without Express 🛣️

Suppose you want two endpoints:

• GET /users
• GET /products

Using Node's HTTP module, you have to check the method and URL yourself.

It works! But imagine handling 50 endpoints, query parameters, request bodies, and different response formats.

Your server code starts becoming difficult to manage.

In short: Node's HTTP module gives you control, but you have to handle much of the request processing yourself.

5. So, What Is Express? ⚡

Express is a web framework built on top of Node.js HTTP functionality. It provides a higher-level interface for building web servers and APIs.

Instead of manually checking every method and URL, you can write (after npm install express):

Notice the difference?

• app.get() handles GET requests for a particular path.
• req and res are still available.
• app.listen() starts the server.
• Unknown paths get a 404 reply (Cannot GET /orders) without any extra code.

Express handles much of the repetitive HTTP server work for you.

In short: Express provides a convenient abstraction over Node.js HTTP functionality.

6. Node HTTP vs Express ⚖️

Think of it this way: Node.js HTTP is the foundation. Express is a framework that makes building on that foundation easier.

7. Does Express Replace Node HTTP? 🔄

No! Express still uses Node.js HTTP functionality underneath.

When you call app.listen(3000), Express ultimately creates and starts an HTTP server using Node.js. These two lines do the same job:

You are not replacing Node's HTTP server. You are using a framework built around it.

Key insight: The req and res you get in Express are Node's own request and response objects, with extra helpers like res.json() and res.status() added on top.

8. What Breaks Without This? 💥

Imagine you start learning Express directly. You write:

But you don't understand the questions below. Understanding Node's HTTP module answers them:

You don't need to build every production application using the low-level HTTP module. But understanding the foundation makes debugging and learning frameworks much easier.

Common mistakes

• Forgetting res.end() in a raw Node server, so the browser keeps loading forever.
• Passing an object straight to res.end(). It only accepts strings or Buffers, so use JSON.stringify().
• Sending JSON without a Content-Type: application/json header.
• Starting a second server on a port that is already in use, which fails with EADDRINUSE.

🧪 Try it yourself

1. Save the routing example from section 4 (with const http = require("http"); at the top and server.listen(3000); at the bottom) and run node server.js.
2. In a second terminal, run curl -i http://localhost:3000/users, then curl -i http://localhost:3000/orders. Compare the 200 OK and 404 Not Found status lines.
3. Now try curl -i "http://localhost:3000/users?page=2". You get a 404, because req.url includes the query string. This is exactly the kind of work Express does for you.

🎯 Day 11 in one line

Node.js provides the HTTP server functionality. Express builds a convenient abstraction on top of it, making backend development easier.

Phase 2 complete! 🎯 We've covered HTTP methods, URLs, parameters, headers, request bodies, status codes, HTTP versions, TLS, cookies, sessions and CORS.

We've spent 11 days understanding how the backend works. Now it's time to build one.

Let's create our first Node.js + Express server from scratch.

1. What Do We Need? 🧰

Before writing code, let's understand our tools.

Think of it this way: Node.js runs your backend code. npm manages the packages. Express helps you build the server.

Check that Node.js and npm are installed:

If both print a version number, you're ready.

2. Create Your Project 📁

First, create a project directory:

Initialize a Node.js project:

This creates a package.json file. The -y flag accepts all the default answers.

What is package.json?

It's the configuration file that describes your Node.js project. It contains:

• Project name and version
• Dependencies
• Development scripts
• Other project metadata

It will look roughly like this (the exact fields vary by npm version):

In short: npm init initializes your project and creates its package configuration.

3. Install Express 📦

Now install Express:

What happens here?

You don't need to manually download or manage Express files.

Key insight: node_modules/ can always be rebuilt by running npm install, because package.json and package-lock.json describe exactly what belongs in it. That's why it is usually left out of Git.

In short: npm installs Express and manages the packages your application depends on.

4. Create Your First Express Server ✍️

Create a file named server.js:

Let's understand what's happening.

In short: You now have a working Express application listening for incoming HTTP requests.

5. Start Your Server ▶️

Run:

You should see:

Now open your browser at http://localhost:3000. You'll see:

Congratulations! Your first Express server is running locally. 🎉

The terminal stays busy because the server keeps listening for requests. Press Ctrl + C to stop it.

6. What Is localhost? 🏠

When you visit http://localhost:3000, you're accessing a server running on your own machine.

Your browser sends an HTTP request to that port, Node.js receives it, Express handles the matching endpoint, and the response goes back to your browser.

In short: Localhost lets you test your backend on your own machine without deploying it to the internet.

7. Add npm Scripts ⚙️

Instead of typing node server.js every time, we can add a script to package.json:

Now run:

With plain node, you must stop and restart the server after every code change. You can install Nodemon for development:

The -D flag saves it under devDependencies, because it's only needed while developing. Add another script:

Now:

Nodemon automatically restarts your server when it detects file changes.

start is a special script name, so npm start works without run. Custom names like dev need npm run dev.

In short: npm scripts simplify running your application, while Nodemon improves the development workflow.

8. Your Project Structure 🗂️

At this stage, your project should look like this:

That's all you need to get your first Express server running. We'll introduce routes, controllers, services and a proper project structure on Day 13.

9. What Breaks Without This? 💥

Imagine you install Express, copy some code from a tutorial, and run it without understanding the setup. Your server doesn't start.

You don't know:

• Which file starts the application.
• Where dependencies are installed.
• What app.listen() actually does.
• Why your browser cannot connect to port 3000.

Understanding the setup makes debugging much easier.

Common mistakes

• Running npm commands outside the project folder, so package.json isn't found.
• Committing node_modules/ to Git instead of adding it to .gitignore.
• Forgetting to save the file before testing.
• Listening on one port and visiting another in the browser.

You don't just want code that runs. You want to understand why it runs.

🧪 Try it yourself

1. Start the server with npm run dev, then in another terminal run curl -i http://localhost:3000. Look for HTTP/1.1 200 OK, the X-Powered-By: Express header and your message.
2. Change the text in res.send() and save. Watch Nodemon restart, then run the curl command again.
3. Visit http://localhost:3000/hello. Express replies with a 404 and Cannot GET /hello, because no route matches that path yet.

🎯 Day 12 in one line

Node.js executes your backend code, npm manages dependencies, and Express provides the framework to build your HTTP server.

Imagine building an e-commerce backend with 50 API endpoints. Would you put all 50 endpoints inside server.js?

It might work initially, but maintaining it would quickly become difficult. Let's understand how backend developers organize their applications.

1. The One-File Problem 📄

Imagine your server.js contains:

• User registration and login
• Product listing and searching
• Cart management
• Order creation
• Payment processing

Every endpoint, database operation and business rule lives in the same file. As the application grows:

• Finding code becomes difficult.
• Changing one feature becomes risky.
• Reusing business logic becomes harder.
• Testing individual parts becomes inconvenient.

We need a better structure.

In short: A small application can start with one file, but growing applications need separation of responsibilities.

2. What Is Routing? 🛣️

A route determines which code should handle an incoming HTTP request. A route is generally identified by:

• HTTP method
• URL path

The :id part is a route parameter. For DELETE /products/42, Express gives you req.params.id === "42".

Express matches the incoming request to the appropriate route handler.

In short: Routing connects incoming HTTP requests to the code responsible for handling them.

3. Express Router 🧭

Express provides express.Router() to create separate route modules. Instead of defining every endpoint inside server.js, we can organize routes by feature.

Now connect it to the main application:

Now:

• GET /users reaches the GET route.
• POST /users reaches the POST route.

Notice that we don't need to repeat /users inside every route. The mount path and the router path are joined together:

In short: Express Router lets us group related endpoints into separate modules.

4. Controllers 🎮

A controller handles the incoming request and prepares the response. Instead of writing the request-handling logic directly inside the route file, we move it into a controller.

Now our route file becomes:

The route decides which controller function should execute. The controller handles the request and sends the response.

In short: Routes define where requests go. Controllers handle the incoming requests.

5. Services 🧠

Now imagine creating a user requires:

• Checking whether the email already exists.
• Processing the user's information.
• Creating the user record.
• Returning the result.

Should all this business logic live inside the controller? Not necessarily. We can move the core business operations into a service.

The controller calls the service. Here is the full controller, now using it:

The service focuses on the application's business operations rather than handling HTTP requests and responses.

Key insight: Because a service never touches req or res, the same function can be reused by several controllers, a background job or a test.

In short: Services contain reusable business logic. Controllers coordinate the request and response.

6. The Complete Request Flow 🔄

Let's say a client sends POST /users. Here's what happens:

1. Server: Receives the incoming HTTP request.
2. Router: Matches POST /users.
3. Controller: Handles the request and extracts the required information.
4. Service: Executes the business operation.
5. Controller: Receives the result and prepares the response.
6. Client: Receives the HTTP response.

Think of it as:

This is a common architecture, not a mandatory rule for every Express application.

7. Project Structure 🗂️

A simple example:

Each folder has a responsibility:

Since createUser reads req.body, server.js needs one extra line so Express can read JSON bodies (more on this on Day 15):

As your application grows, you can organize additional features using the same pattern, for example product.routes.js, product.controller.js and product.service.js.

8. Folders Are Not Architecture ⚠️

Creating folders doesn't automatically mean you have good architecture.

Common mistakes

• Putting database queries and business rules everywhere.
• Writing business logic directly inside route handlers.
• Making controllers unnecessarily large.
• Creating too many layers for a very small application.

The goal isn't to create more files. The goal is to keep responsibilities clear and make the code easier to maintain.

9. What Breaks Without Separation? 💥

Imagine your payment calculation logic is written directly inside five different controllers. Now the discount calculation changes.

You have to update five places. What if you miss one? Different parts of your application may calculate different prices.

If the calculation lives in a reusable service, multiple controllers can use the same business logic:

Change the discount rule once in the service, and every controller gets the update.

🧪 Try it yourself

1. Create the route file from section 4, the service and full controller from section 5, and the server.js from section 7. Then run node server.js.
2. Run curl -i http://localhost:3000/users. You should get 200 OK and {"users":["Dev","Sahil"]}.
3. Create a user:

You should get 201 Created and the user object returned by the service.

🎯 Day 13 in one line

Routes decide where requests go, controllers handle HTTP requests and responses, and services contain business logic.