Sebastián: 0:00

And then, if you want to use the cloud provider, you can just say FastAPI deploy, and then we FastAPI Cloud take care of handling all the deployment. And like taking your app, installing everything, deploying, autoscaling, handling all the HTTPS, like all that stuff is just taken care of, and then you can just make sure that you build an app and that's it. You know, like taking care of the business logic of the application, which is normally the most important thing.

Julian: 0:28

Hello and welcome to the PyBytes podcast, where we talk about Python career and mindset. We're your hosts. I'm Julian Sequeira.

Bob: 0:36

And I am Bob Beldebos. If you're looking to improve your Python, your career and learn the mindset for success, this is the podcast for you. Let's get started. Hello, welcome back everybody to the Five Eyes podcast. This is Bobel de Bos, and I have a very special guest, sebastian Ramirez. Sebastian, how are you doing?

Sebastián: 0:54

Thank you very much. Thank you for having me. I'm doing very well, having a lot of fun.

Bob: 0:59

Yeah, you're busy. We had you back at episode 80. That's over 100 episodes back now, and so a lot has happened. I mean, on one side, we still use your libraries every day and we love them, right, so it's definitely stable. But also a lot of new developments happening, and I think mainly that you announced that you now started a company right FastAPI Cloud.

Sebastián: 1:22

Yep.

Bob: 1:23

Congratulations. First of all, Thank you very much, thank you.

Sebastián: 1:25

Yeah, I think that is the biggest change. I mean, in the open source side, everything is quite similar, but yeah, this is the biggest change around everything.

Bob: 1:38

Yeah, tell us the PyBytes audience here how that evolved. I mean, we, we have been there right. We do these fast api deployments and you can use. You know, flyio and docker and and actually zach, wrote an article a month ago and it's it's. It's pretty smooth, but still there's a lot of nitty-gritty. So I can see the pain, but I will, I, I will let you, uh, tell us how, how you got to the FastAPI Cloud.

Sebastián: 2:05

The company and how that evolved?

Bob: 2:07

Yeah, let us know.

Sebastián: 2:09

Yeah. So I have been always trying to teach as much as possible how to use the underlying things and the underlying tools instead of just building some additional layer of abstraction on top. So I had like a you know like I actually started doing open source. It was with some Docker images for Flask, before even FastAPI existed. At some point I had one of the biggest sites for an alternative to Kubernetes when there were like a couple of other alternatives, because, like to me, that was a simpler product and it was much easier to get something off the ground and just like you know like implementing it yourself and just like deploying it yourself and handling it yourself. But then at some point you know like Kubernetes won the battle against each other and won the race, but still Kubernetes is such a big behemoth, you know like it's such a huge thing to handle and to manage and I wasn't that comfortable with like having like you know like I can take someone that has like learned a bit of Python and then teach a little bit of fast API and, you know, in a couple of weeks you have something that is like a product pretty much ready, but then learning how to deploy it and like getting to the point where you can do it confidently, can take a lot of time. It can take months and you know it comes with so much struggle and uncertainty and like back and forth and like trying an error and like it's. I wasn't happy about that situation, that feeling how that was working and knowing that the main alternative right now is Kubernetes or maybe trying to use one of the products from one of the providers. There are many like Fly or Render. There are many providers that do, and they do a very good job at providing a sort of generic layer of tools on top of some other lower level abstractions. But at the same time they need to be abstract enough to be generic enough for many use cases and try to cover, like you know, like many different programming languages and frameworks and things. So when you are going to replace something very specific like FastAPI and you want to use one of these tools, in many cases you end up having to tweak a bunch of configurations and a bunch of things with just the nuances of each one of the cloud providers. So all the idea of removing all that friction, of dealing with the underlying cloud infrastructure or the Kubernetes or whatever is it that is going underneath. The idea will be to try to remove that as much as possible, but sometimes that ends up becoming just exchanged by some different types of configurations that are specific to some specific provider and things like that.

Sebastián: 5:07

That's the point where I thought, like, okay, it will probably make sense to be able to. It will make sense to have something that will allow someone to just write some code and just have one command and it will do everything right by default and like do all the nice things by default. So, as you can, you are developing an app and you run FastAPI Dev to have the local development server. Then, if you want to deploy it in any other way, you can do FastAPI Run and you have the production server. Then, if you want to use the Cloud provider, you can just say FastAPI Deploy and then we, fastapi Cloud take care of handling all the deployment and taking your app, installing everything, deploying auto-scaling, handling all the HTTPS all that stuff is just taken care of, and then you can just make sure that you build an app and that's it Taking care of the business logic of the application, which is normally the most important thing.

