FastAPI: The Three-Body Framework

The Trinity You Never Chose

This is episode twelve of What Did I Just Install.

If you write Python and your code talks to the internet, there is a very good chance FastAPI is somewhere in your stack. Startups use it for their first API prototype. Data teams use it to serve machine learning models. Hobby projects use it for home automation dashboards, booking systems, notification gateways, and quick internal tools. A survey of Python developers in twenty twenty-four found that FastAPI had overtaken Flask as the most popular Python web framework for new projects. And every single one of those projects starts the same way. Import FastAPI, create an app, decorate a function, return some data. Three lines of code to have an API endpoint running on your laptop.

But here is the thing the listener might not know. When you type pip install fastapi, you are not installing one package by one person. You are installing the work of three people who never collaborated, who built their pieces independently on three different continents, and whose code fits together like it was designed as a single system. Sebastián Ramírez in Berlin built the framework you write your code in. Tom Christie in Brighton built the foundation it runs on. Samuel Colvin in London built the validation layer that checks every piece of data that flows through it. FastAPI sits on top of Starlette, which handles routing, middleware, and WebSocket connections. Starlette sits next to Pydantic, which validates and serializes every request and response. And underneath all of it, Uvicorn, also by Christie, serves as the actual server that listens on a port and speaks HTTP.

Three people. Three packages. One stack. And the story of how they found each other is the story of Python finally growing up.

The Boy Who Was Expelled for Asking Questions

Sebastián Ramírez grew up in Medellín, Colombia. At the age of seven, he was expelled from Catholic school for asking too many challenging questions. His parents, rather than finding another school with stricter discipline, told him something that would shape the rest of his life.

You are doing great. Keep following your curiosity.

They pulled him out of the system entirely and homeschooled him on a farm in Santa Elena, outside Medellín, emphasizing hands-on learning and self-directed exploration. No grades. No curriculum in the traditional sense. Just a curious kid with access to the internet, teaching himself HTML and CSS at fifteen, then JavaScript, then Python, reading documentation and open standards the way other teenagers read novels. He taught himself English the same way, through technical documentation and online courses. No tutor, no immersion program, no semester abroad. Just a screen and stubborn curiosity.

He never got a degree. He went straight from homeschooling into work, joining a startup in Colombia that dealt with big data and machine learning. From there he moved to Dubai, where he spent years managing software developers and building backend systems. And it was in Dubai, sometime around twenty seventeen, that the frustration crystallized. He was watching his colleagues struggle with their tools. The Python web frameworks they were using, Flask and Django, had been created before Python introduced two features that would change everything: type annotations and async await. Flask was synchronous. Django was a monolith. Neither of them used type hints for anything beyond documentation. And Ramírez, the kid who had taught himself to code by reading documentation, kept thinking the same thought over and over.

I just kept thinking I need to do this. I need to build this.

He studied every framework he could find. Flask, Django REST Framework, Falcon, Hug, Molten, APIStar, Sanic, even NestJS from the JavaScript world. For each one he wrote down what he loved and what drove him crazy. He spent years on this. Not weeks, not a weekend hackathon. Years. And on Christmas Eve, twenty eighteen, sitting in Berlin where he had recently moved, he published the first version of FastAPI to GitHub.

The name was a double meaning, and a deliberate one. Fast because of performance, built on the fastest Python web framework available at the time. And fast because of development speed, because type hints meant your editor could autocomplete everything, catch errors before you ran the code, and generate documentation automatically. Fast to run and fast to write. Both meanings packed into seven characters.

The Man from Brighton Who Built the Floor

To understand what Ramírez built FastAPI on top of, you need to go to Brighton, on the south coast of England, and meet a very different kind of developer. Tom Christie studied computer science at Manchester University, graduated with a first-class degree, then went to Cambridge for a master's in computer speech and language processing. He started his career in the late nineties working on speech recognition software, moved through Alcatel-Lucent, and eventually landed at a web development agency called DabApps in Brighton around twenty twelve.

