Glossary

The words, without the shrug

Every term the courses use, defined in one line and then in a paragraph. Written to be read out of order.

Clear

Showing 24 of 24 matching “Server”

Authorization

Backend

Deciding whether someone may do a thing.

Checking permission for a specific action on a specific record. Must be checked on the server, per request, per record. Being logged in is not permission to view record 41 just because you asked for it.

See also Authentication, IDOR

Bounce

Infrastructure

A message the receiving server refused.

A hard bounce means the address does not exist and never will; a soft bounce is temporary, such as a full mailbox. Sending again to a hard bounce is among the fastest ways to be judged a spammer, which is why providers keep a suppression list on your behalf.

See also Deliverability, Retry, Transactional email

Cache

Infrastructure

A kept copy of something expensive to produce.

A stored result reused instead of being recomputed or refetched. The most effective performance tool available and the source of the most confusing bugs, because a copy can be out of date. Copies live in the browser, the CDN, and your server.

See also CDN, Invalidation, TTL

Client

Frontend

The side making the request, usually a browser.

Whatever asks for something: a browser, a mobile app, another server. Crucially it runs on a machine the user controls, so nothing it claims can be trusted without verification.

See also Server, Validation

Cold start

Infrastructure

The delay when no instance is running yet.

When a serverless function has no live instance, one must be created before your code runs. That startup delay is the price of paying nothing while idle, and it lands on whichever unlucky visitor arrives first.

See also Serverless, Stateless

Endpoint

Backend

One address on a server that does one thing.

A path and a method together. The same path with a different verb is a different endpoint doing something different: GET /orders lists them, POST /orders creates one.

See also API, HTTP, Idempotency

HTTP

Frontend

The request-and-response protocol of the web.

The rules by which a client asks and a server answers. A request is a method, a path, headers, and maybe a body; a response swaps the method for a status code. Stateless by default.

See also Status code, Stateless, Endpoint

Idempotency

Infrastructure

Doing it twice has the same effect as doing it once.

A property that makes retrying safe. Usually achieved with a key the caller sends on every attempt; the server records processed keys and returns the original result instead of repeating the work. This is what prevents double charges.

See also Retry, At-least-once, Endpoint

JWT

Backend

A signed token that carries its own data.

A token containing information, cryptographically signed so it cannot be altered. Needs no server lookup, which scales well, but cannot be revoked before it expires, so it must be short-lived.

See also Session, Cookie, Token

localhost

Infrastructure

This machine, talking to itself.

The address a computer uses for itself. Reachable only from that machine, which is why your dev server is not visible to anyone else on the internet.

See also Port, Server

Port

Infrastructure

Which program on a machine you are talking to.

A number that lets one machine run many servers at once. The address finds the machine, the port finds the program: a web app on 3000, a database on 5432.

See also Server, localhost

Process

Infrastructure

A running program.

One instance of your code, executing. A server is a process that is listening; when it exits, the server is gone even though the machine is still on.

See also Server, Port

Rendering

Frontend

Turning content into pixels.

The browser converting HTML, CSS and JavaScript into a visible page. Server-side rendering does the first pass on the server so content exists in the HTML immediately rather than after scripts run.

See also HTML, DOM, Payload

Server

Backend

A program that is open for business.

A running program listening for requests and answering them. Not a piece of hardware: one machine can run several, and it stops being a server the moment the program exits. Your laptop runs one every time you start a dev command.

See also Client, Port, Process

Server function

Backend

A function you call from the client that runs on the server.

Written like a normal function, but the build replaces the body with a network call in the client bundle and the real implementation only ever exists on the server. You get a typed contract for free and the server code never ships to the browser.

See also RPC, Validation, Secret

Server state

Frontend

Data fetched from an API, held in the UI.

Not really your application’s state, but a cache of somebody else’s, which goes stale the moment anyone else changes it. Treating it as local state is what produces "I updated it but the list still shows the old value".

See also State, Cache

Serverless

Infrastructure

You ship a function; something else runs it.

The platform decides when to run your code, how many copies to run, and when to discard them. Costs nothing while idle, scales without thought, and gives you no persistent memory between requests.

See also Cold start, Stateless, Container

Session

Backend

The server-side record that you are logged in.

A stored record the server looks up on each request using an id from a cookie. Slower than a signed token because of the lookup, but logging out is instant and reliable.

See also Cookie, JWT, Authentication

State

Frontend

Data that can change.

The real question is never what the state is but where the authoritative copy lives: the server, the URL, component memory, or browser storage. Two copies of the same fact will eventually disagree.

See also Server state, Search params

Stateless

Backend

Each request starts from nothing.

The server remembers nothing about you between requests by default. Memory has to be added deliberately, which is exactly what cookies and sessions are for.

See also HTTP, Session, Serverless

Timeout

Infrastructure

A hard limit on how long something may take.

Enforced by browsers, proxies, and serverless platforms. Work that exceeds one is killed partway through, leaving whatever it was doing half-finished.

See also Background job, Retry

TLS

Frontend

The encryption behind the S in HTTPS.

Makes the connection private and tamper-proof. Without it, anything between the user and your server can read and modify the page. Costs an extra handshake on the first connection.

See also DNS, Latency

UTC

Infrastructure

The timezone servers actually run in.

Coordinated Universal Time, with no daylight saving. Servers use it so that timestamps are unambiguous. It is also why a job scheduled for "8am" may not run at 8am where your users are.

See also Cron, Scheduled job

Validation

Backend

Checking that input is what you expected.

In the browser it is a courtesy that makes things pleasant. On the server it is a control, because requests do not have to come from your form. You need both, ideally from one shared schema so they cannot disagree.

See also Server function, Search params, Client