Here is a quick recap of the knowledge shared by Sebastián Ramírez, an open-source enthusiast and the creator of FastAPI, Typer, and SQLModel. He has been building products and custom solutions for data and machine learning systems and has led teams of developers around the world.
Hope you enjoy the interview! Let's go.
The Interview
Question: You have an impressive array of interests: frontend development, backend development, DevOps. What do you think about the "full-stack developer" concept, chased after by most tech companies? Is it a reasonable goal for most developers to pursue, or does it have any downsides?
Answer: Thanks! Yes, I’ve had a lot of interests while solving different problems, and I ended up learning several things from different sub-fields (e.g. backend, frontend, machine learning).
I think it’s always useful to have at least some basic knowledge of several areas, but I don’t think everyone has to try and learn everything, as technology is moving fast and the number of possible things to learn is never-ending.
What I would certainly recommend and I try to focus on, is a specific problem that you consider important, and hopefully is important for others as well, and then do the necessary steps to solve it. It might involve learning some additional technologies, but having that objective insight can help a lot in defining what to learn and how deep.
Question: All your flagship projects: FastAPI, Typer, and SQLModel are powered by the new Python-type hints. The latest Python 3.10 release brought even more goodies to the table with PEP-604 union types, which are promptly backported via the __future__ import. What do you think about this new syntax, which can be used even in place of the "Optional" type?
Answer: I love it! Python is getting better and better, every time more convenient to use, editors and tools are on board supporting these new features, and libraries can take advantage of them.
In fact, I have a PR ready where I re-wrote all the FastAPI documentation showing the new and more convenient ways to declare type annotations while showing and explaining what needs to be done in current/older versions of Python. I’ll merge and release it after the next Pydantic release that supports these new features.
Question: You have recently joined Forethought company. Could you tell us a bit about them? How do you combine this work with your consultancy and open-source contributions?
Answer: Yes, Forethought is dedicated to transforming the customer experience space via customer service with human-centered AI. In more technical/explicit terms, it’s a lot of sophisticated machine learning and distributed systems, in particular around natural language processing. This powers several products that improve the customer experience. At Forethought we are using several of my open-source projects, so the company benefits from them. And part of the deal is that I get to spend a high percentage of my working time on these open-source projects.
Additionally, they agreed to have me working with them 3 days a week, that way I can use the extra 2 days to help other teams as an external consultant, or simply do more open-source.
This flexibility and focus on open-source are what convinced me to join Forethought. And the team and products are amazing!
Question: Your FastAPI project is based on extensive research, with a full report available on the project website. What about your new SQLModel project? Are there any projects that you took inspiration from?
Answer: Yes, I have used several ORMs and similar data handling libraries. And I wanted to combine the SQL features from SQLAlchemy with the convenience and simplicity from Pydantic.
That’s basically what SQLModel is, a combination of both SQLAlchemy and Pydantic. The package’s amount of code is actually quite small. The big part of the work was trying many different things and finding the best way to combine both together while keeping compatibility for both. And optimizing the developer experience.
Question: How does it feel to be a maintainer of an open-source project with such popularity? What are your biggest challenges as both FastAPI author and maintainer?
Answer: The task that consumes time the most is actually answering others’ questions in GitHub issues. That’s why I appreciate the help from others so much, helping people with their questions.
Question: The uvicorn web server and Starlette web framework that you use are both based on the new ASGI protocol, which is not yet adopted as a PEP. How stable is the modern ASGI stack compared to the old, battle-tested WSGI? With new async Django and ORMs just around the corner we want to write more async code, but is it a safe bet right now?
Answer: That probably depends on what is considered safe. For example, many banks still have codebases in COBOL because they wouldn’t consider migrating to something else safe.
But by this point, FastAPI is the third most used web framework (from the official Python developer survey), and the third most loved web framework, right above React and Vue.js (from the StackOverflow developer survey), and it’s used by lots of companies already. I would think that would help give some certainty.
On the other hand, although FastAPI is an async framework underneath, it’s also compatible with sync code. If you declare a non-async, normal def function, FastAPI will do the smart thing and run it on a thread pool (thanks to Starlette). So it’s not required to go full async to use FastAPI. In fact, you can even avoid using async and await completely in your code with FastAPI.
To learn a lot more about that, the FastAPI docs have a lot of info about async in a section dedicated to it.
Question: FastAPI was recently included in the latest ThoughtWorks Technology Radar, as one of the technologies that enterprises should start trying out. With 37k GitHub stars supporting this claim, what can be the FastAPI selling points for big companies?
Answer: I would think that for companies and enterprises some of the most compelling features would be: developer speed, to get value faster from the code reduction of bugs, by requiring less code and less duplication, and by harnessing type annotation standards-based, which helps a lot with interoperability with other tools and systems.
There are other features and advantages that can be very interesting for different use cases, but I think those would probably be some interesting ones for companies and enterprises.
Question: All your projects have 100% test coverage. Is it your personal preference or does such high test coverage provide some real advantage?
Answer: Both. It’s personal preference, but it also ensures that all the code is actually run during tests, which increases the probability that everything is properly tested.
On top, most of the tests are run from the examples from the docs. This means that with the tests I can also make sure that most of the examples in the docs work correctly and are properly updated if necessary, keeping the docs up to date. Additionally, if there’s some code section that is not tested, there’s a high chance it is not documented (because most of the tests are run from the docs). That way test coverage also helps me ensure most of the features are correctly documented too.
Question: Last year you tweeted a funny story about not being able to apply for a job requiring 4 years of experience with the technology you created just 1.5 years ago. This tweet really nailed an industry "pain point" and was retweeted all over the internet. How did it feel to be an "internet star" and "meme hero"? Anything worth sharing with our readers?
Answer: It was very fun. I almost didn’t tweet that because I thought it wasn’t funny enough, but at the last moment I said “whatever, let’s tweet it, even if it’s just mildly funny”.
And then for the next couple of days, I couldn’t use the Twitter app on the phone because it would just crash when I opened it with the flow of new notifications.
I also got several thousand new followers on Twitter from that, and also LinkedIn connection requests. It’s also a bit ironic, I’ve made several open-source tools that seem to be useful, but the highlight of what I’ve done on Twitter was a “mildly fun” tweet.
Question: FastAPI is one of the fastest Python frameworks out there, being referenced as "Flask-like simplicity, Django-like batteries, Go-like performance". Developers like to benchmark things, but is it really important to have such outstanding performance, while the bottleneck is often in the database access or business logic code? As a consultant, how often do you meet framework-induced performance bottlenecks?
Answer: I think it’s useful to be able to get performance in the ballpark of the best possible. But in many cases optimizing that from the beginning is premature optimization. In most cases it’s better to optimize building the product, making sure it works correctly, and getting it out there to the public.
Then, after measuring it, you can optimize the places that require it, making sure to use async code properly, etc. But you can do that just for the endpoints that really need the performance boost.
I like that FastAPI can have good performance, but there are other things that I like a lot more and that help build products fast and safe, like autocompletion and inline errors everywhere, automatic data validation, automatic API documentation without any extra effort, etc.
Question: Microsoft recently brought autocompletion to a new level with their "GitHub Copilot" AI-based service. What do you think about it? Can this be the future of software development or can we see any obvious downsides right now?
Answer: I got access to the preview about a month before it was publicly announced and I was mind-blown. It helps a lot, in particular with repetitive tasks. For example, while writing tests, you can create a data structure for the tests, and it can use that information to autocomplete the assert statements. But of course, you have to check and confirm that the code is correct. So, if it is autocompleting a very big chunk of code for a complex task, in many cases it’s faster for me to write it myself than to review what it is writing, paying special attention to any possible small mistake.
It can’t replace our work, but the same way keyboards and laptops can help us write code a lot faster than working with punched cards, it is a tool that can help us be more efficient.
Question: You have had numerous talks at technology conferences during past years, both offline and online. How is the new "online-first" experience different from the good old in-person meetups and afterparties?
Answer: The advantage of online conferences is that many people from around the world can participate and watch. But probably the best value you can get from tech conferences is from the live interactions. It’s also normally more rewarding giving talks live, at least I can see if people smiled with the memes in the slides.
Question: RealPython is one of the best places to learn Python, and you recently contributed the article here. What's their secret? Why are their articles so good and is it somehow related to your project's documentation also being exceptionally good? Do you all have some secrets on "how to write on tech topics" courses?
Answer: Yes, they have great material. They also have a very rigorous editing process, and very strict rules and processes to preserve their own defined style.
Some time ago I gave a talk about “Tips from FastAPI and Typer for other developer tools” including a bunch of tips about docs. I should probably write a post about it too.
Question: The demand for software developers is so huge that we have "Become a programmer in 3 months" courses right now. What do you think about the need for proper Computer Science education for new developers? Do we really need it now?
Answer: I think what’s most important is to focus on solving a problem.
At some point, it’s useful to get some knowledge about algorithms and algorithm analysis, cryptography, databases, and their internals, etc. but there’s a lot that can be achieved before getting too deep into technical concepts. And when it is necessary, there are great online courses about those topics, even from the top universities and professors around the world.
Question: If you could change one thing in FastAPI without having to care about backward compatibility, what would it be?
Answer: That’s a good question. I actually don’t have something that I strongly regret in FastAPI.
At some point when I have all (or most of) the features and docs I want for FastAPI, and before releasing the first 1.0.0 version, I’ll probably make some small updates to internal parts (that people probably wouldn’t be using anyway). That could be a breaking change if people are using internal parts, but that will also help me see what internal parts are needed publicly, etc. It would be mostly internal cleanup, but nothing drastic.
Comments