I am Sebastian Ramirez, or Tiangolo. I am the creator of FastAPI and now the founder of FastAPI Labs, this new company. I drink my coffee as a cappuccino, and I drink a lot of it. Welcome back to the MLOps Community Podcast. I'm your host, Dimitrios, and today we've got the mustache man himself, Mr. Tiangolo. Hello.
aka the creator of FastAPI, which I am sure a few of you use and love. We talked all about developer experience when building software. We also talked about how he thinks through abstractions. Let's just get right into this conversation because I had a blast with my amigo, Mr. Sebastian. You know what I want to tell the listeners? I want to start with
The fact that we did a hackathon and the winners of that hackathon were from Colombia. Oh, right, right. I forgot that that was so fun. We were the judges. And the funniest part was you're from Colombia. The winners were from Colombia. Afterwards, we're making all kinds of jokes like they paid off the judges. Yeah, yeah, yeah. What is this?
Because the thing that they came up with was quite cool, but I felt like I am Colombian. I cannot vote on this. And I just like, you know, like hands off, like the other two judges, you decide that I can't. You had too much honor. But I also remember that when we were just hanging out and everybody was hacking, somebody, you were talking to somebody and for some reason,
Pydantic came up and they didn't know what Pydantic was and you looked at them like, "You don't know what Pydantic is? Oh, let me tell you all about it." So why do you love Pydantic so much? Pydantic, I think Pydantic is so cool. The thing is Pydantic made it super simple to validate data and to get auto-completion and linear errors for the data that you're handling in code.
The funny thing is, before Bydantic was as widely known as it is right now, it was like a library for doing data validation, but it was not as obvious, I would think, that you need to do data validation, that you need to validate the data, you need to structure it properly, serialize it, convert it, document it. It's not something that is obvious anymore.
And there's a lot of code that goes, you know, like just wasted on doing custom validations. Just because, you know, like if you don't know that there's that option, you end up just like writing a lot of code just to check if it's actually an integer or not. Or maybe this one is a JSON object or like, I don't know. So I thought that Pydantic was amazing doing that. It was just not as obvious that you will get so much benefit from it.
For FastAPI, it was the key component for doing all the data validation, serialization, parsing documentation, all that stuff, and to make it super simple and super intuitive. And I guess that's also why it sort of helped Avid show, hey, Pydantic is here. You can use it for these types of things. And then I think people slowly got the hang of it and started using it for more things.
But I think it actually took a bit for people to start exploring Pydantic in many other ways. I remember I was like that at that moment. I was pitching Pydantic for everything because I was doing all the data processing with Pydantic. I have a bunch of custom GitHub actions that are pretty much just a Pydantic model that extracts the data from the environment variables and just gives me the right data, and then the call is super simple afterwards.
And it actually doesn't even involve FastAPI or anything. It's just like pure Pydantic. So like, yeah, I think it's a great tool. You were super early on that trend. And so it feels like you saw around the corner a bit and you incorporated into FastAPI, right? Yeah. Yeah. So the thing is, I was looking to build something that was similar to the other tools that I was using. But by that point, I realized that I wanted to have
the best developer experience possible, and that will need to take advantage of type annotations. And type annotations were just super new. They were for a year or something. So there was no tool that was using type annotations, at least not properly. And Pydantic was, I think, the only one that was using them at the time.
Apart from data classes, that was in the standard library. But data classes doesn't do any data validations, realizations, transformations. But it's sort of the same style. And I was looking for a tool that will do things like that. I was just seeing, by then, there was a previous tool called Marshmallow. And Marshmallow was great. It's just that it was the same before we had type annotations. So that didn't have a way to exploit them.
I was trying to look for something like that, that will be based on type annotations. So I already had my mind set on what I needed. And then I found Python. I was like, okay, this is the right thing.
But the Pydantic docs were mainly focused about managing settings and handling settings for applications. And we're like, okay, but is this... So I was like, you know, like, is this actually what I need or not? But then, like, I kept digging deeper and then I found out, yeah, this is exactly what I need. It's just that...
it's probably not obvious that it could be perfect for all these other use cases. So yeah, just like started just exploiting it and nagging Samuel with, hey, here's another PR. Yeah, Samuel, that's awesome. He's been so good and they're great shepherds for that whole community. It's cool to see Pydantic. And like you said, how it had this lagging effect, but now it feels like it is very much at the forefront.
and people understand the value in it thanks to, I think in part, a lot of what you did with FastAPI.
Nice. You know, like that's an honor for me to think that I helped people to get to know Pydantic. And now Pydantic is also using like everywhere, you know, like all the major LLM providers or SDKs or tools. They are all based, built on top of Pydantic. And that's amazing because I think it's like, yeah, it's an amazing building block for everything that we build on top of.
So there's two things that I wanted to talk about from our last conversation, which was, I think, like three years ago till now that I swore to myself, if we end up talking again, I have to ask you about these things. The first one is I got a little bit of flack back in the day because I didn't ask you about your stint in ML.
Folks were like, yeah, but Sebastian's done ML stuff. And you guys didn't talk at all about that in the podcast. So can you break down the ML stuff that you did and give us a bit of, I think you're like an undercover ML slash AI guy where you're masquerading with the FastAPI. But was FastAPI built for ML?
And now use case? Yeah, exactly. You got me. So I got into Python to do AI and ML. That's why I got into Python. It was a requisite in an AI course from Edex, from Berkeley, like, I don't know, 10, 12 years ago. All of them. Yeah. Yeah.
That's how I got into Python. Then I started working and I was doing stuff with computer vision. And then it was computer vision without deep learning, without neural networks. It was just like, you know, like...
very complex algorithms and like SIFT and like then matching stuff and like Kalman filters and like a bunch of stuff that was super sophisticated, complicated and difficult to get like, you know, like great results with it. And then like, you know, now you can just like put deep neural networks on top and like get a lot of value without, you know, like without having to fiddle so much. It's amazing.
But yeah, I got into that and I took a bunch of, I took a lot of online courses, but like I had like a big inclination towards machine learning and AI. And then FastAPI came from that. And then, yeah. So like I started working at a company, we were doing like machine learning stuff and it was things related to that. But we always had to build applications. I mean, in all the cases we needed to build an API on top of things.
So I kept struggling and kept stumbling in the issues of building an API with the tools that I had at hand. And I figured that this was one of the things, one of the patterns that was just repeating over and over and one of the things that had to be solved over and over. And I didn't find a great solution and something that would work well. And I found something that would sort of work and I figured out how to make it work, but it was so complicated. And like, you know, like,
It was difficult, and then the team that I was working with, they were all struggling, and it was like, yeah, this is just copy-paste whatever Sebastian did, and it works. And free. Yeah, it's not the best developer experience. So continuing in that path, I was using that setup for quite a while, but I kept just investigating and researching different frameworks and things until I ended up in FastAPI, and then I just got stuck.
in apis but like i i got into python because i was gonna do ai and mm you missed the train on that one you were super early and then you went down the api rabbit hole and ended up powering half the internet that's amazing that's that's a crazy it's like you know like it's uh it's something that makes me uh very what proud and humble and like everything at the same time to see so many ai applications and like you know like
Many of the, you know, like top voices and like top opinion leaders in AI liking and using FastAPI, for me, that's, you know, that's mind-blowing. Well, I remember you telling us that one of the bigger ones that you had heard was using it was like NASA and they were powering spaceships or something along those lines. And that blew my mind, just like there are some
Really cool use cases. And of course there are because you use APIs for everything. So it's not like it's not contained in that way. You can use APIs wherever. And like you said, your commitment to the developer experience has been, I think, what makes FastAPI shine. And so the second thing that I wanted to ask you about was what I also got flack for,
in the last time that we had a conversation. And that was people saying, why didn't you ask him why there's so many damn emojis in the docs? And this is pre-ChatGPT. You were very early on that trend also. Yeah, that's funny. Like, you know, at some point, I don't know how much you go into Reddit. I now try to avoid it because in many cases it's a dark place. It's a very dark place.
At some point, I remember there was some conversation in one of these Reddit or like, I don't know, Fast API or Python or something. And someone was saying like, oh, no, couldn't trust Fast API. Like, you know, like, oh, no, cannot trust. Like, it's a single guy. Like, how can you trust them? Like, you know, like people don't realize that most of the open source projects they use are built by a single guy or a couple of people.
Even if they are big corporations, this is still mostly one or two people for most of the open source projects. But anyway, they were saying, no, no, how can you trust a single guy and blah? One of them said, well, but why wouldn't you trust this guy? Or why do you say he's a psychopath or something? And the guy said, he clearly does very hard drugs.
Like, what? How do you know? And it's because of the emojis. It's all the emojis. It gives it all away. Yeah, yeah. That's what tells that, like, I do very hard drugs. Like, well, I do lots of coffee. Maybe that counts. Yeah.
Oh, man, that is the best Reddit thread. We'll have to try and find that one to showcase to people because, yeah, that's the Internet for you. That's what you can expect when you gain a certain amount of notoriety. You're going to get that type of random speculation. But it's fun. You know, like the point is, I guess.
Well, after a while. At first, it's like, oh, you know, like you feel weird and like maybe like attacked or like did I do something wrong or it's like something bad or something. But then like after a while, you realize that the bigger the scope of the impact that you can have,
the higher chance that you're going to have some random person just nagging about random stuff that doesn't really make that much sense. So I guess... It's the blue guy. Yeah, trying to take it as a compliment, I guess. You know, like when someone criticizes you so badly, it's like...
How could we get to this point? You know, like I'm a random person in the other side of the world on the Internet. How could this person hate me so, so much? For the emojis that you use in the docs. So, yeah, I don't know. I have also had like a few reports. I think like more than, it's more than one, two, three of saying like, hey, the FastAPI docs have been hacked.
because it's all full of emojis. It's just that they put the URL run because there's a version. So FastAPI is translated to a few languages. And one of those languages is emoji.
It was just an April Fool's joke. And it just stuck and it's still there. And you can find the whole documentation written in emojis. Wow. And it was actually done by other people. It was not done by me. It was done by a few other people. And I think that's the PR with the most approvals I have had in Fast ATI.
So when people get to like, you know, like Easter eggs and April Fool's jokes, like they really go hardcore on that. So that's still there. But then occasionally people bump into a URL with the emoji prefix and they just see everything in emoji and like, oh no, it was hacked. And then they tag me on Twitter. It's like, yeah, no, you're in the wrong language. Incredible, dude. That is so funny to think about. Well, there's the other piece that,
I just can't stop thinking about the emojis part and how much controversy emojis cause for basically nothing. I also get that way when I...
play guitar in our virtual conferences or in our i used to do guitar intros for the virtual events and we threw them up on youtube and i'll tell you what some people on youtube uh they've got some creative ways of talking shit and i was the same way as you where i would just think damn
I am honored in a way because they took the time out of their day to talk shit. And I guess I could feel a little bit ashamed here, but nah, I'm going to take it as a compliment as opposed to a threat or just dissing me. So anyway, the thing that I wanted to talk to you about too, you...
have started a new company. You also got some funding from Sequoia, I heard or I saw. And I know that for the last year or so, you were doing something really cool that Sequoia was sponsoring, which was like they were, it was almost like this entrepreneur in residence, but it wasn't. So maybe you can break down what you were doing and then why you finally landed on Sequoia.
fast API cloud or the pro version of fast API, because I know that back in the day when we had a meetup and then we went out after the meetup in Berlin, people were like, oh, so you're going to start a company. You're going to do something around fast API. And you were like, I don't think so. I don't know. Maybe we'll see. I'm open. But that was also like four years ago. So obviously a lot's changed. Give me the breakdown and the lead up to this.
You know, like I remember in that conversation after the meetup, one of the guys came and said like, okay, so are you going to work like full time on that or not? Because at that point, I still wasn't working full time on FastAPI. Yeah, you had a job. I forgot. I think I had a part time job and I asked them to do it part time because I wanted to spend more time on open source.
And he said, I remember this guy said like, hey, are you working full-time fast API? Like, no, but like, yeah, you know, like I don't have a product or something. Why don't you start the company? No, yeah. And I remember he said like, you should, you should start a company or do something and build something for open source because we all need it. Like, you know, like...
We all benefit from that and it will be a shame if we cannot get like more of that. You know, like it was something around those lines and it was like, oh, that's shit. That's so, you know, makes you feel well, on one hand, super appreciated. On the other hand, it's sort of almost a responsibility of like, you know, like this is something that is being so useful to people and I get the chance and the power to do
help many more people by just improving it was like something that you sort of gotta do right so yeah it was i remember i remember that mode that point and that moment and that guy i think i remember who you're talking about and that guy because i i remember distinctly being at the bar when we were talking and he was telling me like dude yeah like maybe you could start a
course or maybe you could do something with this community like certificates and i looked at you and i was like yeah and maybe you could like start a course too or uh like a newsletter and he looked and he was like this is sebastian he started fast api he's not starting a course he's got a company to go start and i was like okay dude thanks for like that backhanded compliment
I was laughing so hard. I can't remember what that guy's name was, but I'm going to go find him and we'll have some laughs together. But anyway, so then you had that pressure put on you. Yeah, but then after that, I don't know if it was like the next year or one year after, I don't remember. It was probably one after that. It was in 2023, Sequoia started the open source fellowship. So it was like this sort of...
It was a steep end to cover my expenses, so I would just work full-time on open source. I think during that time is that we had the hackathon that I was helping judge and that stuff. But that was because that was after the previous event. And you weren't getting paid, right? I remember you telling me that you had the option to donate.
on the GitHub page, but the sponsors of FastAPI, it wasn't like enough for you to live off of. Yeah, yeah. And you know, like this is quite fun is that like people come and sometimes people come and sponsor and they get like, you know, like a couple of bucks, five bucks a month, 10, something like that. And it's like super, you know, like I appreciate it a lot and it's like, it feels very encouraging.
But with that, it's very difficult to make a sustainable income because you get like, you know, like you get a hundred and a hundred people putting five bucks a month is 500 bucks a month. It's not...
enough to live off. Then the ones that put the most are the ones that get something in exchange, like a badge in the dogs or like consultancy time or things like that. But then in the end, it's sort of a transaction that, you know, like
You're giving something extra for them to give you something back. And sometimes, you know, like it's also difficult for companies to justify giving money to, I don't know, to sponsor open source stuff without having something in exchange to show finance and to show the investors and like all the stuff.
It's, yeah, I guess it's like, it's difficult to balance. There are some things like, for example, the open source pledge now, I think that's amazing. From those started from the people from Sentry and also people from Astral and Pydantic joined and like a few other companies joined there. That they are, you know, like committing to give, I don't remember, a certain amount of open source per employee they have. Some certain amount of open source a year or something like that.
But the thing is that, you know, like the open source sponsorships are normally not super, super meaningful necessarily, at least not for the majority of projects. So it's like, it's something. But in the end, it's also sort of a service or a product or transaction that you have to give away something. It's like a badge in the dogs or something like that.
But yeah, with the Open Source Fellowship, they will cover my expenses and then I will be able to just go full time on open source. They will ask every once in a while, hey, what do you think about this company? But that was like, I don't know, like four times in a year or something like that. So it was very little. It was actually just mainly focused on your open source.
And it was also not like, you know, like here's a project manager. You have to work on these issues or you have to do this or that. It was just like, you do your thing. We just trust you. Go and build your stuff. You know what to do. Just go and do it. So it was super useful because I was able to work and like tackle very difficult things that required a lot of continuous focus time.
and that the results and the value will be seen only after it was completely done. So for example, migrating or like supporting in FastAPI, supporting Pydantic version 2.
FastAPI currently supports both version one and version two, depending on whichever is the one that you installed, FastAPI supports that one. So those people can do the migration on that. But then getting that, doing that, getting to that point required a lot of work. And it's something that will have been very difficult to do if you just put one or two hours in the night and then a bit during the weekend. It's very difficult to keep the pace and keep the context. So that was amazing.
You'd still be working on it. Yeah. That was the open source fellowship. That was 2023. By the end of 2023, I was seeing there were like, you know, like companies trying to build a cloud for FastAPI, cloud for Pyth and trying to get like that feature, trying to get that going. Like, why would someone else build it? And why wouldn't I build it?
because on one hand I could make sure that it has like you know like the best developer experience for fast api because I am the first user of fast api I built fast api for myself to use it myself and then like building a cloud I'm building it for myself I'm just like it's just self-satisfaction that everyone gets to enjoy but like you know like I'm building it for myself as I want it to exist and then
It's also like, you know, like the community is already there and I can make it super simple to integrate it with FastAPI to make it easy to integrate FastAPI. And I can also ensure that, you know, like FastAPI is being, which is something that is super important to me, that FastAPI is being open source, fully open source with all the features like you can deploy wherever you want, however you want.
I'm just going to make sure that you have an amazing developer experience with FastAPI Cloud. So you want to try FastAPI Cloud and stay there. But like, you know, like it's still, you can use it however you want to use it.
It made sense and it was also like, you know, like there's a chance also to if there are some fruits that could be taken out of like all the work I put over the years on the open source, I would like to take a piece of that at least. So like, yeah, that made sense as well. And figuring out a way, a sustainable way to have a funding for the open source projects.
And that was something that I have been trying to figure out how to do for years. And the open source fellowship was great, but it's not something that I can feel like, oh, I'm going to just stay here forever in the open source fellowship. They probably wouldn't want to just pay me forever just to stay there. They were willing to extend it, but it was like...
you know, I should probably make something that makes sure that all this stuff keeps working. And so that I can also work on a, and I get people to work on the open source projects, fast API, type, SQL model, async, like all the stuff that I built that is already there. So it was like, you know, like just the balance of everything together. You can't rely on the goodwill
indefinitely. You have to at some point figure out what is a more sustainable way. And this feels like it was a great bridge from not you were you were moonlighting on this to then it became your full time thing.
And now you have this sustainable way of keeping it your full-time thing. Yep. And so that makes a ton of sense. I want to go into the difference or what you get with FastAPI Cloud and how you think about which features or what parts go towards the open source versus what parts now go towards the company and also everything around that decision making. Yeah.
This is actually, this is something that I gave a lot of thought to. Building a cloud was not like, you know, like I was not trying to build a cloud. That felt like daunting and it was daunting. It's been like a lot of work that we have been doing. And it was like, can't I make, you know, like a simple product or something? But every time I came up with something, it would just make sense to make it open source. Typers, SQL model, a thinker. It was like, yeah, well, this has to be open source.
Building a cloud was daunting, was a lot of work, and I required a team and I required resources. But it had this very nice detail, this characteristic that the overlap and the conflict of interest between the open source and the cloud are huge.
are minimal. You know, like you have the open source is this way and then the cloud goes this other way and it's just like they just cross each other. But the open source, it doesn't really affect that much. In fact, it actually aligns quite well. If FastAPI is even better, you get more features, you can do more stuff with FastAPI, there's a higher chance that you will want to just use FastAPI in general. And if you use FastAPI in general, there's a higher chance that you at some point will want to try FastAPI Cloud and
try out the service. So, you know, like it just made sense to do something that had the least friction possible with all the open source because it also simplifies all that
conflict and that sort of process of what goes in the pro version and what is the core and what is the... Now, FastAPI is all pro. You get the pro for free. And if you want to deploy in FastAPI Cloud, you could just deploy to FastAPI Cloud. But the open source thing is just like you get all the features that are there and all the new features that we will build. Like all the new stuff that we will make sure
the FastAPI is just as good as it can be, and we keep improving on that, then you will be able to just reap those benefits no matter how you deploy it.
Then on the other side, we can make sure that deploying on FastAPI Cloud is just the best developer experience ever. It has like, you know, like the most robust and resilient way to deploy things that you get something that is just instant there. Like you don't have to think or figure out or like, you know, like tweak a bunch of configs and debug errors in other languages. And, you know, like all that process is, it's a lot, right?
You've been through it. Yeah. Yeah. Which is also the reason why I realized and I decided that it was a good idea to build a cloud product. Before that, I was very much on the side of just learn to build everything yourself and just like, you know, like install the Linux machines yourselves and just like build and set up the cluster yourself and just like deploy your things there.
And actually, I had one of the most prominent websites for explaining how to use an alternative to Docker that was created by... Sorry, an alternative to Kubernetes that was created by Docker. It was called Docker Swarm, Docker Swarm Mode. Yeah. And it was a great product. It was quite lean. But in the end, it didn't work out for them, and they sold it to another company that put that...
under their Kubernetes umbrella. So like, you know, Kubernetes won one way or another. But then Kubernetes is just massive. It's a beast. And just getting to learn Kubernetes, getting to use it, getting to manage it, and you just do it and then you're just scratching the surface. It's just a lot, a lot of work. So, you know, like seeing that and seeing that I...
Before that, I could tell people, hey, just go and install this other thing and then you're good to go. You have the first version that is working in a week, in a couple of days. But then if I tell them, well, you have your FastAPI app, now go learn Kubernetes for six months or try one product or the other or maybe this one will work less.
That was not a great story. So that also convinced me, like, it probably makes sense to have something that is dedicated to this type of application and to make it super simple for people to deploy FastAPI application and being able to just focus on the code and the product and not on all the nuances of deployments. Yeah, so...
everything fit together and match to that point to say like, yeah, well, this is probably the best way to go. This is the way that I can have the biggest impact in people's code and the things that they can achieve and the things that they can do and build to help others on the open source and also on the product and like everything together. So, yeah.
You remind me of the founder of that company called, I think it's Base 10 or Base Camp. No, Base Camp is what it is. And they, I have heard a few podcasts with him on it. And he talks about how when he sees or uses
poorly designed or just not the best thought out software, it drives him crazy. And so crazy that he has started a few different companies to combat poorly designed software. And I think one of them was even a parking garage.
lot software that his HOA or his condominium complex used. And he hated it so much, he just went and created a new one, if I'm getting that correct. And it reminds me of you kind of, you go through and you say, wow, this developer experience is painful. And then you
I'm sure there is a long period of time where you sit with it being painful and it like continues to be painful, but it eats away at your soul in a way that for some of us, we just put up with it. But for you, you're like, I'm going to have to go and create a product around this. Yeah, maybe, maybe it's a bit like that. Like, yeah, I don't know. And like, you know, like there are many tools that are just great, but they are also...
super complex or like dealing with a lot of nuances and it's just like some layer of abstraction and then sometimes you just having to deal with that is like it's so complex like you know like if you had to go and buy the motor and the tires and the doors to finally assemble your own car it's like that's just too much you just go and buy a car
Yeah. So, yeah. And I think in many cases, it doesn't really make sense to assemble your own cars when your business is not assembling cars. Your business is doing something to ride them or maybe not even riding them. Maybe you just need them to be able to get something across. But you need a car to be able to do that. And like, yeah, like I feel for many, many use cases, being able to just like get the car and like not having to deal with that makes total sense.
Yeah, you don't even need to create an Uber or you're not even an Uber driver using your car every day. It's just that you're getting in a car and it's taking you from point A to point B. I like that metaphor because at the end of the day, everybody needs to use a car or use an API in their software that they're building. And so how can you make that the least friction-free
or the easiest for getting that outcome that someone is looking for. Yeah, exactly. And you know, like that was the spirit of FastAPI. How can you make it so that you just write the code in the way that will be the most intuitive to you, and then it does the right thing and does all the stuff that you need it to do underneath by default. Data validation, documentation, everything is just done by default.
and it just gets out of the way. So you can focus on your code. When you see a FastAPI application,
the amount of fast API code is minimal. It mostly is just like the actual code of the business logic. That is the idea to try to make it super simple to use the tool and, you know, like to do not get in the way of building the thing that you need to build. Since we talked last too, I have been thinking a lot because I think in our first conversation, we hit upon the point of how you look at
what abstraction layer to play on and where that decision is made or how you think about making that decision. It's only become more relevant since the new LLM boom.
Because of all these new tools that are coming out and trying to abstract away different pieces of the LLM API calls, or maybe it's the orchestration, or maybe it is something around the system when you're building with AI. Have you thought, not necessarily about the abstraction for the AI systems, but what is your way of going about
these abstractions and thinking through what would be the best abstraction here do you sometimes create an abstraction and then roll it back and say actually no no no is it something that you're working with and it slowly is boiling in your mind and you then all of a sudden have a eureka moment what does that look like
That's actually a very interesting question because, like, you know, I do think about that a lot, but I don't get asked about that often. I think it's more of like, you know, like it's boiling in the background and I'm trying to figure out what is the right way and just like struggling with it. And then at some point I realized and figured like, yeah, it makes sense. And it's fun that I think about that a lot for the stuff that I build.
And the same, you know, like with FastAPI, Typer, SQL Model, Asynchr, and also the FastAPI Cloud product, for all of them, I avoided building them for a long time. For FastAPI, I was trying not to build something. I was looking for other tools. I'm like, what was already there that could do what I wanted? For the company, I was, you know, like, I had been told like, oh, you should start a company for a few years. Yeah. Like, there were like,
I had like, yeah, a few people that were interested in me building a company. And like it was, yeah, no, I don't think so. I don't have like a right product. It's not, I don't have something that will be the right abstraction to build. But then, and this is the key point. This is how I think about it. When you, when the new abstraction that you could build, learning and using that new abstraction for your users, for your final users, when learning that,
is much less effort than they will have to put to learn the underlying thing. So, you know, like for them to use your tool, for them to use FastAPI, the effort, they have to put some effort into reading the docs, into learning how to write the code for FastAPI, into learning how to do that. But if they didn't put that effort, they will have to put
an order of magnitude more effort into learning how to do everything by hand or more you know like orders of magnitude so when you hit that point where it's like okay if instead of learning all the underlying stuff people could learn a small layer in between in the middle and by learning that they just save so much effort in learning and debugging and using
whatever it is that goes underneath, then that's the point when it makes sense. And it's also when there's no abstraction that is already doing that. Because in some cases, people go and build another tool or build another framework or something, but it's like, this is doing pretty much the same that this other thing is already doing. So it's not necessarily that viable, but when you see repeatedly that
So my level of abstraction is not managing to be met, you know, like having something that is super simple and intuitive to use that you just have to learn a very minimal thing to get a lot of value. And yeah, that's the point when I say like, OK, it makes sense.
That's the point with FastAPI, that's how it happened. I was actually going to start contributing to another framework and the author said, "No, I cannot really keep working on this. I'm going to deprecate this. I'm going to focus on something else." This was Tom Christie, the author of Django Rest Framework, the author of API Star, which was sort of the spiritual predecessor of FastAPI.
And then he started Starlet, which is the building log for FastAPI. And then he said, I cannot keep working on this other framework that was called API Star. Then I said, like, okay, this is the last notch. I'm going to jump into it and try to build FastAPI.
Similar with SQL model. There were some other tools that were trying to build an ORM that was based on type annotations and Pydantic. But none of them were managing to hit the sweet spots that I wanted subjectively. But the things that I wanted it to do, the way that I expected it to do,
Taking into account how type annotations work, how default values work, how to completion inline errors, all these things that are just very tightly coupled to the developer experience.
And they were not really managing to get to that point. And he was like, okay, I have to build this new tool, this SQL model tool. And he was, I really don't want to do it because handling databases on SQL is so difficult. But he was like, you know, like, I just have to do it because I have these ideas that are there. They are going to be useful. I just have to go and, you know, like buy the bullet and build it. The same with the cloud. Yeah.
You know, like learning all the Kubernetes stuff and learning all the cloud products from the big cloud providers and all that is just so much work. And it's just so... There's so much impedance mismatch between different tools that you have to figure out some weird way to monkey patch things to make things work and be always careful with how those things evolve so you can update the monkey patch. You know, like...
That's how the cloud is built. It's not ours. It's everyone's cloud. That's how it's all built. The secret. Spoiler alert. Yeah, yeah. That's how every cloud is built. It's just like a lot of things just like, you know, it's just tape everywhere, putting everything together. And then having to deal with that is just so much work and so much effort.
And then when the, you know, like it was the point that like, yeah, no, like actually if you want to deploy something, you just should go and learn one of these giant products or Kubernetes or Kubernetes on top of them or some cloud provider. There are several cloud providers that are quite good. They are doing a job at abstracting things, layer a little bit above the, you know, like the raw stuff. And they are quite good, but they are still quite general or generic for products.
trying to be like, you know, like generic for every framework and for every language, for everything. So it's always like this little friction of like, how do you do this for FastAPI? How do you make this thing work? That was the thing that I felt like it makes sense to have something that just works. Yeah, for FastAPI. Plug it in, yeah. It's part engineer, part
taste, how I hear it. Because when you're thinking through these problems, you're really stewing on them. But you're also looking at what's going to be the most efficient and then what is going to be the most tasteful way or that developer experience side of things really makes me
realize that you're thinking through not only, hey, this is the best way of doing it. It is, this is the most developer friendly way of doing it. And even if it may or may not be the best way, because
There probably are potentially better ways that you could do something throughout each step. But then that adds that extra complexity that you don't need in the mix. Yeah, yeah, exactly, exactly. And the funny thing is that it feels a lot like taste and like an art and not a science. And like, it feels like, oh, it's just like, you know, like very good taste or something. But it's actually not.
a giant list of specific tips but you know just like knowing all that by heart just helps a lot to see like this doesn't make sense but it's not it doesn't make sense because it smells weird or like you know like I feel it doesn't have a good bite no yeah it's normally a
a very specific thing. It's like, if you define the imports in this way, people, you final users are going to have to import from very different places and they will know what they will need to import. So better to define them this other way. But saying all that long phrase is longer than saying like, it's probably better this way. You know? So it's a lot of, I think it's just a lot of that, which is like, you know, it's a funny thing. I feel it's quite funny that
several of the automatic SDK providers, so the people that generate the SDKs for the big LLM providers like OpenAI and several others. Well,
OpenAI, Anthropic, and I can't remember most of them, they are building the SDKs, the Python SDKs, well, like the several languages SDKs based on OpenAPI, which is the thing that FastAPI is based on. Many of these big providers are actually using FastAPI underneath and they get like a nice OpenAPI as a result. But then many of these SDKs, they have like, okay, what is the right way to build this in Python? And I ended up having conversations with several of them and saying like,
The right way is like doing this. So for example, using, you know, like this is one of those things that is sounds like taste, which is actually a very specific set of things that work. If you define the parameters of your functions as typed dicts, then instead of pydantic modes, the parameters of the functions, the input parameters of the functions, if you are building an SDK.
as type dicts, then the editor will be able to provide autocompletion and inline errors for the parameters that the users are providing without the users having to import some additional model, without them having to import anything. They just start curly braces and they start getting autocompletion. And then if the outputs of those functions are pydantic models, then users are going to have autocompletion when they try to get an attribute or things like that. Two for one deal.
Yeah, so it's like, you know, like it's just like that specific combination of use this here, use that there. This works this way, this works the other way. Like use this tool underneath and like that should get you going. That ends up helping a lot. And then in the end, most of these SDK providers are using exactly that recipe that I think I told them at some point. At least a few of them, I told them like, hey, you can do it this way. I don't know if some of the others like came up with it on their own. But like, you know, it's just like just those tips, those tips
Tiny ideas of...
Just having explored a bunch of that and trying to get that best developer experience after using it as a final user. I think that is the main point. Just using something as a final user and trying to improve that own experience constantly. But when you say explored, do you mean that you've tried to put a certain rule in place and then you've played around with it and you've said, eh...
maybe this isn't good or maybe it could be a little bit better if we also do this. And so you're adding on top of it or you're adding something and then taking it back. Yes. So it's actually both. Me as a consumer of code and other libraries, when I use them and I feel like this is not great, like why don't I get autocompletion here? Now, by this point, I know how autocompletion works internally. So I know what they are doing wrong in their code.
And if I had infinite time, I would go on Maple requests to everything. But in many cases, I see something and it's like, ah. Wait, wait, wait. You're like Batman for open source packages. You go and get the autocomplete man. They submit the PR. I could be autocomplete man. That should be my Halloween costume. Yeah.
You're saving the Gotham City of GitHub. GitHub's Gotham City. That is classic. Control space. Yeah. Keep going though. So it's like one thing is just like using different tools and figuring out like how it feels to use them and then trying to figure out what will feel better if I use them this way or the other way. That's one thing.
And the other thing is when building a tool, when building a library or a product or whatever,
And this actually applies to anyone that is building anything. If you put yourself in the shoes of whoever is going to be the final user, it's much easier to optimize that experience for the final user, to optimize and to make sure that you are doing something that works well for that final user. If you are not the final user, it's much more difficult. Then you have to hire someone that is like, you know, like...
breathing on your neck checking that what you are building is actually useful because otherwise you end up building something that is not useful for the final user and then no one uses it and it doesn't really solve an actual problem. As an example, when I was building SQL model
This was fun because I didn't start writing all the code and then like, okay, now let's try documentation. I started with the documentation. So it was like sort of documentation-driven development. So I started writing the documentation, explaining how this should work, and then trying to write the examples in a way that should be easy to understand and easy to work with.
and then figuring out what do I have to do in the code to make this work. And then like, you know, like going in the opposite direction, just from the, what is the final result? And how do I make this final result actually work? And in some cases, I remember there was like one or two points where I have a feature somewhere in SQL model that will let you do something and you will be able to do that same thing
in three or four different ways. Like you could set this parameter here, or you could also set it here, or you could also set it in this other place, or conditionally this and that. And it was like, you know, like it was very easy to implement. But then I realized explaining this is just so complicated because if this happened, then this, if this other thing happens, then the other. But if you try this, so the priority of the parameter is this one, you know, like it was such a long piece of content.
That was going to be so difficult for people to understand. And then it was going to be difficult to use. If it's something that is difficult to understand, it's going to be difficult to use. You know, like it just has to be simple and intuitive. And then that was the point, like I figured like, okay, I'm going to forbid these other three options that are already there, already implemented for free. But I'm going to forbid them because they just, they are just going to complicate things when I try to explain them. It detracts.
Yeah, so it's like, I think it's a bit of that, of trying to put the hat of the final user, and that helps guiding so much, whatever is the thing that you are building. Dogfooding, man. That is so good. And I really, again, go back to the...
to be able to say, we're going to start with the docs and work backwards. And then when you're creating the docs, you realize that
This is complex as hell. I am not going to allow people to do it these three ways, even though I know that when I create it, you're going to be able to do it these three or four different ways. We're just going to say this one way is the way that we choose. We're OK with being opinionated here because we feel like it is best. And so that's all you need to know. Yeah.
Yeah, exactly. Exactly. It was pretty much like that. And this is strange because like, you know, as a software developer and engineer, you are used to, you know, like being able to build things and like if you have more options and you can make them work. I have like, you know, like more features. It's like, this is great. I'm such an engineer. But then, you know...
If you're searching in the near that you can build a bridge that takes you to many different places and it's like, well, a bridge should take you not only to one single place. So it's better just to make one single bridge. So, yeah, that actually helps. That actually works. Well, let's talk a minute about the community and how you go about
prioritizing PRs and merging different issues that come up because there's a lot of activity around fast API. A lot of people are using it, as you said. There's a lot of different competing interests. So how do you look at that and how do you make sure that
A, you're not doing anything that maybe is going to ruin that developer experience. But then B, is not shutting people off because maybe their whole business relies on some feature being merged. Yeah, this is one of those things that I feel
looks so different from the perspective of the person that is building the entire thing than from the people outside of it. It's quite strange. So, like, you know, like, the first thing is the people that are working on the open source stuff is just a handful. Not just for FastAPI, for most of the projects. Actually, in FastAPI, I'm quite...
I'm lucky and grateful that I, well, now I get to pay people to work on it, but I also get like contributions from a bunch of people in the community. And I also have a session for the FastAPI experts, which are the ones that come and help others with their questions in FastAPI. So, you know, like they prove that they know FastAPI by helping others. And then like I can highlight that in the documentation. So, hey, these are the experts.
And, you know, like then automatizing all that to make it work with the dogs and everything. But, you know, like the inflow of communication in GitHub discussions is massive. Before I had questions in issues, but then people will come and 90% or something like that of the things that people will write in issues were actually questions or errors in their own code. So it was, you know, like it was actually...
Not really a bug in FastAPI. So it was very difficult to manage. Now, with having several people, for example, the experts that can check what are the questions that are coming up, whenever they see something that is actually broken, they just ping me and that helps so much because they help me filter out all the noise and figure out what is actually important, what is actually working.
Then for all the open source PRs. So the first thing is because I have translations, there are so many translations open that are just like waiting for another native speaker to come and review it. So those just have to stay there for quite a while. I'm thinking of changing that and switching it to using LLMs. I'm already doing that for Spanish and the results are really, really good.
I want to do that for the other languages because the results are quite good. They are consistent. This is one of the things that LLM's are actually very good at. There are many things that their LLM's are great at.
translating and doing it properly, they are very good at that. So I want to extend this thing that I did for Spanish to the other languages so that we can have consistent translations for each of the languages. Also because there are some languages that have a couple of pages but nothing else translated. So it will be better to have a consistent set of languages that are supported and then translating those.
Then, you know, like half the PRs are just translations. And then there's a lot of others that some, for example, don't necessarily have tests or is not a specific clear use case that they are solving. So it's not obvious what they are doing.
And there are others that are actually that can be solving a problem, but also in some cases conflict with some other features or some other things that I want to do that will solve that use case plus other three use cases. So it's like I am not going to merge this right now because then I have to maintain it.
But then just closing it and saying, oh, I'm going to do this in another way, another moment, it's also rude. So yeah, it's this difficult balance of how to manage all that and how to make sure that you pick the right things. And many PRs, for simple they look,
can get so complicated. In many cases, people come and say like, "Oh, why haven't you merged or why haven't you reviewed this?" One line change PR. Because to review it, I have to check the other 5,000 lines that were not changed and how this one affected them and how everything can break.
It's happened a couple of times. Well, a few times that I merged something thinking like, okay, well, it probably makes sense. Yeah, like the use case is sensible, sort of.
And the code sort of makes sense, although I'm not sure why would we need to change it. But it makes sense. The tests seem to be passing. Like, you know, like this is touching things that I'm not sure if there's anything else touching. But then I make the release and then like something explodes somewhere else because someone was doing something weird with FastAPI. In most of the cases, it's because someone is doing something weird with the internals. But, you know, like I still try to not affect not even those use cases.
So yeah, it's like this strange balance. I still review each one of the PRs. The ones that are changing the internal code and changing complex things, I still review each one of those and make sure that they are good. Now that I have a team, I have a few people that I trust that can tell me like, hey, this looks quite good. And then I can just give it... I still give it a fair of check, but...
at least I know that this is not something that doesn't make sense. You know, like at least I have a good priority of like what are the things that I should focus on. And then to decide what PRs, what issues or what projects to work on and what to focus on is also this balance of what is the thing that will have the biggest impact for everyone right now. And in some cases, some cases it's even like another third party open source project that FastAPI depends on or something. And it's like,
This needs to be fixed because we are using it in FastAPI or it has a big interaction with FastAPI. So that is the thing that requires the biggest priority. Autoconflate, man. Autoconflate for everything, yeah. You go off and you have to fix other people's open source projects so that yours works. That's you doing your civil duty. Yeah, or the dogs, fixing the dogs here and there. Yeah.
The funny part about that phrase that you were saying is, yeah, it's just one line of code. But then at the end of the day, you have to go and see how that interacts with the other X number of codes, thousands of code, lines of code.
it made me think about that Mark Twain quote where he said, I didn't have time to write a short letter, so I wrote you a long one. Yes. Something like that. Yes. And it's kind of that same thing where you... It's almost suspect if it's just one line being changed because then you go like, what's going on here? Why is this one line needing to go in? And then also when you're saying...
People have to trust you when you are not fixing one issue because you have the foresight to say, down the road, I'm going to fix this issue and two or three more. And so it's that two for one or three for one deal. They just have to be patient. It feels like you almost need to have a public Kanban board.
with things that you're focusing on, issues that you're going to be hitting so that people can know, okay, it's on the backlog or now it's going, yeah, he's working on it. All right, cool. Yeah, but I try also a bit of that.
having like, you know, like there's a public roadmap or like these are the things that are like the main thing that are on my mind. But then also because FastAPI covers so many people, there's someone here and there that just comes to ask for something that is not necessarily related to the roadmap. But it's just like adding comments there. And like, it's just like more communication to manage. So in some cases, the trade-off of making the whole thing public
becomes having to handle so much more communication that it ends up becoming not as efficient, you know? At some point, I was just answering issues and discussions and things like that. And I was just spending the whole time answering them and not fixing anything just because I was answering, just writing messages. And it was like, this is not working. This is not sustainable. Dude, I can imagine that one of the biggest
Biggest time sucks for you is when you go on GitHub and you just had thousands of notifications. And it's like that, like you're saying. So, yeah, if you're making a public roadmap and that just gives more surface area for people to comment or for people to engage with you on top of your social media, where people are commenting and engaging with you on top of the actual project itself.
oof, I didn't think that through, but if I were you, I would be afraid to even look at my phone. Yeah, exactly. You should turn it off most of the time. I have to disable the notifications thing, the email for GitHub. Like I have notifications in email from GitHub and at some point when it was like, you have 10,000 and read, it's like, yeah, no, this is not working. Oh,
You know, like, yeah, I just have to go to GitHub, use the GitHub notification system and also rely on the fast API experts. Like a few are part of the, and like, you know, like people on their team that are just like working and they just come and review. There's a lot of PRs that they can,
review and even merge on their own. So for example, if people have been like working on like checking the repositories or like doing a translation or something like that, probably have one thing to Sophie or Alejandra or maybe Pazic, you know, like people might think that are
constantly doing things like that. I also get a lot of help from the fast API experts like Marcelo, which is part of the Pydantic team. There's also, there's also, Judy, Ludovico. There are several people that are just like, that are not necessarily, that are not in the company.
but are helping a lot. They are like some of the experts that also, yeah, that helps a lot and helps me also surface whenever something breaks. Whenever there's something that I need to put attention to, they are the ones that end up just like
bringing me the important news. They're doing their civic duty to make sure that your shit runs so their shit can run too. Yeah, so I can do my civic duty as well. Yeah, exactly. It's just paying it forward all around the internet. That's great. Now, the last question I wanted to hit you with was you have had the luxury of being able to focus on the tech industry
for the past X amount of years. Now starting a company, I can imagine you are already seeing that you're getting pulled in a million different directions, whether it's hiring or it's just paperwork stuff or it is going out and public speaking, et cetera, et cetera.
All of that time is going to detract from the actual building. How are you thinking about that as you move forward? Because at some point, like, you know, the project and you know, the cloud, I imagine the ins and outs of it, your stamp and your vibes on this make it.
what it is today. Yeah. How do you think about continuing that even if you are not able to put your fingerprint on each piece of it? Yeah, that's a very good question and it's difficult because it's indeed a lot of work doing extra stuff and I really love to code. That's something that I really like to do. But this is like, you know, like I have to do this other stuff so that I can get that product and I can use it so...
you know like i can have the team working on everything i just have to suck it and do the rest of the stuff that i have to do but also i i get the fortune to rely on people that are super clever and helping helping me a lot with a bunch of the things and also like get the spirit of like how is the project going and like it's hard to find people like that it's hard to like you know like
get the right people in, but once you start, like, being able to just, like, rely more and more on some people, that's amazing. And that's also, like, a great feeling. For example, the CLI, the new CLI, the FastAPI CLI, since a couple of versions have, like, the new
terminal UI that was created by Patrick. And it's like this new set of CLI UI components that you can use to build CLIs. And it's open source and everything. It's all done by him. And like the same with the CLI that we have for the cloud, it's like just a lot of work by him that I can just like quickly check and see like, yeah, this all makes sense. And he's super clear. So I can just like say like, yeah, this all looks good.
The same with, yeah, just like sign approved. This all looks good. There's nothing good. You know, like from time to time, it's like, why this? Why that? Okay, this, that. It's like the standards are terrible, so we need to follow the standards. Like, okay, yeah, well, then again, let's do it. Perfect. The same with the UI. Like, you know, like a lot of the work has been done by Alejandro, one of the team members, that I can now say, like,
This is a bunch of tweaks, and I see, like, it's a lot of React code and TypeScript and, like, tweaking the Tailwind classes and stuff and, like, here and there. Like, yes, makes sense, looks good, the screenshots look good, but, like, by this point, I can say, like, yeah, I trust the code. It's, like, fine, approve it without having to, you know, like, get the pull request and check all the code each bit by bit just by looking at it.
The same with Sophie, for example. She's been helping a lot with the open source, with Typr and with FastAPI, mainly with Typr. That has been the main focus. But then I can see whenever she goes and gives a comment with a review, it normally explains what was the problem, all the references, all the things that were tried. She already fixed up the tests and the docs and everything, and I can just go and say, make sense, approve it. So that really helps a lot. It's difficult to get to that point,
And like, you know, it has to be also gradual. I cannot just suddenly say like, everyone just merge away whatever you want. Because, you know, like the whole point of FastAPI and my open source project is that I am so picky with the quality that everything has to go through me for those things. But then being able to have like more and more reliance on the team, that's amazing. And that's an amazing feeling. Being able to see like, oh, we are building this whole thing together. That's awesome. Yeah, it feels like you are...
Learning to let go a little bit of the reins and trusting the team more and duplicating yourself. And I like that you say it is a great feeling because then you can go and focus on other stuff. If you know that you have the team there and you trust the team to hold the same quality standards as you, the...
Last thing that I wanted to mention is I think people can sign up for FastAPI Cloud right now, right? Yes. So people can go and join the waiting list. It's fastapicloud.com. I hope we are going to start letting people in soon to try out the beta. Yeah, I think that will be something great for people to go and try. And also just keep using the open source projects because now...
they have a little more power behind them. So yeah, like I will say you're in good hands, but like, you know, I'm biased. Classic, man.