Sebastián: 6:04

So that was the idea, that's the product that we are building and it's like I feel it's like similar to what FastAPI will provide in another layer. You could build everything that you will do with FastAPI with any other framework and just like adding a bunch of plugins and configurations and, like I don't know, maybe manually writing the open API, like it's possible, it could be done, but it's probably simpler to just build something with FastAPI. And, of course, you can deploy FastAPI in any other cloud however you want, like it's all open source, it's all based on open standards, so that you can deploy however you want and you will be able to keep just doing that. But maybe there's like this additional level of a abstraction. That is just the right abstraction level so that you can focus on the application and we can handle the cloud part. That is the, that is the premise, that is the idea and that is what we are building yeah, and I agree, if we can just focus on writing the business logic, that would be great.

Bob: 7:03

And so that was a nice involvement as well, because you started at the FastAPI command line and now it's just the Nexus switch right Like FastAPI deploy, and I guess yeah, I haven't tried it yet because right now there's a waiting list, right.

Sebastián: 7:17

Yeah, yeah, yeah, like right now we have a waiting list and like I'm super glad to see that people have really liked the idea and so we have. Like a lot of people have joined the waiting list and have been asking for the you know, like early access we are right now. The phase we are right now is we are doing the. Well, I don't know when this episode will come out, but at the time of recording, pretty soon. Yeah, okay, nice, at the time of recording. We are in the. We are in the alpha preview stage, so we are having some just a few people joining and we are doing some UX research interviews to check all the workflows, to clean all the possible paper cuts, to tweak and fine-tune the developer experience to the maximum so you can provide the best possible developer experience for FastAPI, which has always been the key of FastAPI having the best developer experience. We are in that stage. Next, we are going to start onboarding people in the beta previews and then we can more consistently keep onboarding more and more people.

Sebastián: 8:26

And that will be the next stage. That is super exciting. That will happen, probably soon.

Bob: 8:31

Yeah, yeah. Now what stands out is your DX-first mindset. With all these libraries, right, like FastAPI, sql Model and Typer, great documentation, ergonomic for a developer, right. But yeah, can you already reveal a couple of DX decisions you had to make with this, like how you designed the ideal experience?

Sebastián: 8:53

Yeah, so we want people that are building fast API apps to be able to have a good setup with no configs by default. It's just SEO configs. You just say fast API deploy and we handle the rest. And we are handling auto scaling automatically based on requests, including scaling down to zero, so people will be able to save on costs when they don't have like requests that are coming and like everything just scales back up. But if you have an app that is like I don't know, like some crucial functionality or something that you really need it to be on all the time, like that can also be configured so you can have like a minimum number of instances running. Let's say, we are also integrating with providers so that we can provide we are not, at least not on this stage we are not going to provide databases or things like that. We're going to integrate with database providers so that you can have.

Bob: 9:50

They have SQL models right.

Sebastián: 9:52

Yeah, yeah, and like SQL models, of course, it will make total sense to have the integration there. So we want to make sure that we tweak and fine-tune the integration so that it's super simple. I mean, you can integrate with any third party provider just by setting the environment variables in the deployment and you can just like use whatever tool you would like to use. But we want to improve the developer experience in that area so that you can have like some simple way to integrate with some of these providers and you can just like have a simple integration to create a database or to connect with some more observability tool, for example with Dogfire or something like that. So, yeah, that is some of the things that we are working on right now.

Sebastián: 10:33

But the idea is that there are so many things that we can improve, that we can tweak to make the developer experience a little bit better and to have their end results a little bit better and to have things that end results a little bit better and to have, like things that just work by default without requiring so much effort on the on the developer side, because there are many things that can be just quite common to many deployments and it doesn't really make that much sense that everyone that is building an app needs to become an expert in a?

Sebastián: 11:03

You know, like site reliability engineering or like dev officer, like whatever is the term that is used. It doesn't really make sense that everyone has to know everything about that. If we can take care of all that part, and then people can, you know like, offload all that effort into the system and then, like we can just like do it for a lot of people at the same time and we can keep the pace with all the you know, then, like we can just like do it for a lot of people at the same time and we can keep the pace with all the you know like evolving cloud that just keeps changing all the time. And then, like you know like, distribute that, distribute that work across, like so many apps that can be running on top of it.

