FastAPI Lesson 1: Understanding Frontend-Backend Separation and RESTful APIs

Starting with Web Development Patterns

Before diving into FastAPI, it's important to understand the technical context that gave rise to it. Rather than jumping straight into code, this opening lesson of the FastAPI tutorial series starts by clarifying two fundamental Web development patterns — because FastAPI's design philosophy is shaped precisely by the differences between them.

At the heart of any Web application is a core question: who provides the UI, the interactive effects, and the data that users see in their browser? The industry has evolved two distinctly different answers: "coupled" (frontend-backend not separated) and "decoupled" (frontend-backend separated). Understanding the difference between them is key to appreciating why FastAPI has become such a popular choice for backend development today.

Coupled Architecture: One Server Does Everything

The coupled approach is the more traditional model from a few years back. Its defining characteristic is straightforward: everything the browser sees — the UI itself, the button interactions, and the data displayed — is served by a single server.

The flow works like this: the browser sends a request, the application server queries the database, processes the data, applies business logic, and then renders it all into a complete HTML page that gets sent back to the browser. In other words, business logic, data processing, and UI rendering all live in the same server.

This model has two obvious pain points. First, development efficiency is low — because the UI and data are tightly coupled, the frontend design has to be finalized before the backend can fill in data and render pages. Second, there's no clean technical separation, making it difficult for frontend and backend teams to work in parallel. This pattern is worth understanding for context, but the real focus lies in the alternative.

Decoupled Architecture: The Standard for Enterprise Projects

The core idea behind frontend-backend separation is splitting by technology. Frontend assets — HTML, CSS, and JavaScript — are developed and deployed on a dedicated server (often called a static file server), while backend business logic and data processing run on a separate Python application server.

The key difference is that you have at least two servers: one dedicated to the frontend, one to the backend. The immediate benefit is that teams can work in parallel — once requirements are confirmed, the frontend and backend teams can start simultaneously without waiting for the other side to finish. This is currently the most popular pattern for enterprise-level Web projects, accounting for over 90% of modern deployments.

Under this architecture, browser requests are directed separately: UI requests go to the frontend server, data requests go to the Python application server. The backend exposes a unified API interface and is only responsible for handling business logic and returning data — whether the request comes from a browser, a WeChat Mini Program, or an Android/iOS app, it doesn't care how the client renders that data.

A note on data formats: over 95% of modern frontend-backend communication uses JSON — it's concise, language-agnostic, and easy to work with. The older XML format is now largely legacy technology, having been replaced by JSON in most contexts.

FastAPI's Role: Built for Decoupled Architecture

With both patterns in mind, FastAPI's positioning becomes clear. FastAPI was "born for frontend-backend separation" from day one.

Its foundation is Starlette, a framework that was purpose-built for API interfaces and backend development from the very beginning. This determines FastAPI's primary domain: backend service development in a decoupled architecture.

Can it handle coupled projects? Yes. Because it's built on Starlette, FastAPI can integrate the Jinja2 template engine to perform server-side rendering (which is what coupled architectures require). But this isn't its primary use case — FastAPI leans heavily toward backend development and is positioned as "the most mainstream and fastest backend framework for external services going forward."

Starlette is a lightweight Python async Web framework/toolkit developed by Tom Christie, built on top of the ASGI (Asynchronous Server Gateway Interface) standard. Unlike traditional WSGI frameworks (such as Django and Flask), ASGI natively supports async operations, allowing the framework to switch between requests during I/O wait times (such as database queries or network calls), dramatically improving concurrency performance. FastAPI inherits all of Starlette's features — including WebSocket support, background tasks, and middleware — and adds data validation (via Pydantic) and automatic interactive API documentation (Swagger UI and ReDoc). This is the fundamental reason FastAPI benchmarks competitively with Node.js and Go: its high performance isn't achieved through optimization tricks, but is determined at the architectural level by its async foundation.

What Are API Interfaces and the RESTful Specification?

API stands for Application Programming Interface. It's an entry point that an application exposes for manipulating data — this entry point can be a function, a class, or a URL. Clients simply send a request to this entry point to invoke it.

There are two mainstream API interface specifications: REST and RPC. RPC is an interface development protocol; REST is often described as a "development style" — essentially a set of conventions agreed upon by the community. Both are standards, but RPC has relatively low market share today. REST dominates because it's convenient and reasonably secure.

REST stands for Representational State Transfer. The name itself isn't worth overthinking — like ISO9001, it's simply the name of an internationally recognized standard.

The core of REST is resource-oriented programming. It treats every API interface as a resource: a client requests an interface to receive the corresponding resource, and a resource is fundamentally just data. Under this philosophy, the backend's job is to provide data access interfaces, using URL paths to represent the resources being operated on.

For the same resource, different HTTP methods express different operations. Using "students" as an example:

• POST /students — Add a student
• GET /students — Get all students
• GET /students/1 — Get the student with ID 1
• PUT /students/1 — Update the student with ID 1
• DELETE /students/1 — Delete the student with ID 1

As you can see, the combination of a URL path and an HTTP method clearly expresses "what operation to perform on which resource." This resource-centric approach — using consistent verbs to express operations — is the essence of RESTful API design, and it's a pattern you'll use repeatedly in FastAPI development.

RPC (Remote Procedure Call) differs from REST at the conceptual level: REST is resource-centric, using URLs to describe nouns (the target of the operation) and HTTP methods to describe verbs (what to do); RPC is action-centric, with interfaces directly describing callable functions, such as getUserById(1) or deleteStudent(1). Common RPC implementations include Google's gRPC (based on Protocol Buffers and HTTP/2) and JSON-RPC. gRPC is popular for inter-service communication in microservice architectures due to its higher throughput and stricter interface contracts. However, for public-facing APIs targeting browsers or mobile clients, REST remains the overwhelming preference thanks to its readability, natural alignment with HTTP semantics, and broad toolchain support. FastAPI's design is entirely REST-oriented — route decorators like @app.get() and @app.post() are direct mappings to HTTP method semantics.

Summary

This opening lesson doesn't write a single line of FastAPI code, yet it lays the conceptual groundwork for understanding the framework: frontend-backend separation defines FastAPI's role as a backend tool, JSON is its default communication language, and the RESTful specification is the methodology it uses to organize interfaces. With these concepts in place, diving into specific features like routing, dependency injection, Pydantic, async, and ORM becomes a much more natural progression.