It was at DabApps that Christie created the thing that first made him famous in the Python world. Django REST Framework, released in twenty eleven, became the standard way to build APIs in Django. It was not flashy. It was not fast. But it was thorough, well-documented, and it solved real problems that every Django developer faced when they needed to expose their data to the outside world. Within a few years, over a hundred thousand repositories depended on it. Mozilla used it. Red Hat used it. Eventbrite, Heroku, and dozens of other companies built their backends on Christie's work.

But Christie was not satisfied. He could see something coming that Django was not built to handle, and that something was asynchronous Python. The web was changing. WebSocket connections, server-sent events, long-polling, real-time updates. All of these required the server to hold connections open, to do multiple things at once without blocking. Python's traditional web standard, WSGI, the one we traced back to Phillip Eby's PEP three thirty-three in the Express episode, was fundamentally synchronous. One request in, one response out, move on. ASGI, the Asynchronous Server Gateway Interface, was the answer. And Christie decided to build the tools that would make it real.

In twenty sixteen, he left DabApps and founded Encode, a one-person organization with a mission statement that sounded almost quixotic: build a sustainable business model for collaboratively funded open-source development. It was a bet. Christie was walking away from a steady technical lead position to maintain open source full-time, funded by sponsorships and consulting, in a field where we have spent ten episodes documenting how badly that usually works out.

We are building the fundamental components for a high-performance async web stack.

Under the Encode banner, he started building the async Python web stack from the ground up. First came Uvicorn, an ASGI server built on uvloop and httptools, the lightning-fast event loop and HTTP parser that could handle tens of thousands of concurrent connections. Then came Starlette.

Starlette, released in late twenty eighteen, was a lightweight ASGI framework and toolkit. Routing. Middleware. WebSocket support. Background tasks. Static file serving. Session management. Test client. Everything you need to build a web application, nothing you do not. The entire codebase was one hundred percent type-annotated. It was, at the time, the fastest Python web framework anyone had benchmarked, surpassed only by Uvicorn itself, which is a server, not a framework.

The name is worth a pause. Christie's Twitter handle is starletdreaming. Starlette, a diminutive of star, the little star. It was personal, not corporate. A quiet, almost gentle name for something that would become the invisible foundation of the most popular Python web framework in the world.

And then Christie did something else remarkable. He built httpx, a next-generation HTTP client that could do both synchronous and asynchronous requests with HTTP one point one and HTTP two support. Remember how in the requests episode, we talked about Kenneth Reitz's dream for Requests three, the async rewrite that never shipped? httpx was the library that dream was supposed to become. Christie just built it himself, under the Encode umbrella, while nobody was looking. It has been quietly replacing requests across the Python ecosystem wherever async performance matters, and it appears as a dependency in thousands of projects that outgrew the synchronous model.

And then there is MkDocs. Christie also created MkDocs, one of the most widely used documentation generators in the Python ecosystem. He originally built it for Django REST Framework's documentation, and it grew into a standalone project used by thousands of open-source projects. If you have ever read documentation on a website with a clean sidebar, a search bar, and markdown-rendered pages, there is a good chance you were looking at MkDocs.

Stop and think about that for a moment. One person, working mostly alone from Brighton, built the most popular Python API framework, the most popular async Python web framework, the recommended Python ASGI server, a next-generation HTTP client, and one of the most popular documentation generators. Five major projects, all maintained under one umbrella organization. Tom Christie is, by volume of critical infrastructure maintained per person, one of the most important developers in the Python ecosystem. And almost nobody outside the Python community knows his name, because he builds foundations, not headlines.

The Professional Pedant

While Christie was building the floor in Brighton, a developer in London was building the walls. Samuel Colvin is a Python and Rust developer who, in twenty seventeen, looked at the Python ecosystem and saw a gap. Python three point five had introduced type hints the year before, but nobody was really using them for anything practical. They were documentation, suggestions, comments that the runtime ignored entirely. Colvin thought that was a waste. Type hints contained real information about what data should look like, and that information could be used to validate data automatically.