Bob: 11:38

Nice yeah, because in practice we have to get into DevOps a bit as developers because of all these complexities and dependencies, right, so taking that away is a huge win

Julian: 12:04

of a bootcamp style interface of working together with a group of other people, except it's got that unique PyBytes twist on it, where you are going to be building all day, every day. There is very little material that you will be consuming, so you won't be stuck in that tutorial paralysis. The point here is that you will be building from day one and alongside other people also building the same app in their own repositories. You can all talk, you can all share, you can all grow together and, of course, you'll have a PyBytes coach supporting you the whole way. So if you are interested, just check it out, click the link below. It is pybytescoachingcom and we will see you in the next cohort.

Bob: 12:41

I also like the outeraling aspect, because maybe I just don't know how to do it, for example on Heroku. But I'm also like, yeah, should I make a performance dyno or less or more, and I then have to look at the request and kind of have to make a guess or an estimate. So if the tool can already do that based on the request, that would be really nice service, I think.

Sebastián: 13:02

Yeah, and the thing is also that we are hyper-focused on FastAPI and Python, so we can assume many things and we can make many optimizations that are just devoted to all this ecosystem, without having to worry about making something that is generic enough so that you can run many other types of programming, languages and frameworks and things. We are first trying to hyper-focus on this and then figure out what are the next things that we need to build, but our focus is just to build something. Do this thing and do it very, very well and then take it from there.

Bob: 13:39

Yeah, it's like a home match, right, you? You know the territory. You can just focus on fast api because, yeah, except before, like these other providers, they have to keep it generic. But also that adds complexity. Yes, yes, definitely. So, uh, tell me a bit about the journey. How, you know the company came about and there could, I guess, be some challenges with business versus open source. So how was that journey and what are?

Sebastián: 14:04

some of the challenges you had to overcome.

Sebastián: 14:06

No, yeah, it's actually like many people and also investors and friends and people have been telling me for years like, hey, you should build a company. But it was like I didn't have a specific product that I could sell and every time I figured I could build something else that could be useful. Then it only made sense to make it open source. So that's how Typer was born, that's how SQL Model was born. It was like, well, I think this is going to be useful for a lot of people, but it just doesn't make sense to make it in a different way. That is not just open source. So I was just reluctant to building a company or building a product. But then the combination of so many users building fast API, building with fast API, it just growing so much and the landscape of deploying stuff being getting like so complicated is it's fun because, like you know, it's very powerful to get a pure linux machine and just install everything and deploy there. And then it was so useful and so it felt so yeah, so powerful again, when you could just like build a docker container, docker image and deploy that and like you have replicable stuff and like all that, and it felt like we were going towards something like you have replicable stuff and like all that, and it felt like we were going towards something that was simpler and leaner and like easier to manage. And then I guess, like suddenly we needed to handle the scale of the internet and one single machine was not enough. And then, like now we need a cluster, and just changing from one machine to multiple is just this massive, increasing complexity. And then dealing with all the Kubernetes, all the cloud providers, like all the stuff, is just like so much. That, combined with like there's a lot of people building FastAPI and like you know, like I felt this what sort of a shame. Or like I felt bad that I couldn't provide something to users and I could tell them hey, you got this far in the documentation, you learned how to do all these things. Now you can build an application that is pretty much production ready.

Sebastián: 16:13

The next step is just like deploying it. But it's like deploying it now you're on your own. Go and figure it out yourself. And it's just like this a massive jungle of terms and like concepts and things to learn. That like I felt, like you know, like I was just like throwing people out the cliff and like just go and figure it out yourself. So, like I felt like it was, it was something that was missing there, you know, like there was a bridge to finish crossing that cliff that was needed there and seeing how all things you know, like the landscape of deployments, clouds, kubernetes kept getting more complex and like people kept needing to deploy applications and also getting inspiration from other providers, like you know, like I don't know Vercel, netlify, cloudflare.

Sebastián: 17:01

