Today's Goals:
To understand where we are, let's see how we got here...
Single Computer
Everything stored locally. No sharing. No internet.
Connected Computers
Computers connected via networks. Early websites. Dial-up internet.
Millions of Devices & Servers
This is what we'll study! Systems split across many computers, working together seamlessly.
Key Insight: Modern applications don't run on a single computer. They're distributed across many computers, each with a specific role. This is called a distributed system.
The most common way to organize a distributed system is the client-server architecture. It divides responsibilities into two main roles:
The Requester
Your device: phone, laptop, browser
The Provider
Powerful computer storing data and running services
You (The Client):
Kitchen (The Server):
Core Principle: The client requests, the server responds. Simple as that!
No matter how complex an application is, it always has these three parts:
What users see and interact with
The pathway for communication
Where data and logic live
Real Example: Checking Instagram
Remember: We'll explore each of these components in detail, one at a time. First, let's understand what each one does...
Your Phone
WiFi or Cellular
Internet
Web Server
Just like humans speak different languages (English, Spanish, French), computers use protocols to communicate.
HTTP (HyperText Transfer Protocol) is the language of the web. It defines:
Why Servers? Imagine if Instagram stored all your photos on your phone. You'd run out of space instantly! Servers have:
Let's watch what happens when you check social media...
You open Instagram and pull to refresh your feed
(This happens on the CLIENT - your phone)
App creates a message: "Give me the latest posts"
(Sent through the NETWORK using HTTP)
Message travels through WiFi → Internet → Instagram's servers
(Happens in milliseconds!)
Instagram's server:
Server packages the posts and sends them back
(Travels back through the NETWORK)
Instagram app receives the data and displays it beautifully on your screen
(CLIENT renders the UI)
This entire cycle happens in less than a second! And it repeats every time you interact with any web application.
What it is: Fixed content that never changes
Example: A company's "About Us" page
We were founded in 2010.
We have 50 employees.
Our office is in New York.
This text is written directly in HTML and doesn't change unless a developer manually updates it.
Uses: Simple websites, documentation, blogs
What it is: Content that changes based on data or user actions
Example: Your personalized Instagram feed
You have 5 new messages.
Today is Sunday, January 11, 2026
Current temperature: 72°F
The name, message count, date, and temperature all change based on data from the server!
Uses: Social media, email, online shopping, dashboards
The Difference:
Every application needs to remember things. That's where databases come in!
1. You click "My Profile" button → Client sends request
2. Request reaches server → "Show posts for user Sarah123"
3. Server asks database → "Find all posts where user = Sarah123"
4. Database returns → 10 posts with photos, captions, dates
5. Server formats data → Organizes posts newest to oldest
6. Client displays posts → You see your beautiful photos!
How it works:
How it works:
Why React? In a real app, you might show the same data in 50 different places. React automatically keeps all 50 places updated when the data changes. Traditional JavaScript requires updating all 50 manually - easy to make mistakes!
An API is like a menu at a restaurant - it tells you what you can request and how to request it!
Menu (API):
You don't need to know:
You just need to know: What to order and how much it costs!
Weather API:
You don't need to know:
You just need to know: What URL to call and what format to expect!
Your App
"I need weather data"
Uses the Weather API
"GET /weather?city=NewYork"
Weather Server
"Here's the data: 72°F, Sunny"
REST (Representational State Transfer) is a set of simple rules for designing web services. Think of it as a menu for your server!
In REST, everything (users, posts, products) is treated as a resource with its own unique address (URL).
GET /api/posts
→ Get a list of all blog posts
GET /api/posts/42
→ Get the specific post with ID 42
POST /api/posts
→ Create a new blog post
Send data: title, content, author
PUT /api/posts/42
→ Update post 42
Send new data: updated title or content
DELETE /api/posts/42
→ Delete post 42
Why This Matters: REST makes APIs predictable! If you know one REST API, you can guess how others work. It's like knowing that in every restaurant, you order from a menu and pay at the end - consistent patterns make life easier!
React
User Interface
HTML/CSS/JS
Structure & Style
HTTP/HTTPS
Communication Protocol
REST API
Structured Requests
Node.js
JavaScript Runtime
Express
Web Framework
MongoDB
Database