Forem: Prasun Chakraborty

Full Stack System Design 4 : GraphQL and gRPC

Prasun Chakraborty — Mon, 09 Feb 2026 17:19:35 +0000

In our previous episode on REST APIs, we broke down how traditional APIs work from architectures and URLs to headers and status codes. We saw how REST keeps things simple and predictable using HTTP methods and resources. But as apps get more complex, REST can sometimes feel limiting. That's where alternatives shine. In this Episode 4, we'll explore GraphQL and gRPC.

A Quick History of GraphQL and gRPC

GraphQL started at Facebook in 2012 when they were dealing with mobile apps that needed flexible data without wasting bandwidth. The old REST way meant over fetching of extra info, which was bad for slow networks. They built GraphQL internally and then open sourced it in 2015. It quickly caught on because it let clients ask for exactly what they needed. Today, it's used by big names like GitHub, Shopify, and Netflix for complex UIs.
gRPC, on the other hand, came from Google around the same time, it evolved from their internal Stubby system and open sourced in 2015. It's built on HTTP/2 and uses Protocol Buffers for efficient data packing. Google needed something fast for microservices talking to each other, especially in data centers. Now, it's popular in cloud setups like Kubernetes, with companies like Uber and Square using it for backend to backend speed.

Both came out around the mobile boom and microservices trend, solving pain points REST couldn't handle well. But they're tools, not replacements, based on your system's needs.

What is GraphQL?

GraphQL is a query language for your API and a server side runtime that runs those queries against a type system you define for your data. Unlike REST with its many endpoints (like /users, /posts, /comments), GraphQL usually has just one endpoint, say /graphql and the client decides the data shape, not the server. You send a query like:

query {
  user(id: "1") {
    name
    posts(first: 3) {
      title
    }
  }
}

The server returns exactly that no more, no less:

{
  "data": {
    "user": {
      "name": "Prasun",
      "posts": [
        { "title": "Web Basics" },
        { "title": "Protocols" },
        { "title": "REST Deep Dive" }
      ]
    }
  }
}

This is powered by a schema in Schema Definition Language (SDL) that defines types, like User and Post, with fields and relationships. Tools like Apollo or Relay handle the client side, making it easy to integrate with React or other frontends.

Why GraphQL? (Problem → Solution → Benefits)

In the 3-tier architecture we discussed in Episode 3, REST works well for simple use cases, but real world applications expose its limits especially as frontends grow more dynamic.

Over fetching is a common issue. Suppose your mobile app only needs a user’s name for a profile badge. A REST call like GET /users/1 often returns everything like email, bio, address, login history. That’s unnecessary data moving over the network, slowing performance on 3G connections and draining battery. With GraphQL, the client asks for exactly what it needs:

{
  user {
    name
  }
}

Under fetching is the flip side. A dashboard that shows user details along with recent posts might require multiple REST calls like GET /users/1, then GET /users/1/posts?limit=3. Each call adds latency and coordination overhead. GraphQL solves this by allowing nested queries, fetching all required data in a single round trip. This is especially valuable in full stack systems where frontend requirements evolve faster than backend APIs.

At its core, GraphQL acts like a surgical instrument for data access it's precise, flexible, and efficient. It doesn’t replace REST but it complements it where flexibility and performance matter most.

This design unlocks several key benefits:

Declarative Data Fetching
Clients explicitly describe the shape of the data they need. For example, the same API can return full post details for desktop views and lightweight summaries for mobile, without new endpoints or server changes.
Strongly Typed Schema
All data is defined in a shared schema schema.graphql. This enables IDE auto completion, early error detection, and tooling like GraphiQL. Think of it as TypeScript for your API that makes full stack development safer and more predictable.
Introspection by Design
GraphQL APIs are self describing. Clients can query the schema itself e.g.,__schema { types { name } }, making it easier to explore capabilities and evolve systems without breaking consumers.
Faster Frontend Iteration
UI teams can move independently. If the schema already exposes postViews, frontend developers can query it immediately no new endpoint, no backend redeploy. This dramatically shortens iteration cycles.

Full Stack System Design 3 : REST APIs from Architectures to Status Codes

Prasun Chakraborty — Sun, 08 Feb 2026 14:10:39 +0000

In our last episode, we explored the networking protocols that make data flow across the web, like TCP for reliability, HTTP/HTTPS for requests, and WebSockets for real time chats. Building on our web foundations, we're expanding to full-stack system design with the Episode 3, which dives into how applications communicate in more structured ways, starting with APIs. We'll focus on REST APIs first, using everyday analogies to keep it simple. This sets the stage for later topics in the series, like gRPC, GraphQL, and communication patterns. Let's get into it with the basics of app architectures and how REST fits in.