There are many providers that simplify a lot of the work, for example, in the front-end world, where you can just build your front-end and just use one command and then you deploy that and they take care of a lot of the parts. For that area. That felt that it was quite simple and useful and I could just focus on doing that work. But I didn't see something that was doing that same type of providing that same type of developer experience for backend development and even more in particular, for fast API. So it felt like there's this thing here that will make sense. It will make sense to build this, and this is also whenever I'm building something I try to see what I try to compare what will be the cost of learning how to use the underlying things versus the cost of learning this new idea that I'm thinking I could create, and for the idea to be worth it, the cost of learning my new thing has to be much, much smaller than learning.

Sebastián: 18:06

Whatever is the underlying technology, you know, like hopefully like orders of magnitude simpler or smaller, or like improve the developer experience so much that it's like actually worth it learning that. That's what happened with FastAPI, with TypeScript, sql Model, asynchro, like you know, like all these tools have had this component of me trying to not build them, me trying to not create them and trying to figure out what is the right way to build these things and maybe to teach what are the underlying technologies. And then at some point, it just really made sense to make something that will be a little bit simpler on top and by learning how to use this simpler thing, it will save a lot of learning and work to learn all the underlying stuff. So it was the same pattern, but this time it was like, finally, it was a product that people could use and people could end up paying for when they are actually using it and like getting something. So when they get something, some value, and then like they will be willing to pay something for that.

Sebastián: 19:08

So it was just like the right moment and the right combination of factors and, at the same time, this was, I think, the right type of product, in that it has a very nice alignment with the open source side, because the more people are capable of building stuff with fast API and being able to build simple things like being able to build things in a simple way and being able to be successful with just the plain open source stuff the more potential clients for the product. So it just everything aligns very well. You know like. It's the right incentives for the company. It makes sense that people are being able to use fast API very successfully, so it makes sense to keep the libraries well-maintained, to have good documentation, to make sure that everyone can keep building like more and more types of apps with fast API. It's just like the right alignment of things.

Sebastián: 19:59

So I, you know, like I told you, it was like it just made sense to try and build it. The only thing is building that required a lot of capital, increasing the team and a lot of effort and time dedicated to that. But if I was, you know like, willing to take that effort and to do all that and, you know like going the route of raising money and like getting the team building, all the stuff apart from that. That is, like you know, like the difficult part. Let's say it all made sense, it was like all worth it, so like yeah. It was like, yeah, just have to do it makes a lot of sense.

Bob: 20:38

Yeah, it's a beautiful model where you still if the library is an open source and everybody can contribute and they can use them for free. But, yeah, I should say, like, the more people build with fast api, which already has a massive adoption, it's really impressive and also the more clients you can, or customers you can get for the um. You know, the premium thing, the deployment, which is just the next logical thing. Right, because, because, why only build locally? You need to at some point expose it somewhere. Right For people to use it. So, but, yeah, how long did it take you and how big is the team now? And how was that? Because, yeah, it's not bootstrap, right, it's funded.

Sebastián: 21:16

So how was?

Bob: 21:16

that process? How did that happen?

Sebastián: 21:18

So it was well, I was in 2023. I so it was well, I was in 2023. I was on the Sequoia Open Source Fellowship. So Sequoia, the venture capital fund, they started this open source fellowship, so they will cover my expenses so I will just be able to dedicate, you know, like full time on open source. So I was 2023. I was just like fully focused on building the open source stuff.

Sebastián: 21:40

By the end of 2023 is when I thought like OK, probably makes sense to go and build a company. So I started that on 2024. And it was like, of course, like you know, like there was already the relationship with Sequoia and like everything to like you know, it was by December 2023, I told him, hey, how about if I started a company? You know, like one week later we were signing the papers and everything. It was like super fast. And then it was all 2024 building the thing I have been trying to keep, like you know, like a very lean team of people and trying to grow only when it's painful not to grow, because I feel it's much more efficient and empowering and enjoyable having a lean team where everyone can be a big ownership of each one of the things that everyone is doing so. We have been trying to keep it super small. Right now we are around eight.

Sebastián: 22:38

And it's probably super small in comparison with many other teams and for me, I already feel like we are quite a bunch of people.

Sebastián: 22:46

And it's probably super small in comparison with many other teams and for me it already feels like we are quite a bunch of people.

Sebastián: 22:50

