Introduction to Client-server Architecture

Session 1: Servers and Clients

The “Cloud” isn’t Magic

Figure: A whimsical illustration of a cloud being unzipped to reveal racks of computer servers inside. The style should be modern, clean line art with blue and white tones.

The Cloud is just someone else’s computer.

• Hook: We often talk about the “Cloud” as this abstract, magical entity.
• Today, we’re going to demystify it.
• When you strip away the marketing, the cloud is physically just servers—computers—racked in a datacenter, listening for your messages.

Server-Side Website Programming

• Web browsers and servers communicate via HyperText Transfer Protocol (HTTP).
• Every action—clicking a link, submitting a form, or searching—triggers an HTTP Request from the browser to the server.
• Same for mobile apps.

The web server “listens” for incoming messages, processes the logic, and returns an HTTP Response.

Capabilities of Server-Side Programming

1. Efficient Information Delivery
2. Tailored User Experiences
3. Controlled Access & Security
4. Session & State Management
5. Data Analysis

Efficient Information Delivery (1/5)

Instead of creating millions of static HTML files, servers use databases to dynamically construct pages.

1. Dynamic Generation: Templates are populated with data (JSON, XML, HTML) on the fly.
2. Scalability: Handles vast inventories (Amazon) or billions of posts (Facebook) using a single layout structure.
3. Cross-System Sharing: Inventory databases can sync across web stores and physical shops simultaneously.

Note: Your imagination doesn’t have to work hard to see the benefit of server-side code for efficient storage and delivery of information:

1. Go to Amazon or some other e-commerce site.
2. Search for a number of keywords and note how the page structure doesn’t change, even though the results do.
3. Open two or three different products. Note again how they have a common structure and layout, but the content for different products has been pulled from the database.

For a common search term (“fish”, say) you can see literally millions of returned values. Using a database allows these to be stored and shared efficiently, and it allows the presentation of the information to be controlled in just one place.

Tailored User Experiences (2/5)

Servers store and analyze client data to provide convenience and personalization:

1. Saved Preferences: Persistent storage for credit cards, shipping addresses, and search history.
2. Location Awareness: Services like Google Maps provide routing based on real-time or saved locations.
3. Predictive Logic: Autocomplete and search suggestions based on deep analysis of user habits.

Note: Google Maps saves your search and visit history. Frequently visited or frequently searched locations are highlighted more than others.

1. Google search results are optimized based on previous searches.
2. Go to Google search.
3. Search for “football”.

Now try typing “favorite” in the search box and observe the autocomplete search predictions.

Coincidence? Nada!

Controlled Access & Security (3/5)

Server-side logic acts as a gatekeeper for sensitive or private data:

1. Authentication: Restricts data access to authorized users (e.g., Online Banking).
2. Permissions: Social media platforms use server code to determine who can see specific posts or feeds.

Note: Consider other real examples where access to content is controlled. For example, what can you see if you go to the online site for your bank? Log in to your account — what additional information can you see and modify? What information can you see that only the bank can change?

Session & State Management (4/5)

Servers use sessions to “remember” users as they navigate or return to a site:

1. Persistence: Staying logged in across multiple tabs or resuming a game where you left off.
2. Business Logic: Tracking article views on news sites to trigger subscription prompts via cookies.

Note: Visit a newspaper site that has a subscription model and open a bunch of tabs (e.g., The Age). Continue to visit the site over a few hours/days. Eventually, you will start to be redirected to pages explaining how to subscribe, and you will be unable to access articles. This information is an example of session information stored in cookies.

Data Analysis (5/5)

Websites use server-side logic to log and monitor user interactions that occur beyond simple page views:

1. Behavioral: What you search for, recommend, and how long you stay on a specific page.
2. Transactional: Purchase history, cart additions, and payment methods.
3. Contextual: Device type, location (via IP), and referral sources.

Analyzing data on the server rather than the client (browser) offers critical technical advantages:

• Accuracy: Bypasses browser-based ad blockers and privacy settings that often strip out tracking scripts.
• Data Enrichment: The server can combine “live” click data with “historical” data from a CRM (Customer Relationship Management) database to create a complete user profile.
• Privacy Control: Sensitive data can be cleaned or anonymized on the server before being sent to third-party analytics tools.

Physical vs. Logical

Figure: Two diagrams. Top: ‘Physical’ showing a Laptop connected to a Server Rack. Bottom: ‘Logical’ showing two software boxes ‘Browser’ and ‘Localhost Server’ both inside the same Laptop icon.

Logical Tier \(\neq\) Physical Tier.