The Evolution of Tiers (The Restaurant Analogy)

To explain how apps are built, think of it like running a restaurant. We'll use this "digital kitchen" idea to break down the three main architectures.

1-Tier Architecture: The Food Truck Everything happens in one spot. The guy taking your order is also cooking and pulling stuff from the fridge. In software, this means the user interface, business logic and data storage are all on the same machine, just like an old desktop app. The issue with this is if a crowd suddenly shows up, the whole thing slows down or crashes. You can't easily add help without starting over.

2-Tier Architecture: The Small Diner Now the operation is split into two distinct spaces. There’s a front counter where customers place orders and interact with staff, and there’s a back kitchen where the actual work happens. The cashier focuses on talking to customers, taking orders, maybe doing light checks like “is this a valid order,” while the kitchen handles cooking, pricing rules, checking ingredients, and pulling items from the fridge. In software terms, the client handles the user interface and basic validation, while the server contains both the business logic and the database. This setup can handle far more customers than a food truck because multiple clients can talk to the same kitchen at once, and changes to the kitchen don’t necessarily require rebuilding the counter. The problem is that the kitchen becomes responsible for everything beyond taking the order. As the menu grows and customers want more custom options, all those special rules pile up in the kitchen, making it harder to manage and slower to respond. If demand increases or storage needs grow, you can’t just add another fridge or cook independently without redesigning the whole kitchen, because the logic and the data live together in one place.

3-Tier Architecture: The Fine-Dining Restaurant Now the restaurant is fully professional and built to scale. The front-of-house staff focuses only on the guest experience, guiding customers through the menu and taking orders without knowing how the food is prepared or where ingredients are stored. Orders are passed to the kitchen, where chefs concentrate purely on cooking and applying business rules, completely independent of how the order was taken or who took it. Behind all of this is a separate storage area where ingredients, recipes, and inventory are managed on their own, isolated from the chaos of the dining room and the heat of the kitchen. In software, this means the presentation layer handles user interaction, the application layer processes logic and decisions, and the data layer stores and manages information independently. Because each tier has a single responsibility, you can add more waiters, more chefs, or a bigger warehouse without redesigning the entire restaurant, making it far easier to handle growth, change menus, or support huge spikes in customers without the system slowing down or breaking.

What is an API? What is REST?

Before we talk REST, let's define API i.e. Application Programming Interface. In the restaurant, it's like the order slip the waiter hands to the chef. The frontend (waiter) writes what’s needed and passes it to the backend (chef). The waiter doesn't need to know how the oven works; they just follow the format. It's a simple contract between systems, letting them talk without knowing each other's insides.
REST, or Representational State Transfer, is a style for building APIs. If API is the order slip, REST is the standard way to fill it out, so everyone uses the same language.
Instead of random notes, REST uses consistent "nouns" and "verbs" over HTTP (from Episode 2).
Nouns (Resources): Things like /orders, /menu-items, /customers—the stuff you're dealing with.
Verbs (Methods): GET (fetch something), POST (create new), PUT (update), DELETE (remove).

Grammar and Vocabulary

If the 3-Tier architecture is the building, these topics explain how we navigate the hallways and what actions we can perform once we get there.
Let's start with the parts of a URL, since that's the starting point for any API call. Think of it as the map your browser (or app) to find and interact with resources on the server.

Anatomy of a URL: The Map

A URL (Uniform Resource Locator) Is like an address, a full set of directions for the browser on where to go and what to do. It guides the request from your client to the exact spot on the server, following the HTTP rules we talked about in Episode 2. Let's split it into parts with examples.

Scheme (Protocol): Like https:// or http://. It tells the browser (or your app) what protocol to use for communication.Like https:// this tells how to talk securely, as we covered in Episode 2 with HTTP/HTTPS.
Host (Domain): This is the main address, like api.prasunchakra.com. It points to the specific server or subdomain where the API is hosted. For This could be separate from your main site prasunchakra.com to keep API traffic separate and organized. For example, if prasunchakra.com has a blog, the host api.prasunchakra.com might handle requests for posts and users.
Path: This comes after the host, like /v1/users/123. It's the route to the exact resource. In REST design, paths are always nouns representing things and never an actions. So /users for a list of users, or /users/123 for a specific one. The /v1 is a version number, common in APIs to let you update without breaking old clients. For prasunchakra.com, a path like /v1/posts/abc might fetch a blog post by ID abc. This makes APIs intuitive, as if you are navigating like folders on a computer.
Query Strings: These start with ? and use & to separate params, like ?format=json&sort=desc. They're optional extras that tweak the request without changing the path. Think of them as filters, format=json says "send data as JSON, not XML," and sort=desc means "oldest first." For example say prasunchakra.com's API, you might do /posts?author=jagd&limit=10 to get the last 10 posts by Jagdish. They're great for searches.
Fragment: This is the # part at the end, like #profile. It's for client side only. The browser uses it to scroll or jump to a section after the page loads. Servers never see it, so it's not for APIs. In prasunchakra.com, if a post has #comments, your browser scrolls to the comments without a new request. Handy for single page apps.

