Core Development
Web Fundamentals
Before you build the frontend a user clicks or the backend that powers it, you need to understand the infrastructure that gets a website from a codebase to a real, reachable address on the internet — how a domain is bought, how DNS points it at a server, how that server talks to a browser, and how modern companies structure that server-side world at scale.
Topic Map
Everything in this module, at a glance
In Depth
Every topic, explained — with real-world industry context
Domain Registration & DNS
A domain name is a human-readable address rented (not owned outright) through a registrar, and DNS is the system that translates it into the actual IP address of a server.
- Buying a domain — registrars, WHOIS & renewal
- DNS record types: A/AAAA (IP address), CNAME (alias), MX (mail), TXT (verification)
- Nameservers & how a DNS query actually resolves
- TTL & propagation — why DNS changes take time to take effect
Real-World Industry Use Case
Every time you set up a custom domain for an app — pointing "yourapp.com" at Vercel or AWS — you are directly configuring A and CNAME records. MX records are why "[email protected]" actually reaches an inbox instead of vanishing.
Web Servers & Hosting
A web server is software that listens for requests and returns responses — hosting is where and how that server actually runs.
- Web servers vs. application servers (Nginx/Apache vs. Node/Django)
- Hosting types: shared, VPS, dedicated & cloud hosting
- Static hosting & CDNs vs. dynamic server-rendered hosting
- SSL/TLS certificates & why HTTPS is now the default expectation
Real-World Industry Use Case
Nginx alone powers a huge share of the web's highest-traffic sites as a reverse proxy and load balancer. Choosing "static hosting on a CDN" vs. "a full server" is one of the first real architecture decisions on every new project — and directly affects both cost and speed.
Client-Server Architecture
The foundational model of the entire web: a client requests, a server responds — understanding this cycle explains almost everything that happens when you use an app.
- The request-response cycle in detail
- Stateless vs. stateful communication
- Reverse proxies & load balancers sitting between client and server
- Where the frontend ends and the backend begins
Real-World Industry Use Case
DNS resolution itself is a real-world example of client-server architecture — a stub resolver (client) queries a caching name server, which may itself be a client to another server further up the chain, all the way to authoritative root servers.
Types of Web Services
Once a client and server can talk, they need an agreed-upon format for exchanging data — different web service styles trade off simplicity, flexibility, and performance differently.
- REST — resource-based, uses standard HTTP verbs (GET/POST/PUT/DELETE)
- GraphQL — a single endpoint where clients ask for exactly the data they need
- gRPC — a high-performance, binary protocol built on HTTP/2 & Protocol Buffers
- SOAP & WebSockets — legacy enterprise APIs and real-time bidirectional connections
Real-World Industry Use Case
The Twitter/X API is built on REST. GitHub moved its own API to GraphQL in 2017 specifically to let clients fetch exactly the fields they need in one request. Many companies now run all three side by side: REST for public partner APIs, GraphQL for mobile clients, and gRPC for fast internal microservice-to-microservice calls.
Microservices Architecture
As applications grow, teams often split one large codebase into many small, independently deployable services — each owning a single business capability.
- Monolith vs. microservices — the trade-offs of splitting a codebase
- Service-to-service communication — API gateways & service meshes
- Types of microservices patterns: domain-driven, event-driven & sidecar
- Containerization as the enabling technology (a preview of the DevOps module)
Real-World Industry Use Case
Netflix and Amazon are the textbook examples of migrating from a single monolith to hundreds of independent microservices — specifically so that one team's deploy or bug can't take down the entire platform.
Distributed Systems
A microservices architecture is one specific example of a distributed system — components on separate machines coordinating over a network instead of running in a single process.
- The CAP theorem — consistency, availability & partition tolerance trade-offs
- Replication — copying data across machines for reliability
- Sharding — splitting data across machines for scale
- Consensus & fault tolerance — agreeing on truth when parts of the system fail
Real-World Industry Use Case
Every time a global app like Instagram stays up despite an entire data center going offline, it's because of replication and fault-tolerant distributed design. This module is the direct on-ramp to the full System Design module later in the program.
Ready to learn this — live?
See how this module fits into the complete curriculum.