He started building Pydantic in his spare time. The name was a pun, and a perfect one. Take pedantic, meaning excessively concerned with minor details and rules, add a "py" for Python, and you get Pydantic. A library that is pedantically precise about the shape and type of your data, written in Python. Colvin would later describe himself on social media as a professional pedant, leaning into the joke entirely.

The idea was elegant. You define a Python class with type hints. Pydantic reads those hints and automatically validates any data you throw at it. Pass in a dictionary from a JSON API response, and Pydantic checks every field, converts types where it can, and raises clear errors where it cannot. No schemas to write in a separate format. No validation decorators. No YAML configuration files. Just Python classes with standard type annotations, and the library does the rest.

I realized the untapped value of type hints in Python. They contained real information about data shape, and nobody was using that information at runtime.

What made Pydantic different from earlier validation libraries like Marshmallow was not just the type hint approach. It was the developer experience. Error messages were specific and useful. The JSON Schema output was automatic, which meant any tool that understood JSON Schema could understand your Pydantic models. And because type hints were a standard Python feature that editors already understood, your autocomplete and inline error checking worked perfectly with Pydantic models. You did not need a plugin. You did not need a special IDE. The validation layer and the editor support were the same thing.

By twenty twenty-two, Pydantic had about twenty-two million monthly downloads from PyPI and was embedded so deeply in the Python ecosystem that removing it would break virtually every modern API framework, every data pipeline, and increasingly, every AI tool. The OpenAI Python SDK depended on Pydantic. The Anthropic SDK depended on Pydantic. LangChain depended on Pydantic. If you were building anything that talked to a large language model in Python, you were using Samuel Colvin's validation library whether you knew it or not.

The Convergence

Here is where the story gets beautiful. Three developers, working independently, built three things that fit together as if they had been designed by one mind.

Christie built Starlette, the fast async web foundation. Colvin built Pydantic, the validation layer that turned type hints into runtime guarantees. And Ramírez, the self-taught developer from Medellín who had spent years cataloging what every framework got right and wrong, looked at both of them and saw the missing piece. Nobody had combined them. Nobody had built a framework that used Pydantic's type-hint validation as its core interface and Starlette's async performance as its engine.

But there was one more ingredient, and it came from Christie too. Before Starlette, before httpx, Christie had built a project called APIStar. It was an experimental API framework that used Python type hints for validation, serialization, and automatic documentation generation, all in one system. It was ambitious, clever, and ahead of its time. APIStar used type annotations to do everything at once: validate incoming data, serialize outgoing responses, and generate an OpenAPI schema that described the entire API. One source of truth. One set of type hints. Everything else derived automatically. It was exactly the vision Ramírez had been sketching in notebooks for years.

And then Christie abandoned it to focus on Starlette, reasoning that building the foundational toolkit was more important than building the framework on top of it. This is a decision that reveals something essential about Christie's character. He is an infrastructure builder. He does not want to build the house, he wants to build the tools that make houses possible. Django REST Framework was the infrastructure for Django APIs. Starlette was the infrastructure for async Python web applications. Uvicorn was the infrastructure for ASGI servers. httpx was the infrastructure for HTTP clients. Every time Christie reaches the framework level, the level where ordinary developers interact with his work, he stops and goes back down to build more foundation. It is a specific kind of genius, and it is why so few people outside the Python community know his name.

Ramírez found APIStar. He found it inspiring. He later called FastAPI the spiritual successor to APIStar. But where Christie had moved away from the framework layer to build infrastructure, Ramírez moved toward it. He took APIStar's ideas, Starlette's performance, and Pydantic's validation, and he welded them together into something none of the three pieces could be alone.

FastAPI would not exist if not for the previous work of others. There have been many tools created before that have helped inspire its creation. I have been avoiding the creation of a new framework for several years.

This is the part that is unusual and says something important about Ramírez as a person. The FastAPI documentation has an entire page called Alternatives, Inspiration and Comparisons. It is not a marketing page. It is a credits page. He lists every framework that influenced FastAPI, from Flask to NestJS to Hug to Molten, and for each one he explains exactly which features he took and why. He credits Requests for the intuitive API design. He credits Django REST Framework for automatic API documentation. He credits Marshmallow for the schema concept. He credits APIStar for the type-hint-driven approach. He credits NestJS for the dependency injection system. He even credits Swagger and OpenAPI for the documentation standard.

