Backend and APIs

Node.js takes V8, the JavaScript engine from Chrome, and adds what a server needs: files, networking, processes and timers. It handles many connections on one thread with an event loop: while one request waits for the database, Node serves others instead of sitting idle. That suits work that mostly waits on networks and disks, such as APIs, realtime apps and proxies.

It comes with npm, a registry of millions of open-source packages, and almost every JavaScript tool (Next.js, Vite, ESLint) runs on it. Recent versions include a test runner, fetch, a watch mode and the ability to run TypeScript files by stripping out the types. Heavy CPU work, such as resizing large images, blocks the event loop, so it belongs in worker threads or a separate service. Production servers usually run a long-term support (LTS) release.

Ryan Dahl started Deno in 2018 to fix what he regretted about Node.js. Like Node it runs on the V8 engine, but its core is written in Rust and it runs TypeScript directly. A script cannot read files, open network connections or see environment variables unless you allow it with flags such as --allow-net, which limits the damage a compromised package can do.

Deno 2 made it largely compatible with Node.js and npm packages, so most existing libraries now work. It prefers web-standard APIs (fetch, Request, Response), can compile a program into a single executable, and has its own package registry, JSR. Deno Deploy hosts Deno code on a global network, and Supabase Edge Functions and Netlify Edge Functions both run on Deno.

Bun is written in Zig and runs on JavaScriptCore, the engine from Safari, rather than V8. It runs TypeScript and JSX directly, starts quickly and replaces several tools at once: bun install for packages (much faster than npm), bun test for tests and bun build for bundling. It implements most Node.js APIs, so many Node apps and frameworks run on it unchanged.

It also has built-in extras that would be separate packages elsewhere: an HTTP server (Bun.serve), a SQLite driver, PostgreSQL and S3 clients, and password hashing. Anthropic acquired Bun in late 2025, and it remains open source under the MIT licence. Compatibility with Node is high but not complete, so test an app's dependencies before moving production traffic.

An Express app is a list of routes (app.get('/orders', handler)) and middleware functions that run in order for each request: parse the body, check the session, log, then answer. It deliberately does little else, so templates, validation, database access and authentication all come from separate packages.

Released in 2010, it is the framework most Node tutorials, courses and older codebases use, and thousands of middleware packages target it. Express 5, the first major release in a decade, arrived in 2024 and passes errors from async handlers to the error handler automatically. In benchmarks it is slower than Fastify or Hono, which rarely matters for a typical app.

Fastify routes accept a JSON Schema for the body, query string and response. Fastify compiles those schemas into fast validation and serialisation functions, so bad input is rejected before a handler runs and responses skip slow generic JSON conversion. With a type provider such as TypeBox, the same schema also gives the handler its TypeScript types.

Everything is a plugin (database connections, auth, groups of routes), and plugins are encapsulated so one part of an app cannot accidentally change another. Logging through Pino is built in. It is an OpenJS Foundation project, and in benchmarks it handles noticeably more requests per second than Express on the same machine.

Hono (Japanese for 'flame') uses the standard Request and Response objects that browsers, Deno, Bun and edge platforms share, instead of Node's own types. That lets one app deploy to Cloudflare Workers, Deno, Bun, AWS Lambda, Vercel or Node.js with a small adapter at most. The core has no dependencies, and its smallest preset is under 14 KB.

It ships middleware for common jobs (CORS, JWT checks, logging, caching, secure headers) and a validator that works with Zod. In RPC mode a typed client (hc) reads the server's route types, giving tRPC-style end-to-end type safety over plain HTTP. Its API feels familiar to anyone who has used Express.

In FastAPI an endpoint is a Python function whose parameters carry type hints or Pydantic models. FastAPI reads those hints to parse and validate the request, convert types, return clear errors and produce an OpenAPI description, which appears as interactive docs at /docs. Shared pieces such as a database session or the current user are injected with Depends.

It is built on Starlette (an ASGI toolkit) and Pydantic, supports async endpoints, and runs on an ASGI server such as Uvicorn. It has become a common way to put a Python machine-learning model or AI pipeline behind an HTTP API. It has no ORM, admin panel or templates of its own; SQLAlchemy or SQLModel usually fill the database gap.

Django gives a project a standard layout and most of what a web app needs: an ORM with migrations, a generated admin site for managing data, user accounts and permissions, forms, templates, caching, and built-in defences against CSRF, XSS and SQL injection. The admin site alone saves weeks on internal tools and back-office screens.

It first appeared in 2005 at a newspaper and is looked after by the non-profit Django Software Foundation. For JSON APIs most projects add Django REST Framework or Django Ninja. Django runs on WSGI or ASGI servers and supports async views, although much of its ecosystem is still synchronous. Its conventions make projects predictable, at the cost of more weight than a micro-framework.

A Flask app can be a single file: create the app, decorate functions with @app.route and return a response. It is built on Werkzeug (the request and routing layer) and Jinja (templates), and extensions add the rest, such as Flask-SQLAlchemy for databases, Flask-Login for sessions and Flask-WTF for forms.