But the idea is to, you know, like, to keep that spirit of having a bunch of people that are like super independent and can take like a giant project and have like full ownership of that area and that project and that thing and like it's a it's super enjoyable to work that way because, like you know, like when you know that you sort of own something and you have to take care of making sure it works well, and like you enjoy doing that, and you can see, oh, something is wrong, and then you can just go ahead and tweak it right away and say, like I needed to fix this. Uh, just check it out, make the reviews, the approvals, but, like you know, like removes a lot of the bureaucracy and like the busy work. So I I think that's, I think that's great, like I'm having a lot of fun and I think, uh, the the energy in the team is also great. So it's great to see, like you know, like people making jokes with each other and like everything that's.

Bob: 23:43

I enjoy that a lot nice do you still endorse uh documentation driven development, as we discussed last time?

Sebastián: 23:49

yes, yes, definitely, I think that term came out of this podcast.

Sebastián: 23:55

I'm pretty sure, right like we hadn't mentioned it before and like I just kept using it. Uh, I, I, you know like I have been doing it even more and more. I ended up like even building plugins and like I just kept using it. Uh, I, I, you know like I have been doing it even more and more. I ended up like even building plugins and like custom things for the documentation so that the documentation is embedded automatically, including the different versions and flavors of python, so that you know like I can do it even even more I can just write people that didn't listen to our previous uh chat documentation driven like if tdd.

Bob: 24:22

Like you write the test first. This is like I can do it even more. I can just write it Just for the people that didn't listen to our previous chat. Documentation-driven like if TDD. Like you write the test first. This is like one level up in the abstraction you first write the documentation If it was already a thing, calling the methods, whatever, and then you go build it right, so you literally start writing documentation. Is that still how you do it?

Sebastián: 24:40

Yeah, yeah, yeah, good point. Documentation, or is that still how you do it? Yeah, yeah, good point. So what I do is that? What I have been doing is writing the documentation of how I expect the thing to work and how I want to explain it at the same time, or even before, I write the actual implementation, and it actually helps a lot in that.

Sebastián: 25:02

I remember even, like for something in SQL model and maybe we talked about this the last time there was like some way it was possible to configure something in three different ways, three or four or something, and it was just there for free, like you could already just like do that in those ways, but then writing the documentation for that required explaining. Hey, you have like all these options and then like this one has the priority over this other one, and like it's just so much complexity in just understanding and explaining the concept so people will have to learn a lot of stuff just to figure out how is it that they could do it and how they should do it, when, at the end, it was not like a big advantage to be able to do that particular thing in many different ways. There was only one that made sense the most. So I did the work of removing the others just to leave a single one, just to make it simpler to understand and to explain and to and to have like a simple way to to work with it, and and I feel that works great because if you can ensure that you can explain something and that it can be used, it just makes more sense to build a tool that way, because people are going to be able to be using it more easily. It's also the same way that you know, like I have built all these open source projects have been built to solve some specific problem that I was having and trying to do it in a way that will satisfy me as a user, and that is the same way that we are building the product. It's like I am the first user.

Sebastián: 26:36

I really enjoy being able to hit api deploy and then having the thing live there. I was having a conference, uh, here in spain last week and uh, because I'm in spain right now and uh, I I was doing a live demo of fast api cloud and then I was saying like, okay, you build the app now, you say fast api deploy and then you get like the https ur URL and you can access and it's already there. And I have to keep like the serious face because you know, like I'm presenting, I'm giving a talk and put it inside. I was so excited, it was so, so nice to be able to have that very simple developer experience that just works right away. It just works. And also because I know all the work we have been doing for like a year and a half underneath to make sure that everything is just working and everything is in place so that this just works.

Sebastián: 27:29

But then having the developer experience, that is like super exciting to me as a developer. You know, like as a developer, building stuff with fast API, that is what I am optimizing for me as a developer. Like I'm building the tool that I wanted to have. I just I am just lucky enough that VCs are willing to give me money to just like build it and then try to sell it to other developers like me. But, like you know, like I'm building the tool that I wanted to have and that I wanted to use. And, yeah, it's fantastic when you can optimize for the thing that you are using yourself. It just aligns everything so well and you can make a very, very, very good product for other users like yourself.

Bob: 28:14

Yeah, I think the speed and the ergonomics really matter. Like look at UV right Like it works so well, it's fast, the interface makes so much sense, right. And it just goes a long way. Yes, exactly, exactly, Cool. Yeah, maybe you mentioned a bit before. I was still going to ask what are two surprising lessons from seeing FastAPI being adopted at this massive scale? It is now. I mean, how many stars on the repo now? Was it like 84,000, or was it more already?