In open source, where projects routinely claim to be novel and revolutionary, Ramírez published what amounts to a bibliography. He showed his work. The homeschooled kid who learned by reading documentation built a framework and then documented where every idea came from. And there is something poignant about the APIStar connection. Christie built the idea but walked away from it. Ramírez found the abandoned idea, recognized its potential, and carried it forward on top of Christie's own infrastructure. The framework builder built his framework on the foundation of the man who had the idea first but chose to keep building foundations instead.

The ASGI Revolution

To understand why this particular combination was explosive, you need to understand what changed in Python around twenty seventeen and twenty eighteen. The middleware pattern we traced in the Express episode, the chain of handlers that a request passes through on its way to a response, had been the standard architecture since Eby wrote PEP three thirty-three in two thousand and three. WSGI worked. It was simple. And it was synchronous, which meant every request occupied a thread or process for its entire lifetime. If your endpoint needed to wait for a database query or an external API call, it sat there, blocking, doing nothing, occupying resources.

For most of the two thousands and early twenty tens, this was fine. Web applications were mostly request-response cycles. A browser sends a request, the server processes it, the server sends a response, the connection closes. But the modern web needed more. Real-time chat. Live dashboards. WebSocket connections that stay open for minutes or hours. Server-sent events that push data to the client. And async Python, with the async and await keywords that arrived in Python three point five, made all of this possible at the language level.

But there was no standard for how an async Python web application should talk to an async Python web server. WSGI could not handle it. The interface was fundamentally synchronous. So a new standard emerged: ASGI, the Asynchronous Server Gateway Interface. It was designed to be a superset of WSGI, handling both synchronous and asynchronous applications, with native support for WebSockets and long-lived connections.

Christie bet on ASGI early. He built Uvicorn as the ASGI server and Starlette as the ASGI framework. When FastAPI arrived on Christmas Eve twenty eighteen, built on top of Starlette, it was not just a new framework. It was the first major framework that made the ASGI stack accessible to ordinary developers. You did not need to understand event loops or coroutines or the difference between asyncio and trio. You just wrote a function, decorated it, added type hints, and FastAPI handled the rest. Async was there if you wanted it, invisible if you did not.

That last point is subtle and important. Ramírez made async optional. You could write a regular synchronous function and FastAPI would run it in a thread pool. You could write an async function with await and FastAPI would run it on the event loop. You did not need to choose a philosophy or rewrite your code. You just wrote what made sense for each endpoint, and the framework figured out the rest. This lowered the barrier to async Python from understanding computer science concepts to understanding nothing at all. The framework did the thinking for you. And that was the real innovation, not async support itself, which Sanic and others had done before, but async support that required zero understanding of async.

The growth was staggering. Within two years, FastAPI was one of the fastest-growing Python projects on GitHub. By twenty twenty-three, it was receiving roughly eight hundred thousand downloads per day. By twenty twenty-four, it had reached over seventy thousand GitHub stars and was closing in on Django, something that would have seemed absurd just five years earlier. A framework built by a single self-taught developer on top of two other people's work, threatening the dominance of the project that had defined Python web development for nearly two decades. Netflix adopted it. Microsoft adopted it. Google, Uber, the Red Cross, and NASA's Space Telescope Science Institute all run FastAPI in production.

The community response was unlike anything the Python web world had seen. Developers who had spent years with Flask or Django started rewriting their projects. Python conferences were suddenly full of FastAPI talks. The phrase that kept appearing in forums and blog posts was almost always some variation of the same idea.

I tried FastAPI on a weekend project and I cannot go back to Flask. The type hints do everything. The docs write themselves.

Part of the explosion was timing. FastAPI arrived at the exact moment when Python was becoming the default language for machine learning and AI. Data scientists and ML engineers needed to deploy models behind APIs, and they needed to do it fast, without learning web development. FastAPI's type-hint-driven interface felt natural to people who were already using type hints in their data pipelines. The automatic documentation meant they could hand an endpoint to a frontend team without writing a single line of specification. The validation meant bad data got caught before it reached the model. It was not designed for AI, but it was perfectly shaped for the AI era.