Armin Ronacher released it in 2010, and the Pallets project maintains it. It is a WSGI framework: async views exist, but it lacks the async-first design of FastAPI. It remains a common choice for small services, internal tools, webhook receivers and teaching, where a tiny core that is easy to read matters more than built-in features.

Laravel covers most of what a web app needs in one coherent package: routing, the Eloquent ORM and migrations, Blade templates, validation, queues, a task scheduler, events, mail and notifications, file storage and testing helpers. The Artisan command line generates code and runs jobs, and starter kits add sign-in screens built with React, Vue or Livewire.

Taylor Otwell released it in 2011, and a paid ecosystem has grown around it: Laravel Cloud and Forge for hosting and servers, Nova for admin panels. Because PHP runs on nearly every host, Laravel apps are cheap to deploy. The trade-offs are a lot of framework to learn and PHP as the language, which some JavaScript-first teams would rather avoid.

Spring is a long-standing Java framework for dependency injection, web APIs, data access and security. Spring Boot sits on top: add a 'starter' dependency and it configures the matching pieces automatically, embeds a web server such as Tomcat, and packages the service as one runnable file. Actuator adds health checks and metrics for production.

It is common in enterprise, banking and government backends, and pairs with Spring Data (databases), Spring Security (sign-in and permissions) and Spring Cloud (microservices). Kotlin is fully supported. The JVM uses more memory and starts more slowly than Go or Node.js, although GraalVM native images narrow that gap for containers and serverless.

Ktor lets a Kotlin developer write a server as a few lines of routing code and add features (authentication, JSON serialisation, WebSockets, CORS) as plugins only when needed. It is asynchronous throughout thanks to coroutines, and runs on engines such as Netty or its own CIO engine.

The same project provides the Ktor client, a multiplatform HTTP client that Kotlin Multiplatform apps use on Android, iOS, desktop and the web. Compared with Spring Boot it is smaller and more explicit, with fewer built-in integrations.

A Python framework does not listen on a network port by itself. A server such as Uvicorn accepts HTTP and WebSocket connections and hands each request to the app through ASGI (Asynchronous Server Gateway Interface), the async successor to WSGI, which Flask and classic Django use. Any ASGI app runs on any ASGI server, so Hypercorn, Daphne or Granian can stand in for Uvicorn.

Installed with its standard extras, Uvicorn uses uvloop and httptools for speed. In production it usually runs several worker processes, through its own --workers option or under Gunicorn, behind a reverse proxy such as Nginx.

You describe data as a class with typed fields (name: str, age: int), and Pydantic validates incoming data against it: it converts '42' to 42 where that is safe and raises clear errors where it is not. Models can also produce JSON Schema and serialise back to JSON.

FastAPI is built on it, as are many AI libraries that need structured output, including the official OpenAI and Anthropic Python SDKs. Version 2 moved the core into Rust (pydantic-core), which made validation much faster. pydantic-settings loads configuration from environment variables the same way.

In a REST API, resources live at URLs (/orders, /orders/42) and HTTP methods say what to do: GET reads, POST creates, PUT or PATCH updates, DELETE removes. Status codes report the result (200 OK, 404 Not Found) and bodies are usually JSON. Each request carries everything the server needs, such as a token, so any server in a group can answer it.

Roy Fielding described REST in 2000, and it became the default because it needs nothing beyond HTTP: browsers, phones, scripts and other servers can all call it, and CDNs can cache its responses. An OpenAPI document describes the endpoints and can generate docs and typed clients. The weak spot is fit: one screen may need several calls, or receive far more data than it uses.

A GraphQL server publishes a typed schema of everything it offers: users, orders, their fields and how they link. A client sends a query naming just the fields it wants, even across related records (a user with their last three orders), and receives exactly that in one round trip. Mutations change data and subscriptions push live updates.

Facebook built it in 2012 for its mobile apps and released it in 2015; the GraphQL Foundation now looks after the specification. Common tools include Apollo, GraphQL Yoga and Relay, while Hasura, PostGraphile and Supabase's pg_graphql generate an API from a database. The flexibility has costs: caching is harder than with REST, and servers must guard against slow nested queries and the N+1 problem.

With tRPC you write procedures on the server (queries, mutations and subscriptions), usually checking their input with Zod, and group them into a router. The client imports only the router's type, so every call from the browser is checked by the TypeScript compiler: rename a field on the server and the frontend stops compiling until it is fixed.

Under the hood it sends ordinary HTTP requests with JSON and can batch several calls into one. Adapters connect it to Next.js, Express, Fastify and serverless platforms, and it pairs with TanStack Query for caching on the client. It only works when both ends are TypeScript in the same codebase or monorepo, so it does not suit public APIs or apps written in other languages.

You describe services and messages in a .proto file, and gRPC's tools generate client and server code in many languages (Go, Java, Kotlin, Python, C#, Node.js and more). Calls travel over HTTP/2 as Protocol Buffers, a binary format that is smaller and quicker to parse than JSON. Besides simple request and response, it supports streaming in either direction or both at once.

