Frontend, backend, and full-stack

Module 4 introduced the conversation between a client and a server. The client sends a request, and the server returns a response.

Now we can examine the major parts of the application on each side of that conversation.

Software teams commonly divide applications into the frontend and the backend, and this distinction helps organize code, system responsibilities, engineering roles, and discussions about where work should happen.

What is the frontend?

The frontendConcept · lights on your mapfrontendThe part of an application users directly see and interact with: screens, buttons, forms, and the code responding to clicks and typing. Runs in the browser, mobile app, or desktop app. is the part of an application that users directly see and interact with.

In a web application, the frontend runs primarily inside the browser, and in a mobile application it runs through the app installed on the phone. Desktop applications also have frontends that run on the user’s computer.

The frontend may include:

• Screens and pages
• Buttons and menus
• Forms
• Text, images, and icons
• Animations
• Error messages
• Code that responds to clicks, taps, and typing
• Information displayed to the user

When you tap Add to Cart, the frontend detects the action and may update the cart icon immediately.

When you fill out a form, the frontend may check whether required fields are empty before sending anything to the server.

The frontend is responsible for much of how the product looks, responds, and feels to use.

What is the backend?

The backendConcept · lights on your mapbackendThe part of the application operating behind the user-facing interface, usually on remote servers or cloud infrastructure: business logic, authentication, permissions, stored data, payments, and the responses the frontend depends on. is the part of the application that operates behind the user-facing interface.

It commonly runs on remote servers or cloud infrastructure rather than directly inside the user’s browser or mobile application.

The backend may be responsible for:

• Applying business logic
• Authenticating users
• Checking permissions
• Reading and changing stored data
• Processing payments
• Communicating with other services
• Sending notifications
• Preparing responses for the frontend

Suppose a customer places a coffee order. The frontend collects the customer’s choices and sends them in a request.

The backend may then check whether the café is open, confirm that the drink is available, calculate the official price, process the payment, save the order, and return a confirmation.

The frontend presents the experience, while the backend performs much of the work behind it.

How the frontend and backend communicate

The frontend and backend commonly communicate through requests and responses.

The frontend might send “Create an order for one large latte”, and the backend processes the request and returns something like “Order 1042 was created successfully” in reply.

In a real application, this information might be exchanged through HTTP and written as JSON, using the request structure you learned in Module 4.

The simplified relationship is: frontend → request → backend → response → frontend

The frontend uses the response to update what the user sees, perhaps displaying an order-confirmation screen, showing an error message, or updating the cart.

Client-side and server-side

You will also hear engineers use the terms client-side and server-side.

Client-sideConcept · lights on your mapclient-sideWork performed on the user’s device, usually in a browser. Fast to react, but the user controls that machine, which is why nothing important can be trusted here. Its counterpart is server-side. means that work happens on the user’s device, usually inside a browser or installed application.

Server-sideConcept · lights on your mapserver-sideWork performed on remote backend systems the company controls. Slower to reach than client-side, and for that exact reason the only place important rules and authoritative data can be enforced. means that work happens on remote backend systems.

For example: “The form checks the email address client-side.”

This means the application performs an initial check on the user’s device.

“The server validates the email address again.”

This means the backend independently checks the information after receiving the request.

Frontend and client-side are often used in similar ways, and backend and server-side are also closely connected, but the terms emphasize slightly different things.

Frontend and backend describe parts of an application.

Client-side and server-side describe where particular work is performed.

Why some work happens client-side

Performing work on the client can make an application feel faster and more responsive. When you add an item to a cart, for example, the frontend may immediately update the cart count without waiting for a full trip to the server.

Client-side work can help with:

• Immediate visual updates
• Animations
• Basic form checks
• Temporary state
• Offline capabilities
• Reducing unnecessary server requests

This is why the cart icon might change from two items to three as soon as you tap the button.

However, the client’s version is not always the final authority.

Why important rules must be enforced server-side

The company controls the backend environment, but the user controls the device running the client.

A technically skilled user can inspect the frontend’s code, alter information stored on the device, or send a request without using the official interface at all, so the backend should not automatically trust information merely because the frontend submitted it.

Imagine that the frontend displays a latte price of $5. A user could attempt to change the request so that the submitted price is one cent.

Rather than trusting the client’s value, the backend should independently retrieve or calculate the official price.

This creates an important principle: the client can improve the experience, but the server must enforce important rules.

The frontend may check that an order contains a drink before sending it. The backend should check again before saving the order.

The frontend may display the estimated total instantly. The backend should calculate the authoritative total before charging the customer.

Client-side checks improve speed and usability. Server-side checks protect correctness and security.

Where does the source of truth live?

In Module 1, you learned about the source of truth.

For important product information, the source of truth usually exists somewhere within the backend environment, often in a database or another authoritative service.

The frontend may display a local copy of the cart, account balance, or order status, and that copy can help the application respond quickly, but the backend may hold the authoritative version.

For example, your phone might temporarily display three items in a cart, and when the application reconnects to the backend, it may discover that one item is no longer available.

The backend’s data and business rules determine what can actually be purchased.

This is a more precise version of the common idea: the frontend shows the user’s current view. The backend protects the product’s official state and rules.

What is a full-stack engineer?

A frontend engineer focuses mainly on the user-facing portion of an application.

A backend engineer focuses mainly on server-side logic, data, integrations, and supporting systems.

A full-stackConcept · lights on your mapfull-stackAn engineer who works across both frontend and backend development. The “stack” is the collection of technologies and layers used to build a product, from frontend frameworks to databases and infrastructure. engineer works across both frontend and backend development.

The word stack refers to the collection of technologies and layers used to build a product. A stack may include:

• Frontend languages and frameworks
• Backend languages and frameworks
• Databases
• Servers and cloud infrastructure
• Development and deployment tools

A full-stack engineer does not necessarily know every layer equally deeply. The term usually means that the person can contribute to both the user-facing application and the backend systems supporting it.

Team structures vary. Some companies have highly specialized frontend and backend teams, while smaller companies may expect engineers to work across the stack.

Seeing the complete flow

Imagine that a user taps Place Order in a coffee app. The frontend gathers the order information and sends a request.

The backend receives the request, verifies the user, checks the café and item availability, calculates the price, processes the payment, saves the order, and returns a response.

The frontend reads that response and displays either an order confirmation or an explanation of what went wrong.

The complete flow is:

1. The user interacts with the frontend.
2. The frontend performs immediate client-side work.
3. The frontend sends a request to the backend.
4. The backend validates the request and applies business logic.
5. The backend reads or changes authoritative data.
6. The backend returns a response.
7. The frontend updates the user interface.

This pattern appears throughout web, mobile, and desktop applications.

The mental model to remember

The frontend is the user-facing portion of an application.

The backend performs much of the behind-the-scenes logic, data access, and communication with other systems.

Client-side means work performed on the user’s device.

Server-side means work performed on remote backend systems.

A full-stack engineer works across both frontend and backend layers.

Client-side behavior can make a product feel immediate, but important business rules, permissions, and authoritative calculations should also be enforced server-side.

You should now be able to identify which parts of a product belong primarily to the frontend, which belong to the backend, and how requests and responses connect them.