Sebastián: 28:46

I think it's yeah, 84,000. Something like that.

Bob: 28:48

yeah, and you share these cool use cases on Twitter right or on X I think it was the other day ChatGPT was using it or these images. So I guess yeah. What are some success stories of FastAPI you're particularly proud of?

Sebastián: 29:04

Yeah, there are a bunch of things that I find I don't know fascinating. I know, you know, like I know, fastapi is used all over the place for like banks, pharma, machine learning, governments, all types of institutions, like car manufacturers, like rocket manufacturers, you know, like for many, many, many different types of things. There are like a few that are like oh, wow, like chat GPT images, for example, that you know, like generating those images, like oh, there's a bunch of us underneath, that is so cool. Or the Space Telescope. The James Webb Space Telescope sends the science data and the old images, sends that to the Earth and then from the Earth they use FastAPI to distribute that around the globe using FastAPI. I think that's super cool.

Sebastián: 29:54

And also they use it to control the At the CERN. They use it to control the particle accelerators, like the LargeERN. They use it to control the particle accelerators, like the large Hadron Collider, like I mean, there's a lot of additional software before and after just to get to the particle accelerators, but FastAPI is the API that sends the information to control the particle accelerators, and for me that's mind blowing. And then, like you know, then I tweeted about that and a few people came like, oh, is this same. We also use it in Brazil, and they also use it in the United States, and they also. There are a bunch of particle accelerators around the world controlled with FastDPI, and that's fascinating.

Bob: 30:31

Could you ever imagine? That?

Sebastián: 30:36

Yes, I never imagined that. If you see a black hole in the sky, maybe tell me, I don't know, it might be a bug. Yeah, I don't know. I also someone told me. When I mentioned the space telescope, someone also told me like, oh, also, the largest telescopes on Earth that are, like managed by the I don't remember what is the name the European Space Association, something like't remember what is the name, the European Space Association, something like that. I forgot the name, but they handle the largest telescopes that are like inside of the Earth and they are also like controlled with a bunch of fast API internally. So, I don't know, it's like to me, that's super, super, intriguing, fascinating. That's super, super, intriguing, fascinating and you know, like for like all the daily apps that you're using, like it's handled. It's used to handle the incident response in Netflix. I don't know things like that. It's very cool.

Bob: 31:31

Yeah, it's also nice that you have the full scope right, because you have fast API and then you added SQL model for the database and then you have type over command line, for example, doing this app now in a cohort, and we use all three right, because it makes sense to to have the full scale. Maybe the only thing, alembic, um, that is still have to gonna use separately and might not be two and two or two years, but yeah, it probably is.

Sebastián: 31:53

That is also that's actually part of the plans. Like, yeah, and like you know, like the all projects, all the open source projects, are actually quite important to us, like we are using internally for the product and like they are so useful and they're important for our users. As I was saying, you know, like having the right alignment of incentives is great, because now for the company that is the one paying the money, or the developers, it makes sense that the projects are well maintained, are easy to use and have good features and everything. So it just makes sense to devote and dedicate resources into improving these tools. I'm super excited about that.

Sebastián: 32:31

So, for example, with SQL model, I want to have an integrated CLI that wraps Alembic and makes you know like a simpler interface. It will probably be just Alembic underneath doing the work, but maybe with a simpler interface that is like probably more familiar to how all your tools are like behaving right now and things like that. So like, yeah, there's a bunch of things that we can like do and improving like all the projects. In all the projects, I have ideas like we can do this and we can do that and we can improve this here and there, so that you know, like people that are already using the tools can just like keep using them as they have been, but then like a couple of tweaks and a couple of extra features and things that should simplify how things are done. Things that should simplify how things are done that will be tolerated in a couple of cases.

Bob: 33:24

Yeah, I mean the command line interface for FastAPI only came later right, so you could always add that to SQL model.

Sebastián: 33:32

Exactly, yeah, exactly Exactly. Yeah, how do you manage that?

Bob: 33:35

complexity with these projects Because they so many contributors, so much complexity. I mean it looks all so easy to use it from the end user perspective, but you actually hide a lot of complexity underneath right. So how do you scale these projects, Because some of the code is pretty complex.

Sebastián: 33:54

