Web Developer Dictionary

A hash table is a data structure providing O(1) average-case access by key. A key is passed through a hash function; the result points to a "bucket" storing the value. Associative arrays in PHP and dicts in Python are hash tables.CollisionsDifferent keys can produce the same hash — a collision. Resolved two ways:Chaining — each bucket holds a list of elements with the same hashOpen addressing — on collision, probe for the next free bucketLoad factorThe ratio of elements to buckets. When a threshold is exceeded (usually 0.75), rehashing occurs (table grows, elements redistributed). Expensive, but rare.Vs search treeHash table: O(1) access, but no ordering. BST: O(log n) access, but elements are sorted. Choose based on whether sorted order matters.

Hashing is a one-way transformation of data into a fixed-length string (a hash). "One-way" means: recovering the original from the hash is mathematically infeasible. Passwords in a database are stored exclusively as hashes, never in plain text.Algorithms for passwordsbcrypt — a built-in cost factor slows down brute-force attacks. The de facto standardArgon2id — winner of the 2015 Password Hashing Competition. More resistant to GPU attacksPBKDF2 — widely supported, especially in enterprise environmentsHashing ≠ EncryptionEncryption is reversible — encrypted data can be decrypted with a key. Hashing is one-way — recovery is impossible. Passwords need hashing; data that must be readable (e.g. an API key) needs encryption.SaltA random string added to a password before hashing. Protects against rainbow table attacks: identical passwords for two users produce different hashes. bcrypt and Argon2 include a salt automatically.

A headless CMS is a content management system without a built-in frontend ("head"). Content is stored and edited in the CMS, but delivered via API (REST or GraphQL), while the presentation layer is fully controlled by the developer. Headless vs Traditional CMS Traditional (WordPress, Drupal) — the CMS renders HTML. Frontend and backend are tightly coupled Headless — the CMS only manages content and exposes an API. The frontend can be anything: React, Vue, mobile, digital signage Benefits One content source → multiple channels (web, mobile, IoT) Freedom to choose frontend technologies Better performance — static frontend + CDN Popular Headless CMS options SaaS: Contentful, Sanity, Strapi (self-hosted), Directus (self-hosted), Prismic. Git-based: Netlify CMS, Tina CMS — content in a Git repository.

A health check is an endpoint or mechanism that lets an external system (load balancer, orchestrator) verify whether a service is ready to handle requests. If a service is "unhealthy", it is removed from rotation.TypesLiveness — is the process alive? If not — restart it. Simple: GET /up → 200 OKReadiness — is it ready to accept traffic? Checks DB, Redis, and dependency connections. If not — remove from the load balancer, but do not restartStartup probe — extra time during startup (long bootstrap)What to check in readinessDB connection (ping)Redis connectionCritical external servicesSufficient free memory and disk spaceResponse formatGET /health → 200 {"status":"ok","db":"ok","redis":"ok"} → 503 {"status":"degraded","db":"error"}

Stack and Heap are two memory regions used by programs in different ways. Understanding them helps diagnose memory leaks and stack overflows. Stack (call stack) Automatically managed memory for local variables and call frames. When a function is called, its data is pushed onto the stack. On return — it is popped. Stack overflow = recursion too deep, stack exhausted. Heap Dynamic memory for objects with an indefinite lifetime. Allocated on new Object(), freed by the garbage collector. Memory leak = objects are not freed because "stray" references to them exist. In PHP Scalars (int, string, bool) — typically on the stack Objects and arrays — on the heap, managed by reference counting memory_get_usage() — current consumption memory_limit in php.ini — maximum for a single process

Hexagonal Architecture (Ports & Adapters, Alistair Cockburn) — domain logic at the centre, isolated from the outside world through ports (interfaces) and adapters (implementations). HTTP, queues, databases, CLI — all external and interchangeable. Ports and adapters Port — an interface describing interaction with the domain. E.g.: UserRepository, PaymentGateway Primary adapter — initiates an action (HTTP controller, CLI command, queue consumer) Secondary adapter — implements a port (MySQL repository, Stripe gateway, SendGrid mailer) Why "hexagon" The hexagon in the name is not a technical fact but a symbol: the domain has several sides (ports) for external interaction. The number is not fixed. Related concepts Clean Architecture, Onion Architecture — different names for the same idea: business logic does not depend on infrastructure. The difference is in layering details.