CRUD and the HTTP Methods: The Actions

REST is all about doing basic operations on resources, called CRUD (Create, Read, Update, Delete). We tie these to HTTP methods to keep things standard and easy to predict. This predictability is why REST is so popular, it lets developers guess how an API works without docs. Let's expand on each with examples and why they matter.

Create : This sends data to make something new. It's like submitting a form where the body of the request holds the details (e.g., in JSON). For example POST to /users with {"name": "New User", "email": "user@example.com"} creates a account. Servers respond with 201 Created and maybe with the new ID.
Read : This grabs data without changing anything. It's safe and repeatable. For example GET /posts fetches all blog posts, or GET /posts/123 gets one. Servers send 200 OK with the data. This method is cacheable, speeding up apps.
Update / : These change existing resources. PUT replaces the whole thing like send the full data to /users/123, and it overwrites everything. PATCH is partial it just send changes, like {"email": "new@email.com"} to update a single field. PUT is idempotent (repeatable safely), PATCH might not be. Choose based on if you want full control or efficiency.
Delete : This removes a resource. A simple DELETE /users/123 and it's gone. Server replies 204 No Content if successful. For example DELETE /comments/xyz clears a comment. It's idempotent because deleting twice is fine (second time just says not found).

CRUD also maps well to databases like Create=INSERT, Read=SELECT, etc. making REST a natural fit for web apps.

The "Specialist" Methods

CRUD covers most stuff, but there are a few extra HTTP methods for special cases, like tools you pull out only when needed. They're less common but useful for optimization, security, or debugging. Let's dive deeper with use cases and caveats.

HEAD: Same as GET, but skips the body and just gets headers. It's like peeking at mail without opening it. For example, HEAD /images/bigfile.jpg checks Content-Length (size) or Last-Modified (date) to see if it's worth downloading there by saving bandwidth on mobiles or low network scenarios. Response is 200 OK with headers only and no data transfer.
OPTIONS: Asks what methods a URL supports. Server replies with Allow: GET, POST, etc. Crucial for CORS, when your frontend on prasunchakra.com calls an API on another domain, the browser sends OPTIONS first as a "preflight" to check if it's allowed (via headers like Access-Control-Allow-Origin). If not, the real request is blocked for security. Use it to test API capabilities without full calls.
CONNECT: Sets up a tunnel through proxies, turning the connection into a pipe for other protocols. Rare in APIs, but used for things like HTTPS over proxies or VPNs. For example behind a corporate firewall, CONNECT might establish a secure link.
TRACE: Loops back the request for testing, server echoes what it got, including headers. Good for debugging proxies or seeing if requests are tampered with. But security risks are often disabled because attacks like Cross Site Tracing (XST) can use it to steal cookies or headers.

Headers : Metadata that Drives the Web.

Headers are like the metadata or notes attached to your HTTP requests and responses. They're key for telling the server what you want and how the client should handle what's sent back. Think of headers as the envelope around your letter: the address is the URL, but headers add the stamps, return address, and special instructions.

Request Headers: The Client’s Instructions

When your frontend or a tool like Postman sends a request to the API, it includes these headers to give context, preferences, and security details. They're sent in the HTTP request and servers read them to decide how to process and respond. Let's break them down with more detail and why they matter in real world REST setups.

Identity & Context: These help the server know who's asking and from where.