Standing on Shoulders, Building the Roof

The dependency tree of FastAPI is a lesson in layered architecture, and it is surprisingly clean for something this widely used.

FastAPI depends on Starlette for everything related to the web layer. Routing, middleware, request and response objects, WebSocket handling, background tasks, test client. When Ramírez says that anything you can do with Starlette you can do directly with FastAPI, he means it literally. The FastAPI class inherits from the Starlette class. It is Starlette on steroids, as the documentation puts it.

FastAPI depends on Pydantic for everything related to data. Request body validation, query parameter parsing, response serialization, JSON Schema generation for the automatic documentation. Every time you define a function parameter with a type hint in a FastAPI endpoint, Pydantic is the engine that validates the incoming data against that type.

Starlette depends on anyio, a compatibility layer for async frameworks, and httpx for its test client. It is deliberately minimal. Pydantic, as of version two, depends on pydantic-core, a Rust extension that does the actual validation work at near-C speeds. And underneath the whole thing, Uvicorn, also by Christie, runs as the ASGI server that actually listens on a port and turns HTTP bytes into Python objects.

The elegance of this architecture is that each layer does one thing and does it well. Uvicorn speaks HTTP. Starlette routes requests. Pydantic validates data. FastAPI ties them together with an interface so clean that a developer can go from zero to a working, documented, validated API in about fifteen minutes. And crucially, each layer is replaceable. You can use Starlette without FastAPI. You can use Pydantic without Starlette. You can run any ASGI framework on Uvicorn. The pieces are independent, created by independent people, and they happen to compose beautifully.

The Rust Rewrite and the Seventeen Million Dollars

Samuel Colvin's story takes a dramatic turn in twenty twenty-two. Pydantic version one was written entirely in Python. It worked, it was popular, and it was slow. Validation code runs on every single piece of data that enters or leaves an application, which means it runs millions of times per hour in a busy API. Colvin looked at the performance profiles and decided that Python, for this particular task, was not fast enough.

He started rewriting the core validation logic in Rust. Not the Python API, which stayed Pythonic and familiar, but the engine underneath it. The new package was called pydantic-core, and it was a Rust extension module that Python called into for every validation operation. Think of it like a car. The steering wheel, the dashboard, the seats, everything the driver touches, that stayed Python. But the engine under the hood was rebuilt from scratch in a language that compiles to native machine code and runs without a garbage collector.

The rewrite took about a year and a half of full-time work. Colvin was working alone for most of it, learning Rust's memory management model and its Foreign Function Interface while simultaneously maintaining Pydantic version one for millions of users. When Pydantic version two shipped in mid twenty twenty-three, it was five to fifty times faster than version one depending on the operation. The validation that had taken microseconds now took nanoseconds. For applications processing thousands of API requests per second, the difference was material.

This is a pattern the series has tracked before. Charlie Marsh rewrote Python's linter in Rust and created Ruff, which we covered in the package management episode. The uv package installer, also by Marsh's Astral, is Rust replacing Python for speed-critical infrastructure. Colvin was part of the same wave, the realization that Python's role is changing. Python is becoming the language you write in, while Rust is becoming the language your Python runs on. The interface stays human-readable. The engine gets rebuilt for machines.

I started working on the rewrite in Rust at the beginning of twenty twenty-two. I worked on it full-time for a year and a half. Once the company started, people came and joined.

The company. That is the other part of the story. In twenty twenty-three, Colvin raised seventeen million dollars from Sequoia Capital, with additional investment from Partech and Irregular Expressions. Angel investors included the co-founder of Zapier and the founders of Sentry and dbt Labs. The company, Pydantic Services, was not just about the validation library anymore. Colvin built Logfire, an observability platform, and PydanticAI, an agent framework for building AI applications. The professional pedant had become a startup founder.

