Glossary

Terms You Actually Need

No CS degree required. Plain English definitions of the terms you encounter daily as a vibe coder — with diagrams.

Jump to

🎫 JWT 🔑 OAuth 🍪 Cookie 🪪 Session 🌐 CDN ⚡ Serverless 🪝 Webhook 🔌 API 🛡️ Row

🎫

JWT (JSON Web Token)

When you log in, your server creates a JWT. It's a string that looks like gibberish but contains your user ID, an expiry time, and a cryptographic signature. Every time you make a request, you send this token. The server reads it, verifies the signature, and knows who you are — without looking you up in a database every time.

The three parts: Header (type + algorithm) . Payload (your data) . Signature (proof nobody tampered with it). Separated by dots.

Why it matters: JWTs let your server be "stateless" — it doesn't need to remember who's logged in because the proof of identity travels with every request.

How it works

Client → Server: "Here's my email + password"
Server → Client: "Here's your JWT (valid 7 days)"
Client → API: "Here's my JWT" (every request)
API: Reads JWT → verifies signature → knows who you are
→ No database lookup needed

OAuth

A standard for letting users log in with Google/GitHub without sharing their password with you.

OAuth is a protocol (a set of rules) that lets a user say "I allow this app to log me in using my Google account." Google verifies the user's identity and tells your app "yes, this person is who they say they are" — without your app ever seeing the user's Google password.

The flow: User clicks "Sign in with Google" → gets redirected to Google → approves access → Google redirects back to your app with a short-lived code → your app exchanges that code for an access token → you now know who the user is.

Why it matters: You don't store passwords. Users trust familiar login screens. You get the user's email and name from a verified source.

How it works

User: "Sign in with Google"
Your App → Google: "This user wants to authenticate"
Google → User: "Do you allow [App Name] to access your email?"
User: "Yes"
Google → Your App: "Here's an auth code"
Your App → Google: "Exchange this code for a token"
Google → Your App: "Here's the token + user info"
Your App: User is logged in

Session

A record on the server that proves you're logged in.

A session is a server-side record of your login. When you log in, the server creates a session (usually stored in a database or Redis) with a unique ID. That ID gets sent to your browser as a cookie. On every request, your browser sends the ID back, the server looks it up, finds your session, and knows who you are.

Sessions vs JWTs: Sessions require a database lookup on every request (stateful). JWTs carry the data inside the token (stateless). Sessions can be invalidated immediately by deleting the record. JWTs can't be invalidated until they expire — which is why refresh token patterns exist.

Why it matters: "Logging out" on most sites just deletes the session record. Without it, even a stolen cookie would be useless.

How it works

Login:
Browser → Server: email + password
Server → Database: INSERT sessions (user_id=123, token=xyz)
Server → Browser: Set-Cookie: session_token=xyz

Every request:
Browser → Server: Cookie: session_token=xyz
Server → Database: SELECT * FROM sessions WHERE token=xyz
Database → Server: {user_id: 123, expires: ...}
Server: User 123 is logged in

CDN (Content Delivery Network)

A network of servers around the world that caches your files so they load faster.

When you host a website on a single server in Virginia, a user in Singapore has to wait for the data to travel across the world. A CDN solves this by copying your static files (HTML, CSS, JavaScript, images) to servers in 50+ cities. When someone in Singapore requests your site, they get it from the Singapore CDN server — milliseconds away, not seconds.

What CDNs cache: Static files that don't change per-user. Your homepage HTML, CSS bundles, JS files, images. What they don't cache: Dynamic content, API responses with user-specific data, anything that changes per-request.

Vercel and Netlify are essentially CDNs with a build pipeline attached. S3 + CloudFront is the raw version.

How it works

Without CDN:
User (Singapore) → Your Server (Virginia): 300ms round trip

With CDN:
Your Server → CDN: "Here are my static files" (happens once on deploy)
CDN copies files to 50+ servers worldwide

User (Singapore) → CDN Singapore node: 20ms round trip
CDN Singapore → User: serves cached file

Serverless Function

Code that runs on demand in the cloud, no server required.

A serverless function is a piece of code that runs when called, then stops. You don't manage a server. You don't pay when it's idle. It just exists as a function, and the cloud runs it whenever someone calls its endpoint.