HTTP caching lets browsers and proxies store responses and avoid round-tripping to the server. Controlled by the Cache-Control header and related headers. Proper caching is the fastest optimisation: the best request is one never sent. Key Cache-Control directives max-age=3600 — cache for N seconds no-cache — always revalidate with the server (but may use cached response on 304 Not Modified) no-store — do not cache at all (sensitive data) public — may be cached by proxies and CDNs private — browser only (personalised data) immutable — content will never change; browser skips revalidation until max-age expires ETag and Last-Modified ETag is a content hash. On the next request the browser sends If-None-Match. The server returns 304 Not Modified if the content has not changed — no response body. Saves bandwidth. Strategy for static assets Static files with a hash in the filename (app.abc123.js) → Cache-Control: public, max-age=31536000, immutable. Infinite cache; a new deploy means a new hash = a new URL.

HTTP methods define the type of operation on a resource. REST APIs use them semantically: the method expresses the intent of the request, not just how data is transferred. Core methods GET — retrieve a resource. Idempotent, safe, cacheable POST — create a resource or perform an action. Not idempotent PUT — fully replace a resource. Idempotent PATCH — partially update a resource. Usually not idempotent DELETE — remove a resource. Idempotent HEAD — like GET but no response body. For checking existence/metadata OPTIONS — returns allowed methods. Used in CORS preflight Safe vs Idempotent Safe — does not change server state (GET, HEAD, OPTIONS) Idempotent — repeated calls yield the same result (GET, PUT, DELETE) POST — neither safe nor idempotent

An HTTP status code is a three-digit number in the server response describing the result of the request. The first digit defines the class: 2xx — success, 3xx — redirection, 4xx — client error, 5xx — server error.Most important codes200 OK — successful request201 Created — resource created (after POST)204 No Content — success, no response body (DELETE)301 Moved Permanently — permanent redirect304 Not Modified — cached version is current400 Bad Request — malformed data from client401 Unauthorized — not authenticated403 Forbidden — authenticated, but no permission404 Not Found — resource does not exist422 Unprocessable Entity — validation failed429 Too Many Requests — rate limit exceeded500 Internal Server Error — server-side error503 Service Unavailable — server temporarily unavailable

HTTP/2 is the second major version of the HTTP protocol, adopted in 2015. It solves the key problems of HTTP/1.1: head-of-line blocking and the overhead of opening new connections.Key improvementsMultiplexing — multiple requests and responses simultaneously over a single TCP connection. The end of the browser's "6 parallel connections" limitServer Push — the server can send a resource before the client has requested itHeader Compression (HPACK) — headers are compressed and repeated only when changedBinary protocol — replaces the text-based format; more efficient to parseHTTP/3The next step — HTTP/3 over QUIC (UDP instead of TCP). Solves head-of-line blocking at the transport layer. Supported by browsers and CDNs, but requires specific server configuration.

HTTP/3 is the third major version of HTTP, using QUIC (over UDP) instead of TCP. It solves the fundamental HTTP/2 problem: head-of-line blocking at the transport layer. Supported by most browsers and CDNs. Why QUIC instead of TCP HTTP/2 multiplexes requests over a single TCP connection. But TCP guarantees order: losing one packet blocks all subsequent ones. QUIC — over UDP — isolates streams: a lost packet blocks only one stream; the rest continue. HTTP/3 benefits 0-RTT connection — reconnecting to a known server without an extra handshake Built-in TLS 1.3 — encryption is part of the protocol, not a separate layer Better on mobile — QUIC handles IP changes correctly (roaming) Support Cloudflare, Google, Facebook, Chrome, Firefox — all support HTTP/3. Nginx requires quiche or a custom build. For most applications — transparent through a CDN.

HTTPS is HTTP over TLS encryption. It protects data from interception (man-in-the-middle attacks) and confirms you are communicating with the real server, not an impostor. Without HTTPS, browsers mark a site as "not secure" and SEO rankings suffer.How TLS works (simplified)The server sends a TLS certificate (signed by a trusted CA)The client verifies the signature and generates a symmetric session keyAll subsequent communication is encrypted with that keyCertificatesLet's Encrypt — free certificates with automatic renewal via CertbotDV / OV / EV — validation levels: domain only, organisation, or extended verificationHTTP Strict Transport SecurityThe Strict-Transport-Security header prevents the browser from ever accessing the site over plain HTTP — even if the user types http:// manually.