By twenty twenty-six, Pydantic was being downloaded over three hundred million times per month. It was a dependency of essentially every major AI Python library. The OpenAI SDK, the Anthropic SDK, LangChain, LlamaIndex, CrewAI. The explosion of large language model tooling in twenty twenty-three and twenty twenty-four did not just grow Pydantic's download count. It made Pydantic load-bearing infrastructure for an entirely new category of software.

Three Funding Stories

The funding situations of these three developers tell three different stories about how open source sustains itself, and each is different from the patterns we have seen in earlier episodes.

Tom Christie runs Encode on a collaborative funding model. GitHub Sponsors, corporate sponsorships, and occasional consulting. He has no venture capital, no acquisition, no employer paying him to work on open source full-time. He built Django REST Framework, Starlette, Uvicorn, httpx, and MkDocs, and he funds all of it through Encode's modest revenue. For years, Encode was essentially one person with some part-time contributors, maintaining multiple critical pieces of the Python web infrastructure. The sustainability question that haunts this entire series, the one we keep circling back to, applies to Christie as acutely as anyone. The floor that FastAPI stands on is maintained by a small team in Brighton on a budget that would not cover a single engineer at Netflix.

Samuel Colvin took the venture capital path. Seventeen million dollars, a company, employees, a product roadmap. The validation library became the wedge for a business. This is the path that Redis tried, that npm tried, and that the series has documented the risks of. But Colvin's approach is different in one crucial way: the open-source library remains open under the MIT license, and the commercial products, Logfire and PydanticAI, are built on top of it rather than locked behind a license change. Whether that model sustains itself long-term is an open question, but so far there has been no Valkey moment, no community revolt, no sudden relicensing.

Sebastián Ramírez's path is perhaps the most interesting. In January twenty twenty-three, Sequoia Capital invited him to be the first fellow in their new Open Source Fellowship, a program that paid him to work on open source full-time with no strings attached, no equity demanded, no product roadmap imposed. It was, in effect, a patron funding an artist. The homeschooled kid from Medellín who taught himself to code from documentation was now funded by one of the most powerful venture capital firms in Silicon Valley to keep doing what he had been doing for free.

When you build something that others can use and it is helping them, that just feels amazing.

Three packages. Three funding models. A collaborative funding nonprofit, a venture-backed startup, and a fellowship from a venture capital firm. The series has shown us what happens when funding fails, when maintainers burn out, when companies change licenses. Redis raised three hundred and forty-seven million dollars and the creator still left because maintenance killed his creativity. npm raised nineteen million and was acquired by Microsoft. The SQLite Consortium charges a hundred and twenty thousand dollars a year and the creator says he makes enough. Christie takes sponsors. Colvin takes venture capital. Ramírez takes a fellowship. Three people, three bets on how to sustain open source, and all three are still in the middle of their stories. We do not know the endings yet.

The Documentation Difference

There is one more thing about Ramírez that deserves its own chapter, because it connects directly to who he is and how he learned. The FastAPI documentation is legendary in the Python community, and it is not an accident. It is the direct product of a person who taught himself everything from documentation.

Remember, this is a person who was homeschooled on a farm outside Medellín, who learned to code by reading documentation for HTML, CSS, and JavaScript, who learned English by reading technical documentation. He knows, viscerally and personally, what it feels like when documentation fails you. When it assumes knowledge you do not have. When it skips steps. When it is written for the person who already understands the thing, not the person who is trying to learn it.

I wanted things to be explained the way I wished they were explained to me when I was starting.

The FastAPI documentation includes interactive examples, visual diagrams, and explanations that assume nothing about the reader's background. Every feature is demonstrated with complete, runnable code. The alternatives page we mentioned, the one that credits every inspiration, is itself a masterclass in comparative framework analysis. It is not marketing. It is education. And it reflects the worldview of someone who believes that the biggest barrier to technology is not intelligence but access to clear explanation.

This matters to this series because it inverts the pattern we have seen. Kenneth Reitz wrote the documentation before the code and created the most beloved Python library. Daniel Stenberg has written four books about curl and maintains one of the best technical blogs in the industry. Richard Hipp wrote more test code than source code and funded SQLite through a consortium built on trust. In each case, the non-code work was as important as the code. Ramírez took this further than anyone. He built a framework and then built a documentation site that teaches not just FastAPI, but Python, type hints, async programming, API design, authentication, databases, and deployment. The documentation is larger than the framework.

