Welcome to your first lesson in Backend Engineering!
Given your extensive background in AI and machine learning, you're accustomed to building complex systems that process data and make decisions. You've likely interacted with backend systems frequently, for instance, when fetching data for a model or deploying an AI service via an API. This course will demystify what happens on the other side of that interaction. We'll start from the ground up, building the foundational knowledge you need to construct robust, scalable backend services.
Today's lesson addresses the most fundamental concept in web communication: the client-server model and the role of HTTP. We'll explore how different parts of the internet talk to each other, setting the stage for you to build the "server" side of that conversation.
1. The Big Picture: The Client-Server Model
At its core, the web operates on a simple but powerful architectural pattern: the client-server model. In this model, there are two primary actors:
- The Client: A piece of software or hardware that requests information or services. This is often a web browser on your laptop or phone, but it can also be a mobile app, or even a Python script you write to call an API (like the ones you may have used to access large language models). The client is the consumer of services.
- The Server: A powerful computer or a distributed system of computers that stores resources (like web pages, images, data) and provides services. Its job is to listen for requests from clients, process them, and send back an appropriate response. The server is the provider of services.
This is a many-to-one relationship. A single server can handle requests from thousands or even millions of clients simultaneously.
This request-response loop is the heartbeat of the web.
To get a more dynamic explanation of this model, watch the following segment from a video by Harkirat Singh. He uses the example of ChatGPT, which should be very familiar to you, to illustrate the roles of client and server.
Introduction to Backend, what are HTTP servers | Course Preview #2
This video explains the client-server model using the practical example of how your browser (the client) interacts with ChatGPT's backend (the server) to get a response.
Watch the section from 9:26 to 12:37. Focus on how he defines the client (your browser) and the server (the powerful machines running the AI model), and why this separation is necessary for applications like ChatGPT.
The MDN Web Docs, a vital resource for any web developer, provide a concise definition of these components.
Overview of HTTP - MDN Web Docs
For a formal definition of the components in an HTTP-based system, read this section from the MDN Web Docs.
Read the section titled 'Components of HTTP-based systems', including the subsections on 'Client: the user-agent', 'The Web server', and 'Proxies'. This will solidify your understanding of the different actors involved.
Test your understanding!
You've built an "AI Career Coach" using a RAG pipeline. A user interacts with it through a web interface. Identify the "client" and the "server" in the following scenarios:
- A user types a question into the web interface on their laptop and hits "send".
- Your application contacts the OpenAI API to get an embedding for the user's question.
- Your application queries a vector database to find relevant documents.
Show answer
- The client is the user's web browser. The server is your backend application that receives the question.
- In this interaction, your backend application acts as the client, and the OpenAI API service acts as the server.
- Again, your backend application is the client, and the vector database is the server.
This shows that a "server" in one context can act as a "client" in another. This is a common pattern in modern backend development, especially in microservices architectures.
2. HTTP: The Language of the Web
Now that we understand the roles of the client and server, how do they actually communicate? They use a standardized set of rules, a protocol, called the Hypertext Transfer Protocol (HTTP).
Think of a protocol as a shared language and a set of etiquette rules. When you make a phone call, the protocol involves one person dialing, the other answering, saying "hello," taking turns to speak, and saying "goodbye." HTTP provides similar rules for web communication. It's an application-layer protocol, meaning it defines how applications (like your browser and a web server) exchange messages, without worrying about the underlying complexities of network cables and routers.
The core of HTTP is the request-response cycle:
- The client establishes a connection with the server.
- The client sends an HTTP request message.
- The server processes the request.
- The server sends back an HTTP response message.
To understand what these messages look like, let's dive into a resource that breaks them down.
A Deep Dive into OSI, TCP/UDP, HTTP, and More
This article provides a clear breakdown of the structure of HTTP requests and responses.
Read the section titled 'Understanding the HTTP Protocol'. Focus on the four fundamental parts of an HTTP request: Method Type, URL, Headers, and Body. Pay attention to the examples for GET and POST requests.
As you saw, a request specifies what the client wants (the method and URL) and provides context (headers), while a response indicates the outcome (status code) and provides the requested resource (body).
3. The Journey of a Single Request
Let's tie everything together and trace the complete journey of a single web request, from the moment you type a URL into your browser to the page rendering on your screen. This detailed view aligns with your interest in understanding the "under the hood" mechanics.
The communication doesn't start with HTTP directly. First, a reliable connection needs to be established. This is typically done using the Transmission Control Protocol (TCP). Think of TCP as establishing a dedicated, reliable phone line before you start your HTTP conversation.
The following video provides an excellent, detailed walkthrough of this entire process.
How an HTTP Request Gets Served - In Great Detail
This video details the end-to-end lifecycle of an HTTP request. It covers everything from finding the server's address to establishing a connection and exchanging messages.
Watch the following segments in order to trace the journey of a request: Parsing the URL (0:38 - 1:21): The browser identifies the protocol (HTTP/HTTPS) and domain. DNS Lookup (1:21 - 2:44): The browser finds the server's IP address (its 'phone number'). Establishing a TCP Connection (2:44 - 3:59): The client and server perform a 'three-way handshake' to open a reliable communication channel. Sending the HTTP Request (5:07 - 7:01): The client sends its message over the established connection. Generating and Sending the HTTP Response (8:41 - 9:40): The server processes the request, creates a response, and sends it back. Focus on understanding the sequence of events and the role each step plays in the overall communication.
This sequence—DNS lookup, TCP handshake, and then the HTTP request-response cycle—is fundamental to how the web works. For secure connections (HTTPS), there's an extra step involving a TLS handshake to encrypt the communication, which is also covered briefly in the video and the "A Deep Dive" article.
Conclusion
In this lesson, we established the foundational concepts for all of backend engineering. You've learned:
- The Client-Server Model: The web is built on a separation of concerns between clients (like browsers) that request resources and servers that provide them.
- HTTP as the Protocol: Clients and servers communicate using the Hypertext Transfer Protocol, which defines a standard request-response message format.
- The Request Lifecycle: A simple web request involves a complex but standardized sequence of events, including DNS lookup to find the server, a TCP handshake to establish a connection, and the HTTP message exchange.
You now have a mental model for what happens when a user interacts with a web application. You understand that your job as a backend engineer is to build the "server" part of this model: the system that listens for HTTP requests, performs logic, interacts with databases or other services, and sends back meaningful HTTP responses.
Preview of the Next Lesson:
In our next lesson, we'll zoom in on the first part of an HTTP request: the URL. We'll learn how URLs are structured and how web servers use them to route an incoming request to the correct piece of code that can handle it. This is the first step in translating a request into an action on the server.