• Crucial distinction: “Client” and “Server” are roles, not just boxes.
• Physical: Your laptop vs AWS.
• Logical: You can run both on your laptop (localhost).
• This is how we develop. We simulate the world on one machine.

Examples in the Wild

LSP vs No LSP. Note that MCP (Model-Context Protocol) is influenced by LSP.

• IDE (LSP): Editor (Client) \(\leftrightarrow\) Language Server.
• Jupyter: Notebook (Client) \(\leftrightarrow\) Kernel (Server).

• It’s not just web browsers.
• Jupyter: You can run the interface on your laptop, but the Kernel on the Cloud.
• When you code in VS Code, the “Client” is the UI, and a separate “Server” provides errors/autocomplete.
• The protocol they use to communicate is called LSP (Language Server Protocol)

Session 2: Client-server overview

Overview of HTTP

• Core Definition: An application-layer protocol for fetching resources (HTML, images, video).
• Architecture: A client-server model where the recipient (User-Agent) initiates requests.
• Transport: Primarily runs over TCP or TLS-encrypted connections for reliability.

HTTP is the foundation of data exchange on the Web. While it usually runs over TCP, it can theoretically use any reliable transport protocol.

Key Components: Clients & Servers

• User-Agent: Any tool acting for the user (usually a browser). It is always the entity initiating the request.
• Web Server: A virtual machine or collection of machines (load balancers) that serves the requested document.
• Proxies: Intermediate nodes performing caching, filtering, load balancing, or authentication.

Proxies sit between them, operating at the application layer to manage traffic and security.

The HTTP Flow

1. TCP Connection: Establishing a reliable channel for message exchange.
2. The Request: Sending a human-readable (or binary frame) message to the server.
3. The Response: Reading the status code and resource returned by the server.
4. Conclusion: Closing or reusing the connection for the next request.

HTTP/2 introduced multiplexing, allowing multiple requests to be sent over a single “warm” connection simultaneously.

URL Anatomy

Figure: Example URL: http://example.com/api/users?id=123&status=active

• Scheme: http (Protocol).
• Host: example.com (Where).
• Path: /api/users (What).
• Query: ?id=123&status=active (Parameters).

• Explaining: Let’s dissect a URL. It’s not just a random string; it has anatomy.
• Scheme: How are we talking? (HTTP/HTTPS).
• Host: Which building are we going to? (Server address).
• Path: Which room in that building? (Resource location).
• Query: Specific instructions? (Sort by price, Page 2).
• Landmark: Understanding this structure helps you debug why a request might be failing.

Parameters in the Query String

Common Use Cases:

• Filtering: ?category=electronics&sort=price_desc
• Searching: ?q=how+to+build+a+website (note: + is URL encoded for space)
• Tracking: ?utm_source=newsletter (Commonly used in marketing analytics).
• Pagination: ?page=2

• While query strings are great for bookmarkable links (like search results)
• the request body (POST) is the standard for complex or secure data transmission.

Resources vs Representations

Figure: An abstract cube labeled ‘Resource (User)’. Two arrows point from it to ‘JSON File’ and ‘HTML Page’. Text: ‘One Resource, Many Representations’.

• Resource: The concept (e.g., User Profile).
• Representation: The format (.json, .html).
• Content Negotiation: “I speak JSON, please send JSON.”

• Explaining: There is a Zen-like distinction in REST between the Thing and the Representation of the Thing.
• Storytelling: Think of a “User Profile.” That is the Resource.
• But how do I give it to you?
  • I can write it on paper (HTML).
  • I can burn it onto a CD (binary).
  • I can read it aloud (JSON).
• You ask for the Resource, but the server sends a Representation. Negotiating the best format is key to flexible APIs.

HTTP Methods

• GET: Retrieve a representation of a resource (Read).
• POST: Create a new resource within a collection (Create).
• PUT: Replace an entire resource or create if missing (Update/Replace).
• PATCH: Apply partial modifications to a resource (Partial Update).
• DELETE: Remove a specific resource (Delete).

• MDN Web Docs emphasize that GET and HEAD methods are “safe” because they do not change the state of the server
• whereas POST, PUT, and DELETE are intended to modify data.

HTTP Message: Request

Figure: HTTP Request Message Components

• Header: Metadata (Context, Auth, Negotiation).
• Body: Payload (Data, Files) - Empty in GET.
• Separation: Headers tell us how to process the Body.

