Loading content...
Loading content...
Every click, submission, and data refresh in modern web development relies on the foundational contract between the Client (the user's browser) and the Server (the backend engine & database). Learn how requests travel, what code executes where, why client-side security is an illusion, and how professional developers debug full-stack errors.
The fundamental division of responsibilities on the web
In full stack development, web applications are divided into two primary communicating entities:
The software or device that initiates communication and presents the interface to human beings. In web apps, this is typically Google Chrome, Safari, or Firefox running HTML, CSS, and JavaScript.
The computer system or software service that listens for incoming requests, applies business rules, verifies security permissions, queries databases, and sends back structured responses.
GET /api/products. The Node.js/Python backend (Server) authenticates the session, queries the database, and returns a JSON payload. The browser then converts that JSON into interactive product cards.Where code runs determines what it can see, do, and be trusted with
₹1,500 doesn't stop an attacker from opening DevTools or using cURL to send price: ₹1. The server must always recalculate and validate prices independently.The 6-stage roundtrip journey of modern web communication
Test your architectural intuition: decides which environment handles each task
For each task below, decide whether it belongs on the Client (Browser) or the Server (Backend):
Watch an HTTP packet travel step-by-step from browser to database and back
GET /api/products HTTP/1.1 Host: store.pathubs.com Accept: application/json User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Cookie: session_token=jwt_9921_valid
How to isolate error origins in 5 seconds using HTTP status codes
Origin: Server / Backend.
Cause: Unhandled exception in backend code, failed database connection, or null pointer in controller.
Action: Check backend terminal / server logs.
Origin: Routing / Request URL.
Cause: Typo in fetch URL (e.g. /api/productss) or non-existent resource ID (e.g. /api/products/999).
Action: Verify endpoint path and backend router registrations.
Origin: Client / Frontend JavaScript.
Cause: The server succeeded, but client JS failed to render (e.g. reading data.items instead of data.products).
Action: Inspect browser console and component render code.
Interact with endpoints and observe simulated server responses
Tracing security responsibilities between browser and backend
A user authenticates by entering their email and password. Notice how client and server divide duties:
1. Renders login form inputs (email, password).
2. Validates email has an "@" symbol for instant feedback.
3. Dispatches POST /api/login with JSON payload.
4. Shows spinner while awaiting response.
5. On 200 OK, redirects browser to /dashboard.
1. Receives credentials over secure HTTPS.
2. Queries database for user by email address.
3. Verifies password against hashed string using bcrypt.
4. Issues encrypted session cookie / JWT token.
5. Returns 200 OK or 401 Unauthorized.
Pitfalls made by developers when building client-server applications
Never import server database clients (like Prisma, Mongoose, or pg) into client-rendered browser files. All database access must remain in server-only route handlers.
Client-side HTML5 "required" attributes provide great UX, but an attacker can bypass them in milliseconds. Always re-validate every field on the server.
If DevTools shows 200 OK with a valid JSON payload, the backend succeeded. If the UI is blank or broken, the bug is in client-side state or DOM rendering.
Validate your client-server mental model
Validate your understanding of HTTP request-response flow, client vs server boundaries, security, and debugging status codes.
Why should a web application NEVER communicate directly from the browser to a production database?
Core concepts you have mastered in this module