Yeah, yeah, and as you were saying, it's also like one of the challenges is like at this stage, when there are so many people using it and so many applications and so many things, it's very easy's code somewhere because they are doing something weird or some strange plugin that does something strange and modifies things inside I don't know, but like it's very easy to get like little changes that end up affecting users. So you know, like handling that requires like a bit of care. I still review the PRs and like I still review and approve and merge like each one of the PRs. Now the team can do a lot of the work that goes before that and, like you know, like checking that the PRs have tests that are well documented, that the use case is, you know like valid and everything, but I still give them like a final check and sometimes that is sometimes not obvious. Or, like you know, like the general public using the tools, for example, someone comes and says like oh, why hasn't this PR been merged? It's just like one line changed, like it should have been merged way before, and it's like the thing is I cannot just review the line that changed. I have to review the other 6000 lines that didn't change because, like I don't know how this is affecting everything, I have to check everything that this could be interacting with to make sure that I'm not breaking something else. So, you know, like it requires a lot of careful checking that everything is correct, and I prefer to lean on the side of keeping very good quality and like not just like changing a lot of stuff, like I don't really need to move fast and break things. I need to make sure that things are, like you know, like properly there where they are and that they make sense and that there's a little chance that they will break a lot of stuff. And also, whenever we change things, I make sure that I have like some time to repair anything If there's anything unexpected that just exploded.

Sebastián: 36:10

But the API has, like from pretty much the very first release, 100 percent of the coverage, but still there are like corner use cases of like how people do different things. That just requires, like you know, like this extra effort and fortunately now also with the team, is also easier to you know like scale that a little bit more and like also to have like also part of the part of the fast API team, part of the people that help with fast API is not just people from the company, also people, external people, like the fast API experts and things like that, and they help me check. Like you know, whenever they see that something is like important that is breaking or something, they can come to me and tell me hey, pay attention to this one. This one in particular is important because the inflow of questions is just massive. It's just very difficult to handle it on my own, but then, like having this additional help helping me make sure, like you know, like keeping eyes on everything that just yeah, it helps a lot.

Sebastián: 37:09

So it's like it's. It's it's weird that is different than what it looks like from outside. Uh, but it's still it's. It's a lot of fun.

Bob: 37:18

Yeah, it's, it's a lot of fun. Yeah, it's quite fascinating how many eyes there are on it. I mean, the contributor page has hundreds of people and it's very open and somehow it all works, you know, and it is an efficient flow.

Sebastián: 37:31

It seems like, yeah, yeah, yeah, it's also fun that you know like, the amount of people that come and contribute and help consistently and just keep helping is actually tiny. It's a handful of people that are doing most of the work. In most of the cases, people come and ask one question and then they just leave, or they come and make one PR but they never come again, maybe even if the PR requires additional changes. In many cases they don't come back or they come back for this specific PR, but it's not that they are helping review their PR. Contributions are normally handling something that is, in particular, important for the person that is doing the contribution. So it has these additional nuances of how to handle that.

Sebastián: 38:22

But still like, yeah, you know, like, this is not different than all the other open source, most open source projects and this is actually quite counterintuitive, but most open source projects are handled by one person or like a handful of people. If they are lucky, in most of the cases it's just like one person or like one and a half or two. That's, you know, the big majority and the big projects, you know like, I'm talking, the biggest projects they are still like in this same situation. So like, yeah, this is, you know, like this handling of expectations and like managing all that and like, even though it's not obvious, it's like still like a handful of people, just like putting a lot of work behind these things.

Bob: 39:04

Yeah, how do you even keep balance? Because you have these three or more projects and now the company. Yeah.

Sebastián: 39:11

How do you keep the balance?

Sebastián: 39:13

It's actually that's like you know, like I keep.

Sebastián: 39:17

It's one of those things that I keep coming back to and thinking about what is the right thing, what is the thing that I could put my attention on or like put effort on that will have the biggest impact right now, and like dividing that and trying to work on that.

Sebastián: 39:33

For example, like I don't know, like two days ago there was a releasing click that will change some things, and like there were like some breaking changes that I needed to handle in Typr and even though I was, you know, like one day before making the conference, like showing FastAPI, cloud and everything, and like I had all this stuff in FastAPI and the product and SQL model, but this thing in Typr was like super important because a applications built with Typer uh needed to be able to keep working. So I needed to have like a quick release Just with the, just to uh with the pin to handle that and then like being able to refactor whatever needed uh behind the scenes, but like just that just needed to happen right then, right there, because the was the biggest impact then. So like, yeah, it's just like this balance of keeping trying to keep whatever is the thing that has the biggest impact and like the most important thing up front, because, yeah, like I wish I had infinite time, but, like for now, I have to 80, 20, burrito principle to the extreme.