Host: This is mandatory in HTTP/1.1 and tells the server which domain the request is for, like servers often host multiple sites on one IP (virtual hosting), so this routes it right. If you forget this, the server might reject the request with a 400 Bad Request.
User-Agent: This strings together your browser or app info, e.g., User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36. Servers use it to optimize, like sending mobile friendly JSON if it's from an android app, while the backend might log this for analytics or serve lighter data to slow devices. But users can fake it, so we don't rely on it for security it's only for better user experience.
Origin and Referer: Origin is for security, showing just the domain and port (e.g., Origin: https://prasunchakra.com) during CORS checks . Referer gives the full previous URL, like Referer: https://prasunchakra.com/blog/post1. Use Origin for strict checks and Referer for tracking how users arrived. In APIs, if Origin doesn't match allowed domains, the server blocks cross site requests to prevent attacks.

Content Negotiation: This is like negotiating the menu, client says what it can handle, server picks.

Accept: Specifies response formats, e.g., Accept: application/json, text/xml. For example in API, if you GET /posts and set Accept: application/json, the server sends JSON; otherwise, maybe HTML. If unsupported, it might return 406 Not Acceptable. This makes APIs flexible for different clients (web vs. mobile).
Accept-Language: User's language prefs, e.g., Accept-Language: en-US, hi;q=0.5 (English first, Hindi second with lower priority). Servers can localize responses, like sending Hindi error messages for prasunchakra.com users in India. q values (0-1) weight preferences.
Accept-Encoding: Compression support, e.g., Accept-Encoding: gzip, deflate, br (Brotli). Servers compress data to speed up transfers. For large JSON from prasunchakra.com's /posts endpoint, gzip shrinks it 70%, saving bandwidth on slow connections.

Security & State: Crucial for protected APIs.

Authorization: Like showing ID, e.g., Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... (a JWT token). For example to create a new post, you need this after login. Types include Basic (username:password base64'd—unsafe), Bearer (tokens), or API keys. Without it you get 401 Unauthorized.
Cookie: Client stored data from previous responses, e.g., Cookie: sessionId=abc123; theme=dark. For example it might track logged in state.
Conditional/Caching: For efficiency, avoiding unnecessary data.
If-Modified-Since: A date, e.g., If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT. Server checks if resource changed if not, sends 304 Not Modified (no body). Great for static images it saves redownloading.
Cache-Control: Client side rules, e.g., Cache-Control: no-cache (always check server). Or max-age=0 for fresh data. In APIs, this tells proxies or browsers how to cache requests.

Response Headers: The Server’s Reply

After processing, the server sends these back with the status code (like 200 Which we have discussed in the next section) and body. They guide the client on what to do with the data to render it, to cache it, or secure it. In REST, good headers make apps faster and safer.

The Content Details: Basics on what's in the body.

Content-Type: Describes the body, e.g., Content-Type: application/json; charset=utf-8 this tells the client to parse as JSON. If mismatched (say, sending HTML as JSON), the app crashes. Multipart types handle files too.
Content-Length: Body size in bytes, e.g., Content-Length: 1024. Helps clients know when transfer ends, especially for streaming. If without it we use chunked encoding.
Content-Encoding: If compressed, e.g., Content-Encoding: gzip. Client decompresses before using. For big responses this pairs with Accept-Encoding to cut load times.

Caching & Freshness: These prevent refetching unchanged data, huge for speed.

ETag: A hash or version, e.g., ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4". Client sends If-None-Match next time and if matches, 304 Not Modified. If content hasn't changed, skip download.
Last-Modified: Timestamp, e.g., Last-Modified: Tue, 29 Oct 2024 12:00:00 GMT. Pairs with If-Modified-Since. Simpler than ETag but less precise for dynamic data.
Expires: Absolute staleness date, e.g., Expires: Wed, 21 Oct 2025 07:28:00 GMT. Browser won't refetch until then. Good for static assets.
Cache-Control: Most flexible, e.g., Cache-Control: public, max-age=3600 (cacheable by anyone for 1 hour). Or private (user-specific), no-store (no caching). Overrides Expires. In APIs, use must-revalidate for fresh checks after stale.

State & Server Info: Managing ongoing sessions and info.

Set-Cookie: Server sets client cookies, e.g., Set-Cookie: sessionId=abc123; Max-Age=3600; Secure; HttpOnly. This starts a session. Flags: Secure (HTTPS only), HttpOnly (no JS access), SameSite (anti-CSRF).
Server: Server software, e.g., Server: nginx/1.24.0. Gives hints but often hidden (e.g., removed or faked) to avoid targeted attacks.

Status Codes: The Server's Quick Feedback

When the server processes your request, it starts the response with a status code. It's the first thing in the HTTP response line, like "HTTP/1.1 200 OK." Codes are grouped into ranges (1xx to 5xx), and good API docs always explain what each means for their endpoints. In tools like Postman or browser consoles, you'll see them as 200 is green, 404 is red. Let's break them down with more context.

1XX: "Hold on..." (Informational) These are rare, interim codes saying the request is being handled but not done yet. Clients usually don't need to do much,they're automatic.

100 Continue: Server says, "What you've sent so far is fine, send the rest." Useful for big uploads, like POSTing a large image to say /uploads endpoint. Client sends the first chunk, gets 100 and then continues. Prevents wasting bandwidth on invalid starts.
101 Switching Protocols: Server agrees to change protocols, like upgrading from HTTP to WebSockets. For example, if you have real-time comments, a GET /comments with Upgrade: websocket header might trigger 101, switching to bidirectional chat.

2XX: "Got it!" (Success) Everything worked and the request was valid, server did its job. These are what you aim for in happy paths.

200 OK: The default success for most requests, like GET /posts returning blog data or fetching a user profile sends 200 with JSON in the body. Always include a body if there's data; empty is fine for simple confirms.
201 Created: For POSTs that make new stuff, like POST /posts creating a blog entry. Server responds with 201 and often a Location header pointing to the new resource (e.g., Location: /posts/456) this confirms the post is live and gives the URL to view it.
204 No Content: Success, but no body needed—like DELETE /comments/123. For example, removing a spam comment sends 204; client knows it's gone without extra data. Efficient for actions without results.
206 Partial Content: When you request ranges, like video streaming. If website has a media API, GET /videos/bigfile with Range: bytes=500-999 gets 206 and just that chunk. Headers like Content-Range tell the byte range. Great for resuming downloads on flaky connections.

3XX: "Go over there" (Redirection) The resource moved or can be found elsewhere, client should follow or cache. Servers use these for SEO, load balancing, or versioning.

301 / 308: Permanent moves: 301 Moved Permanently says "Use this new URL forever" (with Location header). For example if you rename /blog to /posts, 301 redirects old links. 308 is similar but preserves method/body for POSTs. Caches well, but update your links to avoid chains.
304 Not Modified: Ties to caching headers (from earlier). If client sends If-None-Match with an ETag, and nothing changed, server sends 304—no body, use your cache. For example static CSS, this saves reloads on repeat visits.

4XX: "You messed up" (Client Error) Client's fault like bad input, no auth, or wrong URL.

400 Bad Request: Generic for malformed requests, like missing params or invalid JSON in POST. For example if you POST /users with broken email format, 400 with details helps debug.
401 / 403: You aren't logged in or you don't have permission: 401 Unauthorized means "Log in first". 403 Forbidden is "You're logged in but not allowed," like accessing admin without rights. 401 is used for missing creds and 403 for denied access.
404 Not Found: Classic, the resource doesn't exist. GET /posts/999 on some website if ID's wrong.
429 Too Many Requests: Rate limiting, you're hitting too fast. Headers like Retry-After: 60 say wait 1 minute. For public API, this prevents abuse.

5XX: "I messed up" (Server Error) Server's problem like bug, overload, or downstream issue. Clients can retry later.

500 Internal Error: Catch all for crashes, like unhandled exceptions in backend code. Body might say "Something went wrong" for users, but logs have stack traces.
502 / 504: Gateway/Timeout issues. 502 Bad Gateway means a proxy or upstream server failed e.g. load balancer can't reach the app server. 504 Gateway Timeout is when it takes too long. Common in microservices check connections.
507 Insufficient Storage: Server's disk is full, can't save your POST. Rare, but for websites with heavy user uploads, this means scale storage ASAP.

Status codes are your API's language for feedback, use them right, and your REST service becomes user friendly.

That wraps up Episode 3 on APIs and architectures, starting with REST. We've gone from tiers and basics to URLs, methods, headers, and now status codes—building a solid foundation for how frontends talk to backends. But REST isn't the only game in town. In the next episode, we'll pick up alternatives like GraphQL (for flexible queries) and gRPC (for high-performance microservices), comparing them to REST with examples.

Demystifying the Web 2: The Language of the Internet

Prasun Chakraborty — Sat, 07 Feb 2026 03:12:59 +0000

In Episode 1, we walked through the basics of how the web works. From typing a web address into your browser, through DNS lookups and secure connections, to rendering the page on your screen. We touched on things like TCP and HTTP, but that's just the surface. Now, in Episode 2, let's dig deeper into the networking protocols that power all this communication. These are the building blocks that make data move reliably and fast across the internet. We'll start with the low-level ones and move up.

The Low-Level Workhorses (TCP vs. UDP)

Before the web can talk, it needs a transport layer that decides how data packets are sent between two machines. Think of this as choosing between a careful courier and a fast bike messenger.

TCP (Transmission Control Protocol): TCP is the “reliable guy” of the transport layer. It is connection oriented, which means it first sets up a virtual connection between your browser and the server using a handshake before any real data flows. Once the connection is established, TCP breaks your data into numbered segments so they can be reassembled correctly on the receiving side, waits for acknowledgements (ACKs) from the receiver and retransmits any lost segments to ensure nothing goes missing, guarantees that all data arrives in the correct order even if packets take different paths through the network, and performs flow control and congestion control so a fast sender does not overwhelm a slow receiver or a congested network. All of this reliability comes with extra overhead and slightly more latency, but it is perfect when correctness matters more than speed. Like Web browsing, Emails or File transfers
UDP (User Datagram Protocol): This one's all about speed it takes the opposite approach. It is connectionless and focuses on minimal delay. There is no handshake to set up a session, no tracking of which packets arrived, and no built-in mechanism to reorder or retransmit lost data. Because UDP does not spend time on acknowledgements, retransmissions, or congestion algorithms, it has much lower overhead and can be significantly faster and more predictable in terms of latency. That makes it ideal for real time scenarios where a small amount of loss is acceptable, but delay is not. Like live streaming and video conferencing, Online gaming or VoIP calls.

The Web Giants (HTTP, HTTPS, HTTP/3)

Once TCP or UDP has done the hard work of moving packets around, the web needs a language for clients and servers to talk in. That language is HTTP and its secure cousins.

HTTP (Hypertext Transfer Protocol): Defines how a client (like your browser) sends a request and how a server replies with a response. It is a simple text based, request response protocol.The client asks for a resource (HTML, CSS, JSON, etc.), and the server answers with a status line, headers, and an optional body. By default, classic HTTP (HTTP/1.1) runs over TCP, so it inherits TCP’s reliability and ordering guarantees.
HTTPS (Hypertext Transfer Protocol Secure): Is not a different application protocol. It is simply HTTP running inside a TLS-encrypted tunnel. The “S” in https://prasunchakra.com means that before any HTTP request–response messages are exchanged, the client and server perform a TLS handshake to agree on keys and ciphers, and to authenticate the server’s identity using its certificate. So you can think of HTTPS as “take normal HTTP and wrap every byte of it inside TLS, at the transport layer.” Today, browsers treat plain HTTP as “not secure” and strongly prefer HTTPS everywhere.
HTTP/3 (QUIC): HTTP/2 improved performance by multiplexing many HTTP streams over a single TCP connection, but it ran into a TCP level problem called head of line (HOL) blocking. If one TCP packet is lost, TCP must hold back all later packets for that connection until the missing one is retransmitted, which delays every active HTTP stream sharing that connection. HTTP/3 takes a different route by running over QUIC, a transport protocol built on top of UDP. QUIC provides its own reliability, encryption (it uses TLS 1.3 integrated into the transport), and congestion control, but crucially it is stream-aware: it can treat each HTTP stream independently. This significantly reduces head of line blocking and improves perceived performance, especially on flaky mobile or Wi‑Fi networks where packet loss and changing network paths are common. Modern browsers are gradually adopting HTTP/3 for many large sites so that page loads, API calls, and asset fetches feel snappier and more resilient in real-world conditions.

The Real Time & Legacy Layer (WebSocket, SMTP, FTP)

Not everything on the internet fits cleanly into “classic web pages.” Some protocols exist for real time interactions, others are older but still important in the background.

WebSockets: WebSockets were created to solve a limitation of HTTP that the client always has to initiate the conversation. With WebSockets, the browser and server upgrade an existing HTTP connection, then switch to a protocol that keeps a single TCP connection open and full‑duplex.
Once the WebSocket is established, both the client and the server can send messages at any time without creating new HTTP requests, the connection remains open until it is explicitly closed which reduces overhead and latency, and messages can be sent as either text or binary frames, making WebSocket flexible for a wide range of real-time use cases.Which include chat apps, live dashboards (like stock prices or sports scores), collaborative tools (Figma, Google Docs‑style editors), multiplayer games, and any UI that needs instant updates pushed from the server.
SMTP (Simple Mail Transfer Protocol): It is the protocol responsible for sending emails between mail servers. When you hit “Send” in Gmail or Outlook, your client talks to an SMTP server over TCP, hands over the message, and then a series of SMTP servers relay that message until it reaches the recipient’s mail server.
A simplified flow works as follows: your email client submits the message to your provider’s SMTP server, that server looks up the recipient’s domain using DNS and forwards the email to the destination SMTP server, possibly passing through intermediate relay servers, and finally the recipient’s server accepts the message and stores it in a mailbox where it can later be retrieved using protocols such as IMAP or POP3. IMAP (Internet Message Access Protocol) and POP3 (Post Office Protocol version 3) are email retrieval protocols, with IMAP keeping messages stored and synchronized on the mail server across multiple devices, while POP3 downloads messages to the local device and usually removes them from the server.
FTP (File Transfer Protocol): This is one of the oldest protocols for transferring files between a client and a server. It uses separate control and data channels over TCP, which historically made it flexible but also a bit of a pain for firewalls and NAT devices.
Classic FTP has a big downside that the credentials and file contents are sent in plain text, so anyone sniffing the network can potentially see usernames, passwords, and data. Because of this, modern setups usually prefer secure alternatives such as SFTP (Secure File Transfer Protocol), which transfers files over SSH using a single encrypted channel for both commands and data, and FTPS (File Transfer Protocol Secure), which runs FTP over SSL/TLS to add encryption on top of the traditional FTP model.

From TCP and UDP at the transport layer to HTTP, HTTPS, WebSockets, SMTP, and FTP at the application layer, these protocols are the invisible glue that holds the internet together. Each one solves a slightly different problem: reliable delivery, secure browsing, real-time updates, email, or file transfer. The key idea to carry forward is this: when you type prasunchakra.com or open your favorite app, you are really triggering a carefully layered conversation between machines, with each protocol playing its part in the stack. As you build web apps, APIs, or backend systems, understanding these layers helps you reason about performance issues, security choices, and why things sometimes break in “mysterious” ways on real networks. In future episodes, we will zoom into specific pieces of this puzzle.

Demystifying the Web 1: The Journey of a web page

Prasun Chakraborty — Fri, 06 Feb 2026 17:38:56 +0000

Ever wondered why typing any website say my personal one prasunchakra.com into your browser feels so quick, even though it involves a bunch of stuff happening across the world? From DNS servers connecting over the internet to your screen showing the final page, the web is built on many connected technologies.
Let's break it down step by step.

Let's start with the basic exchange between your browser and the server. This is the core of how the web works,it's like a simple back and forth conversation.

First, the request: When you type prasunchakra.com into your browser and hit Enter, your browser creates an HTTP request message. This is basically your browser saying, "Hey server, send me the main page for prasunchakra.com." It includes details like the URL, what type of data it's expecting (like HTML,CSS,JS), and some headers for things like your browser version or cookies if you've visited before.
Next, the processing: The server for prasunchakra.com gets this request. It checks the URL, goes into its directories, and pulls out the files needed. For prasunchakra.com, this might mean finding the index.html file, any linked images, or backend scripts if there's dynamic content. The server processes any logic, like running code to generate the page if it's not static.
Finally, the response: The server packs up an HTTP response and sends it back. This includes a status code (like 200 OK if everything's fine), and the actual content. For prasunchakra.com, it's usually the HTML for the page structure, CSS files for styling (like fonts and colors), and JavaScript for any interactive parts, like menus or forms. Your browser then starts putting it all together.

For a deeper understanding, think of it in two main parts: first, finding the server's address (that's DNS), and then actually connecting to it and getting the data (that's the request to the server).

Part 1: Finding the Address (DNS Lookup)

When you type prasunchakra.com into your browser, your computer doesn't know the exact location. It needs the IP address, something like 192.0.2.1, to reach the server.

It checks for the IP address in a few places locally first to save time:

Browser Cache: This is split into memory and disk. Memory cache is super fast, but it clears out when you close the tab or browser and disk cache, bit slower than memory but it sticks around between sessions. This is where stuff like images, scripts, or even DNS info from prasunchakra.com gets stored.
Service Workers: If prasunchakra.com uses one (it's a background script), it can grab requests and pull files from its own Cache Storage. This works even offline.
Operating System (OS) Cache: The browser then asks your OS (like Windows or macOS) if it has a recent DNS entry for prasunchakra.com saved in system memory.
Router Cache: Finally, your home router might have its own DNS table cached, speeding things up for all devices on your network.

If none of these have the IP, then it moves to asking the ISP's DNS resolver. Now when the DNS resolver needs to find the IP for "https://www.prasunchakra.com", it doesn't search everywhere at once. It follows a structure, reading the URL from right to left, like flipping through a phone book.

The Root Level (.): This is the top of the tree, hidden in every URL (think prasunchakra.com.) Root servers are like the main directory, they point to where the next level's info is stored.
Top-Level Domain (TLD): That's the ending like .com, .org, or .in. For prasunchakra.com, the root server says, "Go ask the .com servers." These TLD nameservers know all the .com domains and direct to the right one.
Second-Level Domain (SLD): This is the main name you picked, like "prasunchakra" The .com server points to the authoritative nameserver for prasunchakra, which is usually set up by your hosting provider (maybe Cloudflare or GoDaddy). That's where the actual IP is stored.
Third-Level Domain (Subdomain): If it's something like blog.prasunchakra.com, the authoritative server handles the "blog" part. Subdomains let you point to different sections or servers, like blog.prasunchakra.com going to a separate machine.

This whole process usually takes milliseconds because of caching at each level. Once done, your browser gets the IP and moves to the connection phase.

Part 2: The Connection Phase (Handshakes)

Now that we've got the IP address from DNS, it's time for the connection phase. This is where your browser sets up a reliable and secure link to the server hosting prasunchakra.com before asking for the page.

The TCP 3-Way Handshake (For Reliability) The internet can drop packets sometimes, so TCP makes sure everything arrives in order and nothing gets lost. Before sending any real data, the browser and server do a quick check to confirm they're both ready.

SYN (Synchronize): Your browser sends a packet to the server's IP. It's like saying, "Hey, prasunchakra.com server, I want to connect. My starting number is X."
SYN-ACK (Synchronize-Acknowledge): The server gets it and replies, "Okay, got your message. I'm ready too. My starting number is Y, and I confirm yours (X+1)."
ACK (Acknowledge): Your browser sends back, "Cool, I got that. Let's go (Y+1)."

Now the connection is open, and data can flow reliably.

The TLS/SSL Handshake (For Security) If it's HTTPS (you see the padlock for prasunchakra.com), there's an extra step right after TCP to encrypt everything. This stops your ISP or anyone on the network from snooping on your data.

Client Hello: Your browser sends a list of encryption options it supports (called cipher suites) and some random data.
Server Hello + Certificate: The server picks one option, sends its own random data, and shares its digital certificate (signed by someone trusted, like Let's Encrypt).
Authentication: Your browser verifies the certificate: "Is this really prasunchakra.com? Yes."
Key Exchange: Using math like RSA or Diffie Hellman, they agree on a shared secret key. They start with slow asymmetric encryption just to set up a faster symmetric key for the rest.
Finished: Both confirm, "Alright, from here on, all data is encrypted."

With the connection secure, the browser can finally send the HTTP request for the page.

Part 3: Getting the Data (HTTP Request)

Once the secure connection is set up, the server for prasunchakra.com sends back the response packets. Your browser starts receiving them and begins the rendering process to show the page. This happens in stages, turning raw code into what you see on screen.

The Construction Phase (DOM & CSSOM)

As the HTML starts coming in chunks, the browser doesn't wait for everything—it begins building right away.

DOM (Document Object Model): The browser reads the HTML and builds a tree structure from it. For prasunchakra.com, every tag like <div>, <p>, or <img> becomes a node in this tree, representing the page's skeleton.
CSSOM (CSS Object Model): While parsing the HTML, it spots <link>tags for CSS files. The browser downloads and parses these to get the styling rules, like colors, fonts, and sizes for prasunchakra.com.
CSS blocks rendering. The browser won't display anything until the CSSOM is done, to avoid showing a plain, unstyled page first (that's called Flash of Unstyled Content or FOUC). It wants prasunchakra.com to look right from the start.

The Interaction Phase (JavaScript) Next comes JavaScript, which adds the dynamic parts.

JS is Parser Blocking that is when the browser hits a <script> tag in the HTML for prasunchakra.com, it stops parsing the rest of the HTML. It downloads the script, runs it, then continues.
Why? Because JS can change the DOM on the fly, like adding or removing elements. The browser doesn't want to build something that JS might mess up right after.
To fix, we use async or defer on script tags. Async loads JS without blocking but runs it as soon as it's ready. Defer waits until the HTML is fully parsed. That's how modern sites like prasunchakra.com speed things up!

The Visual Phase (Render Tree, Layout, and Paint)

With DOM and CSSOM ready, the browser combines them to draw the page.

The Render Tree: It merges DOM and CSSOM, skipping hidden stuff like <head> or elements with display: none. For prasunchakra.com, this creates a visible structure.
Layout (Reflow): The browser calculates positions and sizes— like how wide a div is or where an image sits on prasunchakra.com.
Paint: It fills in the details: text, colors, borders, images—all the pixels for the page.
Compositing: For layered elements (like a sticky navbar on prasunchakra.com), it uses the GPU to combine them into the final screen image efficiently.

With this we've covered the journey from typing prasunchakra.com into your browser to seeing the fully rendered page on your screen. It's a mix of DNS lookups, secure connections, and browser magic that makes the web feel effortless. But this is just the start and there's a lot more under the hood, like how the backend handles things or advanced topics in networking and security. Stay tuned!