GUIDE · FULL STACK CONCEPTS
15 Fullstack Concepts Every Frontend Developer Should Know
Most frontend developers stop at the framework. Senior interviews don't. They ask what happens between the browser and the server: HTTP, DNS, TLS, caching, and the architecture behind the API you call.
This guide covers 15 concepts, from TCP packets to API gateways and backends for frontend. Each one shows up in real interviews and real production systems. No framework required.
THE CONCEPTS
The mental models, one by one
- 01
HTTP: How Browsers Talk to Servers
HTTP is the protocol browsers use to communicate with servers. The browser sends a request — a GET for the page — and the server answers with a response. That response travels as small TCP packets the client reassembles. TCP costs some header space but guarantees no packet loss and in-order delivery, with retry mechanisms built in.
An HTTP response is just text. First line: the status, like 200 OK. Then the headers — data about the data: the server it came from, the content length, the content-type (text/html). Then an empty line, then the body. The browser renders HTML chunks as they arrive.
Think of it as sending letters. The envelope carries the metadata (the headers). The letter inside is the data.
HTTPTCPHeadersStatus Codes - 02
DNS: Matching Domains to IP Addresses
DNS is a global system that matches a domain name to an IP address. Humans don't memorize IPs. So before any request — typing a URL, making a fetch — the browser does a DNS lookup: what is the IP of this domain? The nearest DNS server answers from its tables.
You can verify this on any site. Open the network tab, check the first request, and look at Remote Address in the headers: the real IP plus the HTTPS port. Everything on the internet ends at an IP address.
Who maintains it? Run `whois` on a domain. Registrars like GoDaddy sell domains, they get the space from VeriSign, and IANA coordinates the whole system. The internet has no central owner, but DNS needs global coordination — that's IANA's job.
DNSIP Addresswhois - 03
IP: The Internet Protocol
The internet protocol lets machines find each other on a network. A packet is a sequence of bytes with an IP header carrying a source address and a destination address. Network components read the header and route the packet along. That's it.
The internet is thousands of networks connected to each other, running on fiber optic cables — underground and underwater between continents. Information moves through them at the speed of light.
IPv4 addresses are the real estate of the internet: scarce and expensive. Companies that claimed address space early own it now — Apple's addresses start with 17. IPv6 fixes the shortage with longer addresses, but legacy network hardware means the rollout is still ongoing.
IPIPv4IPv6Routing - 04
HTTP Caching: Stop Re-Downloading Files
Caching means reusing a file — JavaScript, CSS — for a defined time instead of downloading it again over the network. The browser cache is a private cache sitting between you and the server. A cached asset shows up in the network tab as 200 OK from memory cache.
Three headers run the system. max-age inside Cache-Control is the time-to-live. Age is how long the asset has been cached — it must stay below max-age. When it expires, the browser sends the ETag, a unique identifier based on the file's content, and asks the server: is this still the latest version?
If yes, the TTL resets and the file is reused. If no, the cache is invalidated and the browser downloads the new version.
Cache-ControlETagTTL - 05
TLS Encryption: Why HTTPS Exists
TLS exists to stop man-in-the-middle attacks: someone on a public Wi-Fi intercepting your traffic with Kali Linux and reading your headers, passwords, and card data. HTTPS — introduced by Netscape in 1996 — encrypts the conversation so only the server can decrypt it.
The handshake uses asymmetric encryption. The browser fetches the server's certificate (the public key), verifies it with a certificate authority, generates a secret key, encrypts it with the certificate, and sends it over. Only the server's private key can decode it.
Then both sides switch to symmetric encryption with that shared secret. Why switch? Asymmetric is slow and computationally expensive, but it's the only way to start with a stranger. Symmetric is fast but needs a secret both sides know. The handshake round trips are also why HTTPS is slightly slower than HTTP.
TLSHTTPSEncryptionCertificates - 06
Polling: The Simplest Real-Time Update
Polling is the client actively sampling a status: call an endpoint every few seconds until something changes. The classic case is payment status — keep asking until pending becomes completed, then stop.
The implementation is basic JavaScript: a fetch call inside setInterval, and clearInterval once you get the answer you wanted. The user never refreshes the page. That's the whole point — the browser does the retrying in the background.
PollingfetchsetInterval - 07
WebSockets: A Phone Call, Not Letters
If HTTP is exchanging letters, WebSockets are a phone call. You open a communication channel once and both sides push messages through it, without formalizing every single message. This is what enabled modern chat applications and social media.
The APIs are native. The browser creates a WebSocket and listens; a Node.js server accepts the connection and sends messages back. User B sends a message, it goes through the server, and user A gets it instantly — no request needed. At Facebook scale it gets more complex, but the idea stays the same.
WebSocketsReal-TimeNode.js - 08
Server-Sent Events: How AI Apps Stream Tokens
Server-sent events power modern AI applications. You make one request — the conversation — and subscribe to it. The server then pushes events to you: token after token, which fits exactly how LLMs generate output.
Open the network tab on ChatGPT and find the conversation request. The EventStream tab shows every event the server sends — that's the answer you watch appear word by word. AI apps look complex, but under the hood they sit on low-level browser APIs that have been there forever.
SSEEventStreamLLMs - 09
RPC and tRPC: Calling Functions on Another Machine
RPC — remote procedure call — is one computer causing the execution of a function on another and getting the result. The idea is older than the internet. tRPC revived it with TypeScript: the client calls a mutation, the server runs the matching function, and the whole exchange is typed end to end.
Why isn't it everywhere? Coupling. Client code calls straight into server functions, the server has to know the client, and you end up with spaghetti. REST APIs still dominate — that's the one to learn first.
RPCtRPCTypeScript - 10
MCP: The Protocol Behind AI Agents
MCP — the model context protocol — is the open standard for connecting AI applications to external systems. When a bot books a meeting in your calendar, that's a remote procedure call: the model picks the function, calls it through MCP, waits for the answer, and continues the task.
MCP servers describe their functions as text so the model understands what each one does. Under the hood it runs on JSON-RPC, which is lighter than tRPC. The spec is very recent — and it's how all the agent tooling actually works.
MCPJSON-RPCAI Agents - 11
REST APIs: Order in the HTTP Chaos
REST is an API architecture style that treats entities as separate resources with a uniform, standardized interface. Without it, every API is freestyle and every consumer reinvents the wheel. Pay attention here — this one is very common in senior frontend interviews.
The core is the URI: the resource name in plural. GET /products lists products. Query parameters handle pagination and search. Nested routes like /products/:id/prices model relationships. A well-implemented REST API is predictable without reading the documentation.
REST standardizes CRUD over HTTP: POST creates, GET reads, PUT or PATCH updates, DELETE deletes. PUT replaces the whole object and is idempotent; PATCH applies a change and is not.
RESTCRUDURIHTTP Methods - 12
GraphQL: Fixing Underfetching and Overfetching
Desktop views need dozens of requests to load one screen — that's underfetching. Mobile reuses desktop endpoints and downloads fields it never shows — that's overfetching, on poor connections and limited data plans. A Facebook team built GraphQL in 2013 to fix both.
GraphQL is a data layer where you query multiple resources in a single query and specify exactly the fields you need. Dozens of REST requests become one query. Desktop and mobile shape their own data without backend changes. And it's typed, so the frontend gets type safety without extra tooling.
The catch is the N+1 problem: fetching 24 products triggers 25 SQL queries and bombards your database — worse performance than REST. Solve it with DataLoader, which batches the IDs into a single compound query. It's the first problem you fix on any GraphQL server.
GraphQLN+1 ProblemDataLoader - 13
API Gateway: One Front Door for All Microservices
An API gateway is a reverse proxy that unifies repetitive functions — authentication, rate limiting, caching, SSL — in one place instead of inside every microservice. A proxy (like a VPN) acts on behalf of the client; a reverse proxy acts on behalf of the server.
The gateway terminates the TLS handshake once, applies the edge functions, and forwards the request to the right microservice. Inside the private cloud, services can talk plain HTTP: no man-in-the-middle exposure, no handshake round trips, so it's faster. You also buy one certificate instead of one per service.
You can buy a gateway with one click (Amazon API Gateway) or build your own: an NGINX instance in a Docker container forwarding traffic to the services behind it.
API GatewayReverse ProxyNGINXEdge Functions - 14
Backend for Frontend: The Frontend Team's Own API
In a real company, the platform team owns the API gateway and separate backend teams own each microservice — each with its own backlog and product manager. Shipping one frontend feature means coordinating with all of them. With 300 microservices, that takes forever.
The BFF — backend for frontend — is another reverse proxy, but built for one specific client and owned by that client's team. It usually exposes a GraphQL data layer tailored to that frontend. Web gets its BFF; the mobile team builds its own, shaped to mobile's needs.
This is why frontend engineers are expected to know full stack: you extend the BFF yourself — write resolvers, extend schema types — and ship without waiting on other teams. It makes the architecture scale in people, not just machines.
BFFGraphQLMicroservices - 15
Load Balancing: Removing the Single Point of Failure
The API gateway takes all the traffic, which makes it a single point of failure. If it goes down, the whole system goes down. Load balancing fixes that: distribute traffic across identical instances based on an algorithm, so one instance dying doesn't kill the system.
The most common algorithm is round-robin — rotate through the instances in order. Least connections sends traffic to the instance with the fewest open connections, adapting distribution to instance performance. Together with the load balancer, the group also handles more traffic than any single instance could.
Load BalancerRound-RobinHigh Availability
Free Senior Training.
One session, the whole system: the fundamentals, the interview strategy, and the plan to the offer. Watch it free.
MORE GUIDES
