What are frontend, backend, and an API?

What are frontend, backend, and an API?

The frontend is the part of an application a person sees and touches. The backend is the part that runs on the company's computers, out of sight. An API is the agreed list of requests the backend will answer, which is how the two halves work together.

Every app on a phone and every site in a browser splits this way. The split matters for hiring because it is also how engineering work divides. Most job descriptions name one half or the other, most developers spend years mostly on one side, and the daily work on each side looks different. A developer who describes their work as frontend is telling you which half of the machine they live in.

The word API is the one to hold onto. It appears in more engineering conversations than almost any other term, and this lesson is where it gets a real definition. Once the two halves are clear, the API falls out naturally as the seam between them.

What is the frontend?

The frontend is everything that runs on the user's own device: the screens, the buttons, the forms, the animations. When a page loads, when a menu opens, when an error message appears in red, that is frontend code doing its job.

Frontend code runs in two main places. On a phone, it runs inside the app installed from an app store. In a browser, it runs inside the page itself. A product that lives entirely in the browser is called a web app. Gmail is one, and so is almost every business tool a recruiter uses at work. A web app is a full product, with all the moving parts of one, delivered through a browser tab instead of an install.

Frontend work is judged on things a non-engineer can see. Does the page load fast on a cheap phone? Does the layout survive every screen size? Does clicking a button feel instant? Frontend developers build with frameworks made for this half of the job, and the most common ones, such as React, show up constantly on resumes for these roles. A later station in this path covers what each role looks like day to day.

What is the backend?

The backend is the part of the application that runs on the company's computers. Users never see it directly. It stores the data, applies the rules, and answers every request the frontend sends.

Think about what happens when someone logs into a work tool. The login screen is frontend. The check that the password is right happens on the backend, because the frontend cannot be trusted with that decision. The user's device is out in the world, in unknown hands, so anything that involves money, permissions, or other people's data gets decided on the company's side. The backend is where the product keeps its memory and enforces its rules.

That is why backend work is judged on qualities a user never sees: correctness, speed under load, and staying up when a million people arrive at once. It is also why the backend usually holds most of a product's codebase. An app that looks like six screens can sit on top of a backend many times its size, built by a team many times larger than the one that built the screens.

What is a server?

A server is a computer that runs all the time and answers requests from other computers. The name is literal: it serves. When an app loads your messages, your device sent a request across the internet, and a server answered it with the data.

A server has no screen and no keyboard, because no person sits at it. It is a machine built to do one thing without stopping: receive a request, do the work, send back the answer, millions of times a day. The backend of every product runs on servers, which is why "server-side" and "backend" mean the same thing in a job description.

Very few companies own these machines anymore. Most rent them from a handful of large providers, a shift the lesson on the cloud covers on its own. For now the useful fact is simpler. Every app on a phone is one half of a conversation, and somewhere a server is holding up the other half.

What is an API, and why is the word everywhere?

An API is an agreed list of requests one piece of software will answer for another. The backend publishes the list, the frontend sends requests from it, and neither side needs to know how the other is built inside. That agreement is the whole idea.

The letters stand for application programming interface, and the name is older than the web, which is why it explains so little. Skip the acronym and keep the picture: a menu of requests, agreed in advance. "Give me this user's messages." "Save this document." "Delete this record." Each request on the menu has its own address, called an endpoint, and each endpoint answers one kind of request. A real backend exposes dozens or hundreds of them.

The agreement is what makes teams fast. Once the frontend and backend teams settle the list, they can build their halves at the same time, in different programming languages, in different cities, and the halves will still fit. It is the same reason nobody writes all the code themselves: every library a developer pulls in is used through its API too. The word is everywhere because the boundary is everywhere. Any time two pieces of software cooperate, an API is the seam where they meet, and building, extending, and maintaining those seams is the most common work in backend engineering. That is why the word saturates job descriptions: it names the day job.

What is an integration?

An integration is a connection between two products so that data or actions flow between them. When a hiring tool pushes a candidate into an applicant tracking system, or a calendar tool books a meeting inside a video product, that is an integration.

Under the surface, every integration is one product calling another product's API. Companies publish public APIs for exactly this reason: a published menu of requests is an open invitation for other software to connect. A payments company publishes an API so any product can charge a card. A messaging company publishes one so any product can post to a channel. The company with the API gains reach, and the company building the integration ships a feature without building a payments system or a messaging system from scratch.

For hiring, this decodes a common line of work. A req that mentions "building integrations" is describing a developer who reads other companies' APIs, connects them to the home product, and handles what happens when the far side changes or fails. It is backend-flavored work with an unusual amount of reading, since every integration starts with another company's documentation. A candidate who has shipped several integrations has practice absorbing an unfamiliar system quickly, which is a skill that travels to every job after this one.