Where All the Roads Lead

Let us count the ways these three packages show up in a typical Python developer's life, because the number is honestly a little staggering.

Think about all the Python projects on your machine. If any of them serve an API, there is a good chance FastAPI and Uvicorn are in the requirements file. A podcast server. A dashboard. A booking system. A notification gateway. An image processing API. A machine learning model endpoint. Every single one of them, regardless of what it does, passes HTTP requests through the same three-layer stack. Christie's Starlette handles the routing, Colvin's Pydantic validates the data, and Christie's Uvicorn serves the responses.

Pydantic appears explicitly in some project requirement files, but it is installed in every project that uses FastAPI because FastAPI depends on it. httpx, Christie's async HTTP client, shows up wherever developers have outgrown the synchronous requests library. Starlette is installed globally, a foundation so deeply embedded that it is part of the operating system rather than any single application.

Think about what that means in concrete terms. When someone subscribes to a podcast, their app makes an HTTP request to an RSS feed endpoint. That request hits a server somewhere, where Uvicorn, written by Christie, accepts the TCP connection and parses the HTTP headers. The request passes through Starlette's routing layer, also by Christie, which matches the URL pattern to the right handler function. FastAPI, by Ramírez, calls that function and validates any query parameters through Pydantic, by Colvin. The function queries a database, builds the XML, and returns it as a response. Starlette serializes the response. Uvicorn writes it to the socket. The podcast app parses the XML and downloads the episode. Three people's code, three separate packages, one seamless pipeline, executing in milliseconds.

The Express episode talked about how FastAPI's middleware descends from the Connect and Express pattern that Christie's work adapted for Python. That was the architectural lineage. This is the living reality. Every FastAPI endpoint on every server in the world, from hobby projects to Netflix's internal tools, runs through the work of a self-taught Colombian, a Cambridge-educated Englishman, and a London-based professional pedant.

If I feel I am doing something simple, mechanical, and repetitive, I just want to make it faster, or automate it.

Ramírez automated the entire Python API development experience. Christie built the floor it stands on and the server it runs behind. Colvin built the walls that keep bad data out. Three people who never worked together, whose code fits like puzzle pieces, powering the majority of modern Python web applications.

There is a word for what happened here, and it is not collaboration. Collaboration implies intention, coordination, meetings, shared roadmaps. What happened with FastAPI, Starlette, and Pydantic is more like convergent evolution. Three developers, in three cities, responding to the same environmental pressure, the same gap in the Python ecosystem, built components that fit together because they were all solving the same problem from different angles. Christie solved it from the bottom up, building servers and frameworks. Colvin solved it from the side, building validation. And Ramírez solved it from the top down, building the interface that unified everything underneath.

The result is that when you type pip install fastapi, you are not installing one person's vision. You are installing three visions of what Python should be, assembled into one framework by a self-taught developer who spent years studying every other framework and then had the humility to credit all of them. The boy who was expelled from school for asking too many questions built the framework that answers all of yours. The man from Brighton who keeps building foundations built the one that everyone else now stands on. And the professional pedant who saw untapped value in type hints turned his perfectionism into a company worth tens of millions of dollars. Three stories, three packages, running everywhere you look.

Type pip install fastapi uvicorn. Create a file called main dot py with four lines: from fastapi import FastAPI, then app equals FastAPI open close parentheses, then at app dot get slash, then a function that returns a dictionary with a key and a value. Run it with uvicorn main colon app dash dash reload. Open your browser to localhost colon eight thousand. You will see your dictionary as JSON. Now visit localhost colon eight thousand slash docs. That is the automatic interactive API documentation that Ramirez built, generated entirely from your type hints. Click the endpoint, click Try It Out, click Execute. You just tested your own API without writing a single line of documentation. That is what the boy expelled for asking questions wanted programming to feel like.

That was episode twelve.