Today, I’m joined by Sebastián Ramírez, a software developer at Explosion AI. He is also the creator of the popular frameworks FastAPI and Typer. In this interview, we discuss typing in Python, his motivations for creating FastAPI and the future of the framework, and much more. Without further ado, let’s get into it.
Ricky: Thanks for joining me, Sebastián. I’d like to start with the same questions I do with all my guests: how did you get into programming, and when did you start using Python?
Sebastián: Thanks for having me 😁
I got into coding when I was about fifteen, trying to build a website for my parents’ business. The first actual “code” I wrote was some JavaScript inside an HTML with an alert("Hello World"). I still remember the rush of excitement seeing that little alert message and the powerful feeling of thinking that I had coded it.
I was afraid to learn any other language for years, thinking I had to “at least” master JavaScript first. Several years later, one of the many online courses I was taking at the time required Python for controlling an AI Pac-Man and other things. The course had a single long-page tutorial with just the basics of Python, and that was enough for that course. I really wanted to try it, so I went ahead with just that basic tutorial.
Of course, I rapidly fell in love with Python and wished I had started earlier 😅
Ricky: You’re currently a software developer at Explosion AI, the company behind the popular natural language processing (NLP) framework spaCy. Can you speak a little about what your day-to-day looks like? What interests you about artificial intelligence and machine learning, and what tooling has Explosion AI created to help developers push the boundaries in both fields?
Sebastián: Yep, Explosion is mostly known for spaCy, the open source NLP toolkit. They also created Prodigy, a commercial, scriptable tool for efficiently annotating machine learning datasets. My work has been mainly on Prodigy Teams, a cloud version of Prodigy focused on teams with multiple users. As the product is very privacy-centric, making a teams/cloud version has many particular challenges.
Nevertheless, I recently decided to leave the company. I’m currently (as of the time I’m writing this) finishing all the vacations I had accumulated 😁
My plan is to arrange a way to dedicate a high percentage of my working time to FastAPI, Typer, and the other open source projects, while probably doing some consulting helping other teams and companies to make it all sustainable 🚀
Ricky: People might know you best as the creator of FastAPI, a high-performance web framework for building APIs that has quickly become one of the most popular Python web frameworks. What gave you the inspiration to build it, and what do you have planned for it in the future? And for those that have yet to try FastAPI, why might they choose to use it for their next API over other popular frameworks, such as Flask and Django?
Sebastián: I actually avoided building a new framework for years.
I first learned and used many frameworks, plug-ins, and tools, always improving my workflow (and the workflow of the developers I was leading), while making the products we were building better. And as I worked on startups, always pivoting, creating new products quickly, etc., I had a chance to iterate a lot on that process of finding the “right” workflow and tools, combining existing frameworks with a lot of plug-ins and tools.
At the same time, I also got the chance to work on other areas, like front end with JavaScript, TypeScript, several frameworks, some hybrid apps, some Electron desktop apps, and so forth. And most or all of the projects were very data-centric (data science, machine learning, etc.), so having good ways of communicating data was always important.
By that point, I had many specific features I liked from several frameworks, tools, and even from other languages and ecosystems:
- Autocompletion in the editor
- Automatic error detections in the editor (type checks)
- Code simplicity
- Automatic data validation
- Automatic data conversion (serialization)
- Automatic API documentation
- Support for standards, like OpenAPI for web APIs, OAuth 2.0 for authentication and authorization, and JSON Schema for data documentation
- Dependency injection to simplify the code and improve reuse of utilities
- Good performance/concurrency
But I didn’t have a way to have all those features together at the same time while building web APIs, and the best workflow I had come up with still had pitfalls and caveats. It needed difficult plug-in integrations, obsolete components, undocumented tools, duplicated code, and so on.
But at some point, there was nothing else to try. And that was my cue. I began to study the standards, such as OpenAPI, JSON Schema, OAuth 2.0, and others. And I started to design how I wanted it all to work, first testing on several editors, optimizing the developer experience before writing the actual internal code.
Then I made sure I had the right building blocks for FastAPI: Starlette (for all the web parts) and pydantic (for all the data parts), both with great performance and features. And finally, I got to work implementing those designs based on the standards and the best developer experience I could come up with, plus some extras (like the dependency injection system).
There’s a lot more background about the history, design, and future of FastAPI and also about alternatives, inspiration, and comparisons in the docs. In short, FastAPI was born from the learnings and inspiration from many other tools, API designs, and ideas, and on top of very solid foundations (Starlette and pydantic).
For those that are curious to try it, I suggest checking out just the main page or README and following that mini-tutorial. In fifteen or twenty minutes, you will have a very good idea of how FastAPI works, if you like it or not, and if it would be useful for you.
For those that are already using other frameworks in an existing product, don’t jump to migrate to FastAPI just because it looks shiny. If your product is working well and you don’t need new features, or if you don’t need the benefits of FastAPI, then it might not be worthwhile switching.
Nevertheless, if you want to migrate to FastAPI, it’s actually relatively simple as there are no complex integrations. You can use normal Python packages combined with FastAPI directly, and you can migrate by small parts or create only new components with FastAPI.
Ricky: Typer is a command-line interface (CLI) framework you’ve built that is of a similar vein to FastAPI in that it heavily relies on Python’s typing. I’m noticing a pattern 😉 What is it about typing that you enjoy so much, and do you feel that more libraries should embrace Python’s typing?
Sebastián: Yes, totally! There’s a very powerful pattern there. Type annotations (or type hints) are what power auto-completion and type checks in editors. And these type annotations were invented to serve that purpose. Those two features alone justify using them.
Even more, if it’s in a tool that is expected to be used by other developers, I really wish many Python packages for handling, for example, infrastructure or SaaS clients would adopt type annotations fully. It would improve the lives of their developers so much and make adoption of their tools so much easier.
But now, in the case of pydantic, FastAPI, and Typer, those type annotations already contain a lot of information that can be used to make more powerful tools. They implicitly contain documentation information such as “name is expected to be a string” and “age is expected to be a float.”
That information on the type annotations could also be used for data validation, for example, if the function expects a string but receives a dictionary. That’s an error that could be reported, and if the framework is based on functions receiving parameters, the framework (like FastAPI or Typer) could take care of that.
And then those type annotations can also be used for data serialization. For example, in a URL, everything is a string, and the same is true in the CLI. But if we declare in the type annotations that we want an integer, the framework (FastAPI or Typer) can try to convert a string like "42" from the URL or CLI into an actual integer for our code.
So, then, with a very intuitive and simple fragment of code just declaring a type for a variable, we can suddenly get three extra features (validation, serialization, documentation) on top of the two original ones (auto-completion and type checks). That’s a lot of value extracted from very little coding effort.
And in the great majority of cases, all those features require exactly the same information: “age is an integer.” So, by reusing the same piece of code (the type annotation) to declare that, we can avoid a lot of code duplication. We can keep a single source of truth and avoid future bugs if we decide to change the type in some place (such as for validation) but forget to also update it in some other place (like the documentation).
By having a single type declaration, we can avoid a lot of those errors related to duplicated code that goes out of sync. And those features are what FastAPI and Typer provide.
Ricky: Now that you’ve created very popular modern CLI and web frameworks, what are your plans for the future? Any other projects in the pipeline that you’re excited about?
Sebastián: Oh, yes, I have lots of plans. Maybe too many 😬
There are several features I want to add to FastAPI and Typer. I also want to work on an automatic admin user interface for FastAPI that is independent of database (based on OpenAPI). I want to work on a way to mix pydantic with SQLAlchemy for the use cases that need SQL databases (again, to take advantage of these type annotations and reduce code duplication).
I also want to improve the project generator a lot. I want to improve, simplify, and better document all the utilities around OAuth 2.0, using scopes, authenticating with third parties, and so on.
I also want to, at some point, try to make some videos, possibly a course, and make more content about learning all these things.
Ricky: Now just a few last questions. What else do you get up to in your spare time? What other hobbies and interests do you have aside from Python and programming?
Sebastián: I haven’t been having a lot of time for other things lately, but I hope this will change a bit in the future 😅 When I can, I like to play video games with my wife (or sometimes by myself), watch movies, and go for breakfast or coffee with friends in Berlin (when there’s no pandemic around).
I also really like working on these open source projects, so I can easily spend hours on them during the weekends without noticing it 😁
Thanks a lot for having me! It’s an honor to share this stage with many people that I follow and admire.
Ricky: Thank you for joining me for this interview, Sebastián. It was great talking to you.
If you’d like to get in touch with Sebastián about FastAPI or anything else we’ve talked about today, then you can contact him on Twitter.
If there’s someone in the Python community that you’d like me to interview, then leave a comment below or reach out to me on Twitter.
