learn.kevalabs

PostgreSQL 101: a quick introduction

2026-08-16T00:00:00+00:00

Prerequisites: none — this quick introduction stands on its own.

Where this fits: a full database course covers the theory, SQL in depth, and design. These notes are the practical minimum to start building: what the pieces are called, which tools talk to the database, and why it rejects bad data. That's enough to model real applications.

The difference between a spreadsheet and a database is one word: rules. A spreadsheet accepts whatever you type — a name in the age column, two students with the same ID, a blank where an email must be. A database lets you declare the rules once, then refuses every violation, forever, no matter which app or teammate does the writing. Everything in this guide is about where data lives and how those rules work.

The containers: server → database → schema → table

PostgreSQL names trip people up because database means both the software and one specific container inside it. There are four levels of nesting, and each has one job:

The practical version: one project = one database (your application's config points at exactly one), and unless you say otherwise everything lands in the default schema, public. When you meet university.public.students, read it right-to-left: the students table, in the public schema, in the university database.

Tables: columns are a contract

A table is defined by its columns — each with a name and a type — and filled with rows, one per record. Here's a real one:

CREATE TABLE students (
    id     integer      PRIMARY KEY,
    name   varchar(100) NOT NULL,
    email  varchar(254)
);

The types are already rules: integer refuses "twenty", varchar(100) refuses a 300-character name. Columns are the contract; rows are the data that signed it.

Constraints: the table defends itself

Types catch the wrong kind of data. Constraints catch data that's the right kind but still wrong:

PRIMARY KEY — this column is each row's identity: it must be unique and can never be missing. Two students with id 1? Rejected.
NOT NULL — this value is required. A student with no name? Rejected.

Try to break the table yourself:

The deep lesson: the database rejects bad data at the gate, at write time — instead of you discovering it months later and cleaning up. In a project with four teammates and three apps touching the same data, the table's own rules are the only ones everyone is forced to obey.

pgAdmin and the engine: a query's journey

So far we've talked about the server as a black box. Two things open it up: knowing what a client is, and knowing what happens inside the engine when a query arrives.

pgAdmin is the standard GUI client for PostgreSQL — a browsable tree of exactly the containers from the first simulator (server → databases → schemas → tables), plus a Query Tool where you type SQL. The crucial thing to understand: pgAdmin has no special powers. When you press F5 in its Query Tool, it sends your SQL over an ordinary network connection (port 5432, the PostgreSQL wire protocol) — the same connection that psql on the command line uses, and the same one your application or ORM uses. Every client is just a different way to put SQL on that wire.

On the server side, every query — no matter which client sent it — passes through the same pipeline of engine components:

Four components worth naming:

Parser — checks the SQL's grammar and turns text into a query tree. Typos die here.
Planner/optimizer — decides how to run it: scan the whole table, or jump straight to rows via an index? (Primary keys get an index automatically — one more thing PRIMARY KEY buys you.)
Executor — runs the chosen plan step by step.
Storage — shared memory buffers in front of the actual data files on disk; the executor reads and writes through them, and constraints are enforced right here at write time.

Keep this picture and two debugging superpowers follow: a syntax error means you never got past the parser; a slow query means the planner chose an expensive plan — different problems, different fixes.

Takeaways

Read the nesting right-to-left: table ⊂ schema (public by default) ⊂ database (one per project) ⊂ server.
Columns + types are a contract; rows are records that must honor it.
PRIMARY KEY = unique + not null identity for every row; NOT NULL = required field. Declare rules once, they're enforced forever.
Reject at the gate beats clean up later — constraints are the only rules every app and teammate must obey.
pgAdmin is just a client. GUI, psql, and your app all speak the same protocol to the same engine: parser → planner → executor → storage.
When your app's ORM throws an IntegrityError-style exception, that's a constraint firing — the database doing its job, not the framework being difficult.

References

Codd, E. F. (1970). A relational model of data for large shared data banks. Communications of the ACM, 13(6), 377–387. https://doi.org/10.1145/362384.362685
The pgAdmin Development Team. (n.d.). pgAdmin 4 documentation. Retrieved August 16, 2026, from https://www.pgadmin.org/docs/
The PostgreSQL Global Development Group. (n.d.). Constraints (PostgreSQL documentation, Chapter 5.5). Retrieved August 16, 2026, from https://www.postgresql.org/docs/current/ddl-constraints.html
The PostgreSQL Global Development Group. (n.d.). Overview of PostgreSQL internals (PostgreSQL documentation). Retrieved August 16, 2026, from https://www.postgresql.org/docs/current/overview.html
The PostgreSQL Global Development Group. (n.d.). Schemas (PostgreSQL documentation, Chapter 5.10). Retrieved August 16, 2026, from https://www.postgresql.org/docs/current/ddl-schemas.html

Server-side rendering in pure Python, part 2: rendering from PostgreSQL

2026-08-16T00:00:00+00:00

Prerequisites: part 1 (this builds directly on its code) and PostgreSQL 101 (databases, tables, constraints, pgAdmin). Time: ~45 minutes.

Part 1 had one honest weakness: STUDENTS was a Python list frozen into the program. Add a student? Edit the source, restart the server. Real applications don't work that way — the data lives in a database, and the server renders whatever is there right now. Today the fixed list dies. The plan: same server, same template, but render() gets its rows from PostgreSQL, per request.

Set up the database

Using psql or pgAdmin's Query Tool (this is the containers hierarchy in practice — a university database, default public schema, one table):

CREATE DATABASE university;
-- connect to it: \c university   (or open a pgAdmin Query Tool on it)

CREATE TABLE students (
    id     integer      PRIMARY KEY,
    name   varchar(100) NOT NULL,
    course varchar(50)  NOT NULL
);

INSERT INTO students VALUES
    (1, 'Asha',  'AI'),
    (2, 'Ravi',  'AI'),
    (3, 'Meena', 'Data Science');

The same PRIMARY KEY and NOT NULL constraints from PostgreSQL 101 now guard your lab data — try inserting a duplicate id and watch them work.

One new dependency

Python's standard library speaks HTTP but not PostgreSQL's wire protocol — remember from PostgreSQL 101 that every client talks to the engine over port 5432 in that protocol. The translator is a driver:

pip install "psycopg[binary]"

psycopg is exactly the "your app / ORM" box from the engine simulator: it opens the connection, sends your SQL down the wire, and hands rows back as Python tuples. That's the whole magic.

The server, now database-backed

Save as server.py — the diff from part 1 is small enough to read in one breath: STUDENTS is gone, fetch_students() is new, and render() now escapes its values (the lesson part 1 warned about):

# server.py — part 2: server-side rendering from PostgreSQL
from html import escape
from http.server import HTTPServer, BaseHTTPRequestHandler
from urllib.parse import urlparse, parse_qs

import psycopg  # pip install "psycopg[binary]"

DSN = "dbname=university user=postgres host=127.0.0.1"  # adjust user/password

PAGE = """<!doctype html>
<html>
<head><title>Students</title></head>
<body>
  <h1>Students — {course}</h1>
  <ul>
{rows}
  </ul>
</body>
</html>"""

def fetch_students(course):
    query = "SELECT id, name, course FROM students"
    params = []
    if course != "all":
        query += " WHERE course = %s"     # %s = placeholder, NOT string formatting
        params.append(course)
    query += " ORDER BY id"
    with psycopg.connect(DSN) as conn:
        with conn.cursor() as cur:
            cur.execute(query, params)    # the driver sends value separately
            return cur.fetchall()         # → [(1, 'Asha', 'AI'), ...]

def render(course):
    rows = "\n".join(
        f"    <li>{escape(str(sid))} — {escape(name)} ({escape(c)})</li>"
        for sid, name, c in fetch_students(course)
    )
    return PAGE.format(course=escape(course), rows=rows)

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        url = urlparse(self.path)
        if url.path != "/students":
            self.send_error(404, "try /students")
            return
        course = parse_qs(url.query).get("course", ["all"])[0]
        body = render(course).encode("utf-8")
        self.send_response(200)
        self.send_header("Content-Type", "text/html; charset=utf-8")
        self.send_header("Content-Length", str(len(body)))
        self.end_headers()
        self.wfile.write(body)

if __name__ == "__main__":
    print("serving on http://127.0.0.1:8000/students")
    HTTPServer(("127.0.0.1", 8000), Handler).serve_forever()

Run python3 server.py and open http://127.0.0.1:8000/students — same page as part 1, except the rows just crossed a network protocol to get to you.

The journey of one request

You've now met every piece of this pipeline in a previous guide. Watch them work as one machine:

Count the layers a single refresh touches: HTTP parsing (the servers guide), a SQL query over the wire, the engine's parser → planner → executor (PostgreSQL 101), rows back, the template merge (part 1), and an HTTP response. Two protocols, one page. Every Django, Rails, and Spring request you'll ever debug is this exact journey wearing a bigger coat.

Two injections, one law

Look closely at the two deliberate safety choices in the code:

SQL: the query uses %s and passes course as a parameter. The driver ships the value separately from the SQL text, so a visitor requesting ?course=AI'; DROP TABLE students;-- sends a harmless string, not a command. Never build SQL with f-strings.
HTML: every value goes through escape() before entering the page, so a student named <script>…</script> renders as text, not code — part 1's warning, now actually implemented.

Different layer, same law: data must never be allowed to become code. SQL injection and XSS are both what happens when that law is broken. (OWASP's cheat sheets below are the professional references.)

Prove it's live

The demo that separates part 2 from part 1 — while the server is running, in pgAdmin or psql:

INSERT INTO students VALUES (4, 'Tashi', 'AI');
UPDATE students SET course = 'Data Science' WHERE name = 'Ravi';

Now just refresh the browser. New student, moved student — no code edit, no restart. In part 1 that was impossible. The server doesn't contain the page; it manufactures it from current data, per request. That single sentence is what "database-backed server-side rendering" means.

Exercises

Constraint in the wild: INSERT a student with a duplicate id in pgAdmin, and confirm the error message matches the constraints simulator in PostgreSQL 101.
Sort and count: change the query to ORDER BY name, then add a line under the <ul> showing len(...) students rendered.
A second route: add /courses that renders SELECT DISTINCT course FROM students as a list of links to /students?course=....
Attack yourself, then fix it: make a copy where fetch_students builds the query with an f-string instead of %s, request ?course=AI' OR '1'='1, and watch the filter break (every student leaks). Restore the parameterized version and confirm the same URL is now harmless data.
Feel the connection cost: our code connects to PostgreSQL on every request. Move psycopg.connect to module level and reload rapidly — snappier? That's why real servers use connection pools (and what breaks with threads — recall exercise 4 of part 1).

References

OWASP Foundation. (n.d.). Cross site scripting prevention cheat sheet. Retrieved August 16, 2026, from https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
OWASP Foundation. (n.d.). SQL injection prevention cheat sheet. Retrieved August 16, 2026, from https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
The PostgreSQL Global Development Group. (n.d.). Queries (PostgreSQL documentation, Chapter 7). Retrieved August 16, 2026, from https://www.postgresql.org/docs/current/queries.html
The Psycopg Team. (n.d.). Psycopg 3 documentation. Retrieved August 16, 2026, from https://www.psycopg.org/psycopg3/docs/
Python Software Foundation. (n.d.). http.server — HTTP servers (Python documentation). Retrieved August 16, 2026, from https://docs.python.org/3/library/http.server.html

Server-side rendering in pure Python, part 1: from data to HTML

2026-08-16T00:00:00+00:00

Prerequisites: Python 3 installed, plus the ideas from How HTTP servers work and SSR vs CSR. Time: ~30 minutes.

Server-side rendering sounds like a framework feature. It isn't — it's just building a string of HTML from data, on the server, per request. Today you'll do it with nothing but Python's standard library, so there's nowhere for the magic to hide.

What "rendering" literally is

Before the server, understand the core move: a template with holes, data, and a merge:

That's the entire trick. Real template engines (Django's, Jinja2) add loops, inheritance, and — critically — escaping (more on that at the end), but the mental model stays: template + data → HTML string.

The server, complete

Save this as server.py — it's the whole lab, ~45 lines, standard library only:

# server.py — server-side rendering with only the standard library
from http.server import HTTPServer, BaseHTTPRequestHandler
from urllib.parse import urlparse, parse_qs

STUDENTS = [
    {"id": 1, "name": "Asha",  "course": "AI"},
    {"id": 2, "name": "Ravi",  "course": "AI"},
    {"id": 3, "name": "Meena", "course": "Data Science"},
]

PAGE = """<!doctype html>
<html>
<head><title>Students</title></head>
<body>
  <h1>Students — {course}</h1>
  <ul>
{rows}
  </ul>
</body>
</html>"""

def render(course):
    wanted = [s for s in STUDENTS if course in ("all", s["course"])]
    rows = "\n".join(
        f'    <li>{s["id"]} — {s["name"]} ({s["course"]})</li>' for s in wanted
    )
    return PAGE.format(course=course, rows=rows)

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        url = urlparse(self.path)
        if url.path != "/students":
            self.send_error(404, "try /students")
            return
        course = parse_qs(url.query).get("course", ["all"])[0]
        body = render(course).encode("utf-8")
        self.send_response(200)
        self.send_header("Content-Type", "text/html; charset=utf-8")
        self.send_header("Content-Length", str(len(body)))
        self.end_headers()
        self.wfile.write(body)

if __name__ == "__main__":
    print("serving on http://127.0.0.1:8000/students")
    HTTPServer(("127.0.0.1", 8000), Handler).serve_forever()

Run it and visit the page:

python3 server.py
# → http://127.0.0.1:8000/students

Read it as the server loop

Map the code onto the loop from How HTTP servers work — every stage is here:

accept + parse — http.server does both and calls do_GET with self.path filled in.
route — our humble if url.path != "/students" is the routing table (with send_error(404) as the fall-through).
handler — render(course): filter the data, build rows, fill the template. This is the dynamic lane from the static-vs-dynamic simulator, and the SSR lane from the race.
respond — status, Content-Type, Content-Length, body. The exact anatomy from the HTTP guide, typed by hand.

Notice ?course=AI — visit http://127.0.0.1:8000/students?course=AI and the server renders a different page from the same template. That per-request variation is what makes it dynamic.

Prove it's server-side

Three experiments, in order of persuasiveness:

View-source (Ctrl+U / Cmd+Option+U): Asha and Ravi are right there in the HTML. The browser received finished content.
Disable JavaScript in DevTools and reload: the page is identical. There is no JS to depend on.
curl it — a program with no rendering engine at all sees the full content:

curl "http://127.0.0.1:8000/students?course=AI"

Now do experiment 1 on a CSR app (any big dashboard-style site): the source shows a nearly-empty <div>. You can see the strategy difference you learned in SSR vs CSR.

One warning before you go: escaping

Our render() pastes data into HTML raw. If a student's name were <script>alert(1)</script>, we'd be injecting code into every visitor's browser — the classic XSS vulnerability. The stdlib fix is one function: pass every value through html.escape() from the html module. Real template engines escape by default, and that — not convenience — is the serious reason to use one in production.

Exercises

Add a column: give each student a year, show it in the row.
Add a route: /courses should render the list of distinct courses (hint: another template string + a second if in do_GET).
Escape it: import html and wrap every interpolated value in html.escape(). Then add a student named <b>Bold</b> and confirm it displays as text instead of becoming markup.
Break the loop (from the servers guide): add time.sleep(5) inside render() and open the page in two tabs at once. Which tab suffers, and why? (HTTPServer is single-threaded; try ThreadingHTTPServer and watch the difference.)

What's next

One honest limitation remains: STUDENTS is a list frozen into the source code — changing the data means editing the program and restarting it. Real applications render from a database. That's exactly part 2: same server, same template, but the rows come live from PostgreSQL.

References

MDN Web Docs. (n.d.). Introduction to the server side. Mozilla. Retrieved August 16, 2026, from https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Introduction
OWASP Foundation. (n.d.). Cross site scripting prevention cheat sheet. Retrieved August 16, 2026, from https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
Python Software Foundation. (n.d.). http.server — HTTP servers (Python documentation). Retrieved August 16, 2026, from https://docs.python.org/3/library/http.server.html
Python Software Foundation. (n.d.). html — HyperText Markup Language support (Python documentation). Retrieved August 16, 2026, from https://docs.python.org/3/library/html.html

How auth works: authentication vs authorization

2026-08-16T00:00:00+00:00

Prerequisites: How HTTP works — especially the cookies/sessions and status-code sections; this guide builds directly on both.

Two words that get mixed up constantly, and one distinction that untangles them:

Authentication answers "who are you?" — the login box, the password check, the session cookie.
Authorization answers "what may you do?" — and it's asked again on every single request, long after login.

They fail differently too: fail authentication and you get 401 Unauthorized ("prove your identity"); fail authorization and you get 403 Forbidden ("we know exactly who you are — no"). If you've read How HTTP works, you already have all the machinery: this whole topic is status codes plus cookies.

Authentication: proving who you are

HTTP is stateless — the server forgets you between requests. So authentication has two jobs: check your credentials once, then give you something to carry that proves the check happened. That something is a session cookie. Watch a full login:

Three details that matter in real systems:

The server never stores your password. It stores a hash — a one-way fingerprint. At login it hashes what you typed and compares fingerprints. A database leak then exposes fingerprints, not passwords. (Every serious framework does this by default.)
The session cookie is your badge, not your identity. The server keeps a table mapping sessionid → user; the cookie is just the claim ticket. That's why "log out everywhere" works — the server deletes its side of the mapping and every badge goes dead.
Browser apps redirect to /login (302); APIs answer 401. Same meaning, different audience: humans get a form, programs get a status code.

Authorization: what you may do

Being logged in is not permission. After authentication, every request still passes a second gate: does this user have the right to do this thing? The standard way to manage that is roles — bundle permissions into named jobs, assign users to roles:

Note what the simulator shows: the professor can delete the course but can't submit an assignment — authorization isn't a ladder where higher roles do everything, it's a matrix of who-does-what. And the check lives on the server: hiding a button in the UI is cosmetics, not security. A student who crafts a raw DELETE /course/42 request must still hit a 403.

401 vs 403: the debugging rule

401 Unauthorized → the server doesn't know who you are (or your session expired). Fix: authenticate. Misnamed by history — it really means unauthenticated.
403 Forbidden → the server knows who you are and the answer is no. Fix: get the permission, or stop asking.

When an app misbehaves, this pair tells you instantly which half of auth to debug.

Every framework ships this — your job is the matrix

None of the above is exotic: every serious web stack implements the same two gates, whatever the language. Stripped of syntax, the server-side logic is always:

on every request:
    user = session_table[ request.cookie("sessionid") ]     # authentication
    if user is missing:
        return 401  (or redirect to /login)

    if not permitted(user.role, request.action):            # authorization
        return 403

    handle the request

Django calls it contrib.auth, Spring calls it Spring Security, Rails has Devise, Laravel has guards and policies — same machinery, different names. Two consequences:

Don't hand-roll it. Password hashing, session management, and permission checks are exactly where home-made code gets breached. Use what your framework provides.
The part only you can do is design the permission matrix — the roles × actions table from the simulator, for your application's real actions. Sketch it before you code; it's a design document, not an afterthought.

Takeaways

Two questions, two gates: authentication once at login ("who are you?"), authorization on every request ("may you do this?").
401 = prove identity; 403 = identity proven, still no. Memorize the pair — it's your fastest debugging signal.
Passwords are stored as hashes, never plaintext. If a tutorial stores plaintext, close the tab.
The session cookie is a claim ticket, meaningful only against the server's session table.
Authorization lives on the server. Hidden buttons are UX; the 403 is the security.
Use your framework's auth machinery — whatever the stack — and spend your effort designing the permission matrix instead.

References

Barth, A. (2011). HTTP state management mechanism (RFC 6265). Internet Engineering Task Force. https://doi.org/10.17487/RFC6265
Fielding, R., Nottingham, M., & Reschke, J. (2022). HTTP semantics (RFC 9110). Internet Engineering Task Force. https://doi.org/10.17487/RFC9110
MDN Web Docs. (n.d.). HTTP authentication. Mozilla. Retrieved August 16, 2026, from https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Authentication
OWASP Foundation. (n.d.). Authentication cheat sheet. Retrieved August 16, 2026, from https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
OWASP Foundation. (n.d.). Authorization cheat sheet. Retrieved August 16, 2026, from https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html

How browsers work: from URL to pixels

2026-08-16T00:00:00+00:00

Prerequisites: How HTTP works — this guide assumes you know what requests, responses, and round trips are.

Fast sites feel fast because their developers understand two hard facts about the web:

Latency is the enemy. Every byte travels a physical distance, and the protocols underneath HTTP demand several round trips before the first byte of HTML even arrives.
The browser is (mostly) single-threaded. One main thread parses your HTML, runs your JavaScript, computes layout, and responds to the user's taps. Whatever you make it do, it can't do anything else at the same time.

Everything a browser does between "Enter" and "pixels" is shaped by those two constraints. Let's walk the whole pipeline, step by step. Each step comes with a simulator — press play or step through them; they're the point of this guide.

DNS: turning a name into an address

learn.kevalabs.com means nothing to a network router. Before anything can be requested, the browser needs an IP address, and it gets one through DNS — a hierarchy of caches and servers, asked in order from cheapest to most authoritative.

The important performance detail: every hop in that chain caches the answer. The first visitor pays the full trip; subsequent lookups are answered in microseconds from a cache nearby. But every unique hostname on your page — fonts CDN, analytics, image host — pays its own lookup, which is why piling up third-party domains hurts, especially on mobile networks where each lookup can take hundreds of milliseconds.

TCP and TLS: opening a trustworthy pipe

With an IP in hand, the browser can't just start sending HTML requests. First it must establish a TCP connection (the three-way handshake), and for HTTPS, negotiate TLS encryption on top of it. Watch how many times messages cross the wire before a single byte of your page moves:

Three round trips before the first byte of HTML. If the server is 100 ms away, that's 300 ms of pure protocol overhead — nothing downloaded yet. This is why HTTPS session resumption, HTTP/2 connection reuse, and QUIC/HTTP-3 (which merges the transport and crypto handshakes) exist: the handshakes are the tax, and modern protocols work hard to pay it once.

Step 2 — The response and the 14 KB rule

The request is out; the server responds with the first byte of HTML (Time To First Byte, TTFB). But the server can't firehose the whole page at once. TCP starts cautiously — a mechanism called slow start — sending a small initial window (~10 packets, about 14 KB), then doubling it after each acknowledged round trip:

That first ~14 KB window is why performance guides obsess over what's in the top of your HTML: if enough of the document (and its critical CSS) fits in the first window, the browser can start working after a single round trip. And congestion control cuts both ways — when a packet is lost, the window shrinks and rebuilds, which is the transport layer telling you that every kilobyte of critical path matters.

Step 3 — Parsing: from bytes to trees

Building the DOM

As HTML bytes stream in, the parser tokenizes them and builds the DOM tree — the object model of your document. Two things make this step interesting: some resources block the parser, and the browser cheats around that with a second, lightweight scanner. Here's the document the simulator parses:

<!doctype html>
<html>
<head>
  <link rel="stylesheet" href="style.css">
</head>
<body>
  <h1>Hi</h1>
  <img src="cat.png">
  <script src="app.js"></script>
  <p>Bye</p>
</body>
</html>

Two takeaways from that run:

A <script> without async or defer halts the parser — the script might document.write(), so the browser can't safely continue until it's downloaded and executed.
The preload scanner softens the blow: it races ahead of the blocked parser, spotting img, link, and script URLs and requesting them early, so the downloads are usually done by the time the parser catches up.

Building the CSSOM

CSS gets its own tree: the CSSOM. The browser parses every rule, then resolves what each node's final, computed style is — walking down the tree so that inheritance and the cascade (specificity, then source order) fall out naturally:

Building the CSSOM is fast, but it's render-blocking: the browser refuses to paint anything until it knows the final styles — a half-styled flash would be worse. Keep the CSS on the critical path small.

Meanwhile, off the main thread, JavaScript files are compiled, and the browser also builds an accessibility tree — the structure screen readers and other assistive tech actually consume.

Step 4 — Render: style → layout → paint → composite

The render tree

DOM and CSSOM combine into the render tree: only the nodes that will actually produce pixels. Non-visual nodes (<head>, <script>, <meta>) are dropped, and so is anything with display: none — but visibility: hidden stays, because an invisible box still occupies space:

Layout: where and how big?

With the render tree ready, the browser runs layout (also called reflow when it happens again): starting from the viewport width, it computes the exact position and size of every box. Resize the viewport in the simulator and watch every box get recomputed:

Layout is recursive and expensive — changing one element's width can dirty everything below it. This is why images without declared dimensions are a classic sin: each one that arrives forces another reflow (and a layout shift the user can see).

Paint and composite

Finally the browser paints — rasterizing each render-tree node into pixels (text, colors, borders, shadows, in a defined order) — and composites: layers get stitched together on the GPU. Some elements (transforms, will-change, videos, canvas) are promoted to their own compositor layer, and that has a huge consequence for animation:

Animate left and every frame re-runs style → layout → paint → composite on the main thread. Animate transform and the compositor slides an already-painted layer around — off the main thread, silky even while your JS is busy. This one habit separates janky UIs from smooth ones.

Step 5 — Interactivity: the main thread is a queue

The page looks ready — but "ready" only counts if it responds when tapped. Rendering work and your JavaScript share one main thread, and a long task blocks everything, including click handlers:

Time to Interactive is the moment the main thread is free enough to respond within ~50 ms. A page that paints in one second but ships a 2-second JavaScript boot task feels broken: clicks land in a queue and wait. Break long tasks up, defer what isn't critical, and move real computation to Web Workers.

Takeaways

Round trips dominate first-visit latency: DNS + TCP + TLS cost ~3 round trips before any HTML moves. Fewer unique hostnames, reused connections, and modern protocols (HTTP/2, HTTP/3) are how you pay less.
The first 14 KB is special — TCP slow start delivers it after one round trip. Fit your critical HTML/CSS in it.
CSS blocks rendering; sync scripts block parsing. Keep critical CSS lean; use defer/async everywhere you can. The preload scanner helps, but don't hide resources from it (e.g. behind JS-injected tags).
Layout is expensive and cascading. Declare image dimensions; batch DOM reads/writes.
Animate with transform and opacity, not left/top/width — compositor-only animations skip layout and paint entirely.
The main thread is the whole game for interactivity. Under ~50 ms per task, or the user feels it.

References

Allman, M., Paxson, V., & Blanton, E. (2009). TCP congestion control (RFC 5681). Internet Engineering Task Force. https://doi.org/10.17487/RFC5681
Grigorik, I. (2013). High performance browser networking. O'Reilly Media. https://hpbn.co/
Kosaka, M. (2018). Inside look at modern web browser (part 3). Chrome for Developers. https://developer.chrome.com/blog/inside-browser-part3
MDN Web Docs. (n.d.). Critical rendering path. Mozilla. Retrieved August 16, 2026, from https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/Critical_rendering_path
MDN Web Docs. (n.d.). How browsers work. Mozilla. Retrieved August 16, 2026, from https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/How_browsers_work
Mockapetris, P. (1987). Domain names—Concepts and facilities (RFC 1034). Internet Engineering Task Force. https://doi.org/10.17487/RFC1034
Rescorla, E. (2018). The Transport Layer Security (TLS) protocol version 1.3 (RFC 8446). Internet Engineering Task Force. https://doi.org/10.17487/RFC8446
WHATWG. (2026). HTML living standard: Parsing HTML documents. https://html.spec.whatwg.org/multipage/parsing.html

Structure follows MDN's How browsers work (CC-BY-SA); the prose, mistakes, and simulators are ours.

How HTTP servers work: the loop behind every response

2026-08-16T00:00:00+00:00

Prerequisites: How HTTP works — you'll need requests, responses, and status codes.

Strip away the mystique and an HTTP server is a surprisingly small idea: a program that never exits, listening on a port, answering one question over and over — "here's a request; what's the response?" Everything else (frameworks, routing, middleware, nginx) is engineering layered on that loop.

If you know how HTTP messages look on the wire, you already know the server's input and output. This guide is about what happens in between.

The loop: accept → parse → route → respond

When you run a server on port 8000, the operating system starts delivering TCP connections to your program. For each one, the server reads the raw request text, parses out the method and path, looks up which piece of code should handle that path, runs it, and writes the response back:

Two things to notice. First, the router is just a lookup table — path patterns on one side, functions on the other, and a fall-through to 404 when nothing matches. Second, the 404 in the simulator isn't an error in the server — it's the server working correctly, telling the client its request matched nothing. (That's the 4xx = client's-side rule from the HTTP guide.)

Static vs dynamic: read a file, or run code

Every response a server produces is one of two kinds, and the difference drives most of web architecture:

Static — the response already exists as a file (logo.png, style.css, this very page). The server's job is just read from disk and send bytes. Same answer for everyone, which makes static responses endlessly cacheable — by proxies, CDNs, and browsers.
Dynamic — the response is computed per request: run a handler, maybe query a database, build HTML or JSON on the spot. Your dashboard and my dashboard come from the same URL but different data.

This is why real deployments split the work: a fast static server or CDN handles files, and your application only wakes up for the dynamic part.

Surviving more than one client

Here's the problem the loop hides: while your handler is busy computing one response, new requests keep arriving. With a single worker, one slow request stops the whole site:

The two classic escapes:

More workers — threads or processes, each running the same loop. A slow request occupies one worker; the others keep serving. This is how Gunicorn/uWSGI-style servers run Python apps.
An event loop — one worker that never waits: whenever a request is blocked on the database or disk, it sets the work aside and serves someone else (Node.js, nginx, Python's asyncio).

If this sounds familiar, it should — it's the browser's main-thread lesson from How browsers work, mirrored on the server: whoever holds the only thread must never hold it long.

In production the pieces compose: a reverse proxy (nginx, Caddy, a cloud load balancer) sits in front, serves static files, ends the TLS connection, and spreads dynamic requests across a pool of application workers. Every "how do I deploy my app" tutorial is some arrangement of exactly these boxes.

Takeaways

A server is a loop: accept → parse → route → handler → respond. Frameworks decorate the loop; they don't replace it.
Routing is a lookup table, and 404 is the table's fall-through working as designed.
Static = read a file, dynamic = run code. Push static to CDNs/caches; spend your server on the dynamic part.
One worker means one slow request blocks everyone — scale with worker pools or an event loop.
Real deployments layer it: reverse proxy for static/TLS/balancing, application workers for the dynamic core.

References

Fielding, R., Nottingham, M., & Reschke, J. (2022a). HTTP/1.1 (RFC 9112). Internet Engineering Task Force. https://doi.org/10.17487/RFC9112
Fielding, R., Nottingham, M., & Reschke, J. (2022b). HTTP semantics (RFC 9110). Internet Engineering Task Force. https://doi.org/10.17487/RFC9110
Kegel, D. (2006). The C10K problem. Retrieved August 16, 2026, from http://www.kegel.com/c10k.html
MDN Web Docs. (n.d.). What is a web server? Mozilla. Retrieved August 16, 2026, from https://developer.mozilla.org/en-US/docs/Learn_web_development/Howto/Web_mechanics/What_is_a_web_server
nginx. (n.d.). Inside NGINX: How we designed for performance & scale. Retrieved August 16, 2026, from https://www.f5.com/company/blog/nginx/inside-nginx-how-we-designed-for-performance-scale

How HTTP works: the conversation behind every page

2026-08-16T00:00:00+00:00

Prerequisites: none — this is the first stop on the web-fundamentals path. Everything else builds on it.

Three facts explain almost everything about HTTP:

The client always speaks first. A server can't call your browser out of the blue — every exchange starts with a request and ends with a response. Everything the web does is built from that one shape.
It's text you can read. An HTTP/1.1 request is a few lines of plain text — you can type one by hand into a raw TCP connection and a real server will answer you. That simplicity is deliberate, and it's why the protocol was easy to extend for 30+ years.
It remembers nothing. HTTP is stateless by design: each request arrives with no memory of the last one. Every login session, shopping cart, and "stay signed in" checkbox is a workaround built on top — with cookies.

Let's walk the conversation end to end. Each concept has a simulator — press play or step through them.

Who's talking: client, proxies, server

HTTP is a client–server protocol. The client (your browser, curl, a mobile app — anything acting on your behalf) sends requests; the server answers with documents or data. But between them, the request usually passes through proxies — machines that can cache responses, filter content, balance load across servers, or log traffic, all without either end doing anything special:

The cache hit at the end is the important part: a proxy that already holds a fresh copy can answer instantly without bothering the origin server. Much of web performance engineering is arranging for exactly that to happen — which is why HTTP has an entire vocabulary of caching headers.

The message: a few lines of text

Here's a complete, real HTTP/1.1 exchange — first the request, then the response:

GET /guide.html HTTP/1.1
Host: learn.kevalabs.com
Accept-Language: en

HTTP/1.1 200 OK
Date: Sat, 16 Aug 2026 07:28:00 GMT
Server: keva-edge
Content-Type: text/html
Content-Length: 29769

<!doctype html>… (29,769 bytes of HTML)

Every request and response has the same anatomy — a start line, headers, a blank line, and an optional body. Step through each part:

Two details worth keeping: the Host header is what lets one machine serve many websites from a single IP address, and headers in general are HTTP's extension mechanism — new capabilities (caching rules, CORS, compression, auth) arrive as new headers, not new protocols. HTTP/2 encodes all of this in binary frames for efficiency, but the semantics are identical — what you learn here transfers unchanged.

Status codes: the server's verdict

The first line of every response carries a three-digit status code. The first digit tells you who's happy and who's at fault:

The classes matter more than memorizing individual codes: 2xx means success, 3xx means "look elsewhere" (the client follows automatically), 4xx means the client asked for something wrong, 5xx means the server broke while answering a valid request. That 4xx/5xx distinction is the first thing to check when debugging: it tells you which side of the wire to look at.

Stateless by design, sessions by cookies

HTTP treats every request as if it came from a stranger. That sounds like a flaw; it's actually what lets one server (or a hundred, behind a load balancer) handle millions of clients without keeping a conversation open for each. But then, how does a shopping cart survive from one click to the next?

The trick: the server hands the client a small token (Set-Cookie), and the client volunteers it back on every subsequent request (Cookie). The client carries the memory; the server just uses the token to look up state on its side. Sessions, logins, and "remember me" are all this one mechanism.

One connection or many

HTTP messages ride on TCP connections (with TLS on top for HTTPS), and how those connections are used changed dramatically across versions. Watch six resources being fetched under each model:

HTTP/1.0 paid a full TCP handshake for every resource. HTTP/1.1 introduced persistent connections — one handshake, requests one after another. HTTP/2 multiplexes: many requests and responses interleaved on a single connection at once, so one slow response no longer blocks the rest. HTTP/3 goes further, replacing TCP with QUIC so even the transport handshake all but disappears. (For why handshakes and round trips are so expensive in the first place, the next guide walks the full journey — How browsers work.)

What else rides on headers

Almost every other HTTP capability is "just headers," which is the payoff of fact #2 — an extensible, readable protocol:

Caching — Cache-Control, ETag, Last-Modified: the server tells clients and proxies what may be stored, and for how long.
Cross-origin access (CORS) — Origin and Access-Control-*: servers selectively relax the browser's same-origin rules.
Authentication — WWW-Authenticate / Authorization, or cookie-based sessions.
Content negotiation — Accept, Accept-Language, Content-Encoding: the same URL can serve French text or compressed bytes to the clients that ask for them.

Takeaways

Everything is request → response, client-first. If a design seems to need the server to speak first, you need a different mechanism (Server-Sent Events, WebSockets) — both of which start life as an HTTP request.
Read the raw messages when debugging. HTTP is text (or binary framing of the same semantics); curl -v shows you the actual conversation, and it settles arguments fast.
Status class before status code: 4xx → fix the request, 5xx → fix the server, 3xx → follow the trail.
Cookies are the client carrying the server's memory. Statelessness is a feature; treat session state as an explicit, deliberate add-on.
Fewer connections, fewer handshakes. Connection reuse and multiplexing are where whole round trips are won — the same lesson the next guide teaches from the browser's side.

References

Barth, A. (2011). HTTP state management mechanism (RFC 6265). Internet Engineering Task Force. https://doi.org/10.17487/RFC6265
Bishop, M. (2022). HTTP/3 (RFC 9114). Internet Engineering Task Force. https://doi.org/10.17487/RFC9114
Fielding, R., Nottingham, M., & Reschke, J. (2022a). HTTP/1.1 (RFC 9112). Internet Engineering Task Force. https://doi.org/10.17487/RFC9112
Fielding, R., Nottingham, M., & Reschke, J. (2022b). HTTP semantics (RFC 9110). Internet Engineering Task Force. https://doi.org/10.17487/RFC9110
MDN Web Docs. (n.d.). Overview of HTTP. Mozilla. Retrieved August 16, 2026, from https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Overview
Thomson, M., & Benfield, C. (2022). HTTP/2 (RFC 9113). Internet Engineering Task Force. https://doi.org/10.17487/RFC9113

Structure follows MDN's Overview of HTTP (CC-BY-SA); the prose, mistakes, and simulators are ours.

How rendering works: server-side vs client-side

2026-08-16T00:00:00+00:00

Prerequisites: How browsers work (the rendering pipeline) and How HTTP servers work (static vs dynamic responses).

A browser can only paint what its rendering pipeline is given: HTML. But your actual content — students, products, scores — lives in a database as data. Somewhere between the database and the screen, someone has to turn data into HTML. The entire server-side vs client-side rendering debate is one question:

Who builds the HTML — the server before sending, or the browser after arriving?

The race: same page, two strategies

Watch both approaches deliver the same student list, side by side:

The shape of the result is worth memorizing. SSR does its work before the first byte leaves: slower to start responding, but what arrives is immediately paintable. CSR responds instantly with a nearly-empty shell — great first byte! — then makes the user wait through a JS download, its execution, and a second round trip for data before anything real appears. On fast Wi-Fi you barely notice; on a phone on 4G, the CSR gap is very visible.

What actually travels the wire

The race explains when; this explains what. Step through the actual responses each strategy sends:

That difference — content in the HTML vs content arriving separately as JSON — has consequences beyond speed:

View-source is the SSR litmus test. If your data is in the page source, the server rendered it. (Your lab this week proves it — see below.)
Robots and previews read HTML. Search crawlers and link-preview bots get the SSR page's content for free; a CSR page shows them an empty <div> unless extra machinery steps in.
No JavaScript, no CSR. SSR pages degrade gracefully; a CSR page without its bundle is a blank rectangle.

So which one? (The honest trade-offs)

Neither wins outright — they optimize different moments:

aspect	server-side (SSR)	client-side (CSR)
First meaningful paint	Fast — the HTML arrives ready to paint	Slow — bundle download, then a JSON fetch, first
Navigating after load	Full page reload on every click	Instant, app-like updates
Server cost per view	Renders every page view (CPU per request)	Serves static files + JSON (cheap)
SEO & link previews	Content visible to crawlers for free	Needs extra machinery (prerendering)
With JavaScript off	Fully readable	Blank page

The rule of thumb: content sites lean SSR (blogs, docs, shops — first paint and SEO dominate), tools lean CSR (dashboards, editors — you load once, then interact for an hour). And the modern mainstream is deliberately both: frameworks like Next.js render the first view on the server, then hydrate — attach JavaScript so subsequent interaction behaves like CSR. Once you understand the two pure strategies, hybrids are just mixing the timelines you watched above.

Now prove it with your own hands: Server-side rendering in pure Python builds the SSR half in ~45 lines of standard library, no framework.

Takeaways

Rendering = turning data into HTML. The only question is where it happens.
SSR: server sends finished HTML → fast first paint, view-source shows content, works without JS, costs server CPU per view.
CSR: server sends a shell + bundle; the browser fetches JSON and builds the DOM → slow first content, excellent app-like feel afterwards.
Check view-source when you meet a new site — it tells you the rendering strategy in five seconds.
Modern frameworks hybridize (SSR first paint + hydration); you now have the vocabulary to read their docs.

References

MDN Web Docs. (n.d.). Introduction to the server side. Mozilla. Retrieved August 16, 2026, from https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Introduction
Osmani, A., Miller, J., & Grigorik, I. (2019). Rendering on the web. web.dev. Retrieved August 16, 2026, from https://web.dev/articles/rendering-on-the-web
Vercel. (n.d.). Rendering: server-side rendering (SSR) (Next.js documentation). Retrieved August 16, 2026, from https://nextjs.org/docs/pages/building-your-application/rendering/server-side-rendering

learn.kevalabs

PostgreSQL 101: a quick introduction

The containers: server → database → schema → table

Tables: columns are a contract

Constraints: the table defends itself

pgAdmin and the engine: a query's journey

Takeaways

References

Server-side rendering in pure Python, part 2: rendering from PostgreSQL

Set up the database

One new dependency

The server, now database-backed

The journey of one request

Two injections, one law

Prove it's live

Exercises

References

Server-side rendering in pure Python, part 1: from data to HTML

What "rendering" literally is

The server, complete

Read it as the server loop

Prove it's server-side

One warning before you go: escaping

Exercises

What's next

References

How auth works: authentication vs authorization

Authentication: proving who you are

Authorization: what you may do

401 vs 403: the debugging rule

Every framework ships this — your job is the matrix

Takeaways

References

How browsers work: from URL to pixels

Step 1 — Navigation: finding the server

DNS: turning a name into an address

TCP and TLS: opening a trustworthy pipe

Step 2 — The response and the 14 KB rule

Step 3 — Parsing: from bytes to trees

Building the DOM

Building the CSSOM

Step 4 — Render: style → layout → paint → composite

The render tree

Layout: where and how big?

Paint and composite

Step 5 — Interactivity: the main thread is a queue

Takeaways

References

How HTTP servers work: the loop behind every response

The loop: accept → parse → route → respond

Static vs dynamic: read a file, or run code

Surviving more than one client

Takeaways

References

How HTTP works: the conversation behind every page

Who's talking: client, proxies, server

The message: a few lines of text

Status codes: the server's verdict

Stateless by design, sessions by cookies

One connection or many

What else rides on headers

Takeaways

References

How rendering works: server-side vs client-side

The race: same page, two strategies

What actually travels the wire

So which one? (The honest trade-offs)

Takeaways

References