FastAPI combines Python type annotations with validation, serialization, documentation, and editor support for web APIs.
2
Sebastián Ramírez built FastAPI after years of using existing frameworks and failing to find one that met his needs without fragile combinations of plugins.
3
When choosing what to build, developers should first become power users of existing tools, then build only when those tools do not solve the problem well enough.
Summary
Sebastián Ramírez explains FastAPI as a Python framework for web APIs built around type annotations and current Python features, including optional async support. FastAPI uses those annotations for data validation, serialization, automatic documentation, and editor assistance. He built it after trying many frameworks, especially Flask with plugins, and finding that none provided the developer experience and standards support he wanted. The design combines ideas from OpenAPI, JSON Schema, OAuth2, Starlette, and Pydantic. Ramírez says developers should focus on solving a problem, first learning existing solutions well before creating another tool. He also describes how he maintains FastAPI by continuing to use it in substantial applications, so he encounters the same confusing errors and rough edges as other users. Looking ahead, he expects stronger type checking for tensor dimensions and closer integration between Python's async programming model and machine learning systems. He also discusses how years of experience are a poor proxy for skill and how difficult it is to keep up with fast-moving tools.
FastAPI uses type annotations as one source of information for an API
Sebastián Ramírez describes FastAPI as a Python framework designed for building web APIs. It supports async code without requiring it and uses ordinary Python type annotations such as string and float. Those annotations help editors check code and provide completion. FastAPI also uses them for data validation, serialization, documentation, and other API behavior. The framework follows OpenAPI and related standards, then generates an interactive API documentation interface from the application code. This lets developers declare information once instead of repeating it across validation, documentation, output formatting, and other parts of the application.
FastAPI grew gradually because it combined useful ideas from other tools
Ramírez says he expected FastAPI to remain a niche framework used by a small group of enthusiasts. Its adoption grew because the problems it addressed were common and the ideas came from established frameworks, libraries, and other programming languages. Before FastAPI, his best option was Flask combined with several plugins. That setup was fragile because the plugins were not designed to work together. He learned from that experience and from other open-source contributions, then applied those lessons to a framework with a more integrated design. He still finds it surprising when large companies say they use FastAPI.
The framework's design came after years of studying standards and existing components
FastAPI was not a project Ramírez started immediately after having an idea. He spent years trying different frameworks because he did not want to create another ecosystem. After the tool he preferred was deprecated, he decided to build what he needed. He studied OpenAPI for API definitions, JSON Schema for describing JSON data, and OAuth2 for authentication and authorization. He built FastAPI on Starlette, created by Tom Christie, and integrated Pydantic's data model and validation features. He describes the process as preparing the ingredients before cooking the final recipe. The implementation required understanding difficult parts of Python and Pydantic's internal behavior.
FastAPI was designed around less repetition and a better editor experience
Ramírez wanted autocomplete, inline errors, automatic validation, interactive documentation, security tools, dependency injection, and short, simple code. He disliked declaring that a field was a string in several different systems for documentation, validation, serialization, and database behavior. Repeating the same metadata made refactoring error-prone. He also designed the public interface before writing the internal implementation, then tested it in Visual Studio Code, PyCharm, and editors based on Jedi. His goal was for developers to get a good experience regardless of which editor they used. He calls autocomplete one of his recurring priorities.
Developers should solve a problem after checking whether an existing tool already works
When Adam Sroka asks what technically capable developers should build next, Ramírez recommends focusing on a problem that matters to them. He treats innovation and disruption as possible side effects of solving a problem, rather than as the starting point. A specific problem helps determine what to learn and what to ignore. He also recommends becoming a power user of existing solutions before writing a replacement. If available tools do not solve the problem conveniently enough, building something new may make sense. This was his own path with FastAPI, although he first spent a long time trying not to create another framework.
Maintainers need to keep using their own tools as users
Ramírez says open-source developers can end up spending more time maintaining a project than using it. That can make them optimize for the maintainer's work instead of the user's problems. He therefore tries to use FastAPI as a developer in real applications. One issue he wants to improve appears when an application returns data that does not match a declared Pydantic response model. FastAPI correctly treats this as a server error because the application has broken its contract with the client, but the current error can contain a long stack trace that does not clearly identify the source. Experiencing this problem himself helps him decide what to improve.
Type annotations could catch tensor shape errors before machine learning code runs
Ramírez expects Python's type system to become more useful for multidimensional arrays and tensors. He discusses a recently accepted way to include array or tensor dimensions in type annotations. If libraries such as NumPy, TensorFlow, and PyTorch adopt that information, editors could flag incompatible matrix sizes directly in the code. Developers would see an inline error instead of running a script and discovering the mismatch at runtime. He describes matrix multiplication with incompatible dimensions as a common mistake that can take time to diagnose. Type-aware editors could point to the error where it occurs.
Async Python and machine learning systems may work together more closely
Ramírez says many machine learning, MLOps, and data science APIs and packages are blocking and do not use async and await. He expects more interaction between the machine learning world and Python's async ecosystem. Learning to combine the two could improve concurrency, performance, and distributed applications. He connects this possibility to Python's continued development as a language for concurrent programming and to its existing role in machine learning. He is also exploring type annotations and editor support with Anyscale, the creators of Ray, with the aim of making distributed Python applications easier to write and safer to check.
Years of experience are an unreliable measure of engineering skill
Ramírez criticizes job requirements that ask for a fixed number of years using a particular tool. A requirement for four years of FastAPI experience would have excluded him from a job because he had built FastAPI only about a year and a half earlier. He says years of experience have some correlation with skill, but they are a poor estimator. Someone can spend ten years doing repetitive work, while another person can gain extensive experience by solving difficult problems in a short period. The rapid arrival of new frameworks and tools makes time-based requirements even less useful.
"The best way just to try to run the code, try to test it locally a little bit, and that gives a lot more sense of does it work for me or not."Sebastián Ramírez49:44
Who should watch
You are building Python APIs for machine learning systems and want validation, documentation, and editor support from the same type information.
You are considering creating a new developer tool and need a practical test for whether existing projects already solve the problem.
You maintain an open-source library and want to understand why using it in real applications can expose better improvements than maintenance work alone.