• Explaining: Think of an HTTP request like a physical letter or package.
• Landmark: There are two main parts: the Envelope (Headers) and the Contents (Body).
• The Header contains metadata: “I am using Chrome,” “I want JSON data,” or “Here is my ID badge (Cookie).” This tells the server how to handle the message.
• The Body is the actual cargo. If you’re uploading a photo, the photo accounts for the bytes in the body.
• Reasoning: Why separate them? It allows the server to make decisions (routing, authentication) without having to open the entire package first.

Some Request Headers

Illustration of a client and server negotiating content format.

• User-Agent: “Hello, I am Firefox”.
• Accept: “I want JSON”.
• Accept-Encoding: “Please gzip the response” (Compression).

• Storytelling: Imagine walking into a bakery in Paris.
• You say, “Bonjour” (Handshake), and “I would like a baguette” (Request). But you also add, “I only speak English” (Accept-Language) and “Please put it in a bag” (Accept-Encoding).
• Explaining: This is Content Negotiation. The client tells the server what it can handle.
• Reasoning: Compression (gzip) is critical because bandwidth costs money and time. If we can shrink a text file by 70% before sending it, the website loads faster. The browser then “unzips” it automatically.

HTTP Response Status Codes

Figure: A traffic light arrangement. Green light labeled ‘200 OK’. Yellow light labeled ‘301 Redirect’. Red light labeled ‘404/500 Error’.

• 200 OK: Success.
• 301/302: Redirect (Moved).
• Client error (400 – 499):
  • 400 Bad Request: You sent garbage.
  • 401 Unauthorized: Who are you?
  • 403 Forbidden: Not allowed.
  • 404 Not Found: Are you lost?
• 500 Internal Error: Server exploded.

• Landmark: Status codes are the traffic lights of the web.
• Explaining: The first digit tells the story:
  • 2xx: “All Good.” Green light.
  • 3xx: “Go over there.” Detour.
  • 4xx: “You messed up.” The client sent a bad request.
  • 5xx: “I messed up.” The server crashed.
• Storytelling: If you walk into a store and ask for a product they don’t sell, that’s a 404 (Your mistake). If you walk in and the shelf falls on you, that’s a 500 (Their mistake).

See HTTP response status codes | MDN.

Session 3: DNS, State, Proxies, and Security

The Address Problem

Figure: A person looking confused at a long string of numbers ‘142.250.190.46’. A thought bubble shows ‘google.com’.

Humans remember Names. Machines leverage IPs.

• Hook: Try to memorize 142.250.190.46. Now try to memorize google.com.
• Reasoning: Humans are terrible at remembering unique strings of numbers. We are great at language.
• Computers complement this: they are terrible at ambiguity but great at precise numerical addressing.
• We need a system to bridge this gap.

DNS: The Address Book

Figure: An Address Book Mapping Domain Names to IP Addresses

Domain Name System matches Names to IPs.

• Explaining: DNS is the phonebook of the internet.
• You look up a name (Google), and it gives you the number (IP Address) to dial.
• Landmark: It’s hierarchical.
  • Read right-to-left: .com (Top Level), google (Domain), maps (Subdomain).
• Without DNS, we’d be memorizing IP addresses for every website we visit.

Localhost

Figure: A looping arrow connecting a computer back to itself. Text label: ‘127.0.0.1’ and ‘Home’.

localhost = 127.0.0.1 “There’s no place like home.”

• Explaining: There is a special IP address reserved for “This Computer.”
• 127.0.0.1 is Localhost. It’s the digital equivalent of talking to yourself.
• Reasoning: Why do we need this? It allows us to run a server and a client on the same machine for development.
• When you ping localhost, the signal never leaves your potential network card. It loops right back.

Try It

1. Edit /etc/hosts (Mac/Linux) or System32/.../hosts (Win).
2. Map 127.0.0.1 to me.com.
3. Browser -> http://me.com -> Your Local Server.

• This proves DNS isn’t magic. It’s just a lookup.
• You can override it locally for your machine.
• Great for development (simulating production domains).

Stateless Conversation

Figure: A comic strip style sequence. Panel 1: Client asks for page. Server gives page. Panel 2: Client asks again. Server looks blank and says ‘Who are you?’.

• Definition: Server retains no memory of past requests.
• Implication: Every request must contain all necessary info (Auth, Context).
• Feature, not Bug: Easier to scale (Load Balancing).

• Landmark: This is the most important concept in HTTP: Statelessness.
• Storytelling: Imagine a barista who has amnesia.
• You order a latte. They make it. You come back 5 seconds later for sugar. They look at you blankly and say, “Who are you?”
• Reasoning: This sounds annoying, but it’s great for scale. If that barista takes a break, any other barista can help you because you have to re-state your order anyway.
• In tech terms: If Server A dies, Server B can take over immediately because no “memory” was lost on Server A.