Next.js API routes become serverless functions on Vercel/Netlify. You write a normal function, they wrap it in AWS Lambda or equivalent, and it scales automatically from 0 requests to 1 million.

The trade-off: Cold starts. When a function hasn't run in a while, the first request has to "wake it up" — this can add 100-500ms of latency. For a hobby project: fine. For a real-time app: noticeable.

Why it matters: It's why your Vercel API routes "just work" without a separate Express server. But it's also why you might see occasional slow requests.

How it works

Traditional server:
Server: [always running, always using memory/CPU, you pay 24/7]
Request → Server → Response (fast, no cold start)

Serverless:
No request? No cost. Function = off.
Request arrives → Cloud: "spin up the function"
Cold start: 100-500ms extra on first request
Function runs → Response → Function shuts down
You pay only for execution time

Webhook

A URL your app exposes so other services can notify you when something happens.

A webhook is the reverse of an API call. Instead of your app asking Stripe "did someone pay?" every 5 minutes, Stripe calls your app the moment a payment happens.

You give Stripe a URL (your webhook endpoint). When a payment succeeds, Stripe sends a POST request to that URL with the payment data. Your endpoint receives it, updates the database, grants access, sends an email — whatever needs to happen.

The challenge: Your webhook endpoint must be publicly accessible (not localhost). It must be fast — Stripe expects a 200 response within seconds. It must be idempotent — if Stripe sends the same event twice (it does), processing it twice shouldn't break things.

Why it matters: Stripe webhooks are the #1 source of confusion for vibe coders. "The payment went through but my user didn't get access" is almost always a broken webhook.

How it works

Without webhooks (polling):
Your App → Stripe: "Did anyone pay?" (every 5 min)
Stripe: "No." (repeated until yes)
Stripe: "Yes! Here's the data"
Delay: up to 5 minutes

With webhooks (event-driven):
Customer pays on Stripe
Stripe → Your App: POST /webhooks/stripe {event: "payment_succeeded", ...}
(milliseconds after payment)
Your App: grants access immediately

API (Application Programming Interface)

A set of rules for how two pieces of software talk to each other.

An API is a defined set of endpoints (URLs) that a service exposes so other software can talk to it. Supabase exposes an API so your frontend can read/write data. Stripe exposes an API so your backend can create payment sessions. GitHub exposes an API so you can read repo data.

A REST API is the most common type: you make HTTP requests (GET, POST, PUT, DELETE) to specific URLs, and get JSON back. GET /users returns a list of users. POST /users creates a new user.

The key insight: Every SaaS you use (Clerk, Supabase, Stripe, Resend) is just a database + API + dashboard. When you understand this, you realize you could build any of them yourself — the question is whether it's worth your time.

How it works

Your App → Supabase API: GET /rest/v1/users?select=name,email
Supabase: queries its PostgreSQL database
Supabase → Your App: [{name: "Vatsal", email: "..."}]

Your App → Stripe API: POST /v1/payment_intents {amount: 1000}
Stripe: creates payment intent in its system
Stripe → Your App: {id: "pi_xxx", client_secret: "..."}

Row Level Security (RLS)

Database rules that decide which rows each user can read or write.

RLS is a PostgreSQL feature that Supabase uses extensively. Instead of enforcing "who can see what" in your application code, you define rules at the database level. The database itself rejects queries that violate the rules, no matter how the request arrives.

Example policy: "Users can only read rows where user_id = their own ID." Without RLS: your application has to filter data in every query. With RLS: the database filters automatically, even if your query forgets to.

The common mistake: Enabling RLS and forgetting to create policies. Result: nobody can access anything. Or disabling RLS to "fix" errors without understanding why they appeared.

Why it matters for vibe coders: Supabase lets your frontend query the database directly (via their client library). Without RLS, any user can read any other user's data. With RLS, the database enforces privacy for you.

How it works

Without RLS:
Frontend → Supabase: SELECT * FROM orders
Supabase: returns ALL orders from ALL users ← security hole

With RLS policy: "user can only see their own orders"
Frontend → Supabase: SELECT * FROM orders (user_id=123 from JWT)
Supabase: applies RLS → filters to user 123's orders
Supabase → Frontend: only user 123's orders