Google created it from its internal RPC system and open-sourced it in 2015; it is now a Cloud Native Computing Foundation project. It is common between microservices and in some mobile and device clients. Browsers cannot speak it directly, so web apps need gRPC-Web or the Connect protocol through a proxy, and binary traffic is harder to inspect than JSON.

A WebSocket starts as an ordinary HTTP request that asks to 'upgrade', then becomes a two-way channel over the same connection (ws://, or wss:// when encrypted). Either side can push small messages with very little overhead, so the client no longer has to keep asking whether anything has changed. The protocol was standardised in 2011 and every modern browser supports it.

Libraries such as ws and Socket.IO (which adds rooms and automatic reconnection) run it on Node.js, and services such as Supabase Realtime, Pusher and Ably host it for you. Open connections are the hard part: a server must keep thousands of them alive, reconnect dropped clients and share messages across machines, and many serverless platforms cannot hold connections open at all.

The browser opens a connection with the EventSource API, and the server keeps the response open, writing short text messages (content type text/event-stream) whenever something happens. If the connection drops, the browser reconnects on its own and can tell the server the last event it received. Data flows one way only; the browser still sends anything of its own with normal requests.

Because it is plain HTTP, SSE passes through most proxies, CDNs and load balancers and needs no special server. The OpenAI, Anthropic and Gemini APIs stream model output this way. Over HTTP/1.1 a browser allows only about six open connections per site across all tabs, a limit HTTP/2 removes, and messages are text only.

A web page asks for the camera and microphone (getUserMedia) and opens an RTCPeerConnection to the other person. Media travels as encrypted SRTP, usually straight from peer to peer over UDP, with Opus for audio and VP8, VP9, H.264 or AV1 for video. Data channels carry chat messages, files or game state over the same connection.

WebRTC deliberately leaves signalling to you: before connecting, the two sides must swap connection details (SDP offers and answers) through your own server, usually over WebSockets. To get past home routers and firewalls it uses ICE, which tries direct routes discovered with STUN servers and falls back to TURN servers that relay the media. A share of calls always needs a relay, so production apps budget for TURN.

Peer to peer suits one-to-one calls. Group calls usually go through an SFU (selective forwarding unit), a server that receives each person's stream once and forwards it to everyone else; LiveKit, Janus, mediasoup and Cloudflare Realtime provide one. Google Meet and Discord both run on WebRTC.

You give a service (Stripe, Razorpay, GitHub, a form tool) a URL on your server. When an event occurs, it sends an HTTP POST to that URL with the details as JSON, and your endpoint updates the order, sends the email or starts the build. Payments depend on them: the webhook, not the browser's redirect, is the reliable signal that money arrived.

Because the URL is public, anyone could post to it, so senders sign each request (usually an HMAC with a shared secret) and your code must check that signature. Senders retry when an endpoint fails or is slow, so the same event can arrive twice: reply with a 2xx status quickly, hand slow work to a queue and make handlers idempotent. The Stripe CLI and tunnelling tools forward webhooks to a laptop for testing.

A cron schedule has five fields: minute, hour, day of month, month and day of week. So '0 2 * * *' means 2 a.m. every day and '*/15 * * * *' means every fifteen minutes. On a server, the cron program reads these lines from a crontab file and runs each command at the matching times.

Serverless apps have no always-on machine, so hosts offer their own versions: Vercel Cron Jobs, Cloudflare Cron Triggers, GitHub Actions schedules, pg_cron inside PostgreSQL and QStash schedules. Most run in UTC, may start a little late and can overlap a previous run that has not finished, so jobs should be safe to run twice.

Instead of doing everything inside the request, the app adds a job to a queue ('send the receipt for order 42') and responds at once. Worker processes take jobs off the queue and run them, retrying with growing delays when something fails and moving jobs that keep failing to a dead-letter queue for someone to inspect.

Common tools include BullMQ (Node.js on Redis), Celery (Python), Laravel's queues, Amazon SQS, RabbitMQ and Cloudflare Queues, plus HTTP-based services such as QStash, Inngest and Trigger.dev that suit serverless apps. Most deliver each job at least once, so a job can occasionally run twice and its handler should be idempotent.

A rate limiter counts requests per key (a user id, an API key, an IP address) in a time window and rejects the excess with HTTP 429 Too Many Requests, often with a Retry-After header. Common algorithms are fixed windows, sliding windows and the token bucket, which allows short bursts while holding the long-run average.

Counters usually live in a fast shared store such as Redis, so every server sees the same numbers; Upstash offers a ready-made library for serverless apps, and Cloudflare and API gateways can enforce limits before traffic reaches the app. Sign-in, OTP and password-reset endpoints, and anything that calls a paid AI model, need limits most.

A web framework passes each request through a chain of middleware functions. Each one can read or change the request, stop it (for example with a 401 when there is no valid session) or pass it on to the next with a call such as next(). Order matters: the body must be parsed before it is validated, and the user checked before any route that needs one.

Express, Hono, Django, Laravel and ASP.NET all work this way, and Fastify offers the same idea as hooks. Next.js has a similar layer that runs before a page is served, renamed proxy in Next.js 16. The word also has an older, broader meaning: any software that sits between systems, such as a message broker.