Problem: Shopping Cart?

Figure: Shopping Cart

How do we build Stateful shopping carts on a Stateless protocol?

• Hook: So if the web is stateless, how does Amazon remember items in your cart?
• How do you stay logged in to Facebook?
• We need a way to build State on top of a Stateless protocol.

Cookies: Managing State

Figure: A waiter (Server) sticking a post-it note (Cookie) on a customer’s (Client) jacket. Next time the customer comes in, the waiter reads the note.

• The Problem: How to stay “Logged In” if HTTP is stateless?
• The Solution: Cookies (Client-side fast storage).
• Mechanism: Server sends Set-Cookie. Browser sends it back automatically.

• Explaining: The solution is the Cookie.
• Think of it like a coat check ticket or a VIP badge.
• When you first log in, the server gives you a badge (Cookie).
• Landmark: The magic is that your browser automatically pins this badge to every single subsequent request you make to that server.
• The server sees the badge and says, “Ah, welcome back, User 123.”

The “Web Server”

• Virtual Presence: Appears as a single entity to the client, but often represents a complex infrastructure.
• Composition: Can include load balancers, caches, and database servers working in tandem.
• Shared Hosting: Multiple software instances can coexist on one physical machine, often sharing an IP via the Host header.

• Explaining: A “server” is rarely just one computer anymore. It is a logical concept.
• Storytelling: When you visit google.com, you aren’t talking to a single machine under a desk in California. You are talking to a massive distributed system that acts like a single responder.
• Reasoning: This abstraction allows for Shared Hosting. A single physical machine can host bobspizza.com and alicesbakery.com.

Proxies: The Middlemen

User Agent acting on behalf of the User making requests and recieving responses. Proxies in-between the User-Agent and the Server.

Proxies are essential for performance and security.

Functions of a Proxy

• Caching: Stores copies of resources to serve future requests faster.
• Filtering: Performs antivirus scans or implements parental controls.
• Load Balancing: Distributes incoming traffic across multiple backend servers.
• Authentication: Validates user credentials before allowing access to resources.
• Logging: Tracks request history for security and analytics.

• Landmark: Proxies are the silent workhorses of the web.
• Explaining: A proxy sits between you (the client) and the destination (the server). It acts on your behalf.
• Reasoning: Why use them?
  • Caching: If 100 people ask for the same logo, the proxy saves it once and serves it 99 times. Faster for you, cheaper for the server.
  • Security: Corporate firewalls are proxies that filter “bad” sites.
• Storytelling: It’s like sending your assistant to buy coffee. The barista doesn’t know you ordered it, they just see the assistant.

Securing Sensitive Information

Credit Card Information Transmission over TLS Encrypted Channel (HTTPS).

• HTTP: Plain text (Dangerous).
• HTTPS: Encrypted (TLS/SSL).
• What is Encrypted?: Headers, Body.
• What is Visible?: URL, Path, IP Address, Port, Domain.

• Explaining: Standard HTTP is like sending a postcard. Anyone handling the mail (routers, ISPs) can read it.
• Reasoning: This is dangerous for passwords and credit cards.
• HTTPS wraps that postcard in an unbreakable, armored envelope.
• Landmark: Crucial Detail—The mailman still needs to know the Destination Address (IP) and the House Name (Domain), but they cannot see the Letter Contents (Body) or even the Specific Room (Path).

Session 4: REST APIs

Nouns and Verbs

REST is a set of practices mapping HTTP methods to actions on resources.

• Nouns (Resources): Represent the “what” of the request.
• Verbs (Actions): Represent the “how” or the operation being performed.

According to the original dissertation by Roy Fielding and supplemental MDN documentation: - resources (nouns) should always be plural and represent entities - while methods (verbs) define the transition of state.

Naming Conventions (Nouns)

• Objects: Use /articles instead of /getArticles.
• Nested: Use /authors/42/books to show relationship.

Official RESTful design patterns documented by MDN suggest avoiding verbs in URLs to maintain the separation of concerns between the protocol (HTTP verbs) and the data (resource nouns).

RESTful Endpoints Meaning

• GET /users -> List all.
• GET /users/1 -> Get specific one.
• POST /users -> Create new.
• PUT /users/1 -> Replace it.
• PATCH /users/1 -> Update it.
• DELETE /users/1 -> remove it.

• The URL + Verb tells the whole story.
• This is the beauty of REST. It’s predictable.