Bob: 40:36

Yeah, I guess you just have to accept that you never can do all the work, all the issues. It's just not going to happen. It will be working forever. As long as you just constantly focus on the most important tasks, you can get pretty far.

Sebastián: 40:48

Yeah, exactly, and getting the help of people that are just helping me handle all the projects and everything. That's amazing, so that helps a lot.

Julian: 40:59

A quick break from the episode to talk about a product that we've had going for years now. This is the pybytes platform. Bob, what's it all about?

Bob: 41:04

now with ai, I think there's a bit of a sentiment that we're eroding our skills because ai writes so much code for us. But actually I went back to the platform the other day, solve 10 bytes and I'm still secure of my skills because it's good to be limited in your resources. You really have to write the code. It really makes you think about the code. It's really helpful.

Julian: 41:23

Definitely helpful, as long as you don't use AI to solve the problems. If you do, you're just cheating, but in reality, this is an amazing tool to help you keep fresh with Python, keep your skills strong, keep you sharp so that when you are on a live stream, like Bob over here, you can solve exercises live with however many people watching you code at the exact same time. So please check out pybytesplatformcom. It is the coding platform that beats all other coding platforms and will keep you sharper than you could ever have imagined. Check it out now, pybytesplatformcom.

Bob: 41:58

And back to the episode well, we're on time, but uh, I always ask about the books and what you're reading. When you're reading anything cool or learning, I'm reading, I have been reading.

Sebastián: 42:08

it's fun, but I have been reading like I think I'm finishing the sre book from google, like they book about, like all this stuff that I am dealing with for the past year, I guess.

Bob: 42:23

So sites reliability engineering right.

Sebastián: 42:25

So I, you're a liability engineer and, yes, that's great, like a bunch of things about that, and I also ended up reading about like standards and things like that here and there and like yeah.

Bob: 42:35

All technical no there and like yeah.

Sebastián: 42:37

All technical, no, no fiction. In most of the cases I ended up just like reading a bunch of technical stuff. I was also recently reading the protocols for MCP and like trying to check out like okay, what is actually happening there and like what needs to be done. What do we need to do on fast API to support like all those use cases as well? Uh, but like yeah I, I ended up reading just so much standards.

Bob: 43:02

I see that in the documentation, right, because you don't just explain the framework but you also explain the underlying concept, like with SQL model. There's a lot of documentation around the SQL basics, right, and that concept. So yeah, that's you really want to teach us, like not only what the tool does, but kind of what's the problem it solves, right.

Sebastián: 43:22

Yeah, yeah, at least that's the intention. Definitely, I'm glad to hear that you say it, because, like, yeah, that's definitely the idea.

Bob: 43:31

Awesome, well, thanks for all you do and amazing libraries that we use with joy every day, you know, and very excited for you, for the company, and cannot wait to try it out. Any final shout-out or things you want to share before we wrap it up.

Sebastián: 43:46

Hey, I think you know, like to all the people like building cool stuff and all the people building open source that we are based on, and all the people helping with the open source projects, with FastAPI and friends it's a lot of work from a lot of people and there's a lot of people that are not necessarily having the spotlight, but they're still doing all that work behind the scenes and, yeah, I love that. It's so much appreciated Awesome. Well, thanks, sebastian, great catching up and yeah, good luck with everything. Thanks for coming.

Bob: 44:18

It's so much appreciated, awesome. Well, thanks, sebastian, great catching up and, yeah, good luck with everything.

Sebastián: 44:22

Thank you very much. Thank you, thank you for having me.

Julian: 44:26

Hey everyone, thanks for tuning into the PyBytes podcast. I really hope you enjoyed it. A quick message from me and Bob before you go To get the most out of your experience with PyBytes including learning more Python, engaging with other developers, learning about our guests, discussing these podcast episodes, and much, much more please join our community at pybytescircleso. The link is on the screen if you're watching this on YouTube and it's in the show notes for everyone else. When you join, make sure you introduce yourself, engage with myself and Bob and the many other developers in the community. It's one of the greatest things you can do to expand your knowledge and reach and network as a Python developer. We'll see you in the next episode and we will see you in the community.