Sebastian Ramirez, Python FastAPI Creator Interview | Craft of Open Source Podcast

Check out our open-source Feature Flagging system – Flagsmith on Github! I’d appreciate your feedback ❤️

Episode Transcript:

I'm interested in talking to Sebastian Ramirez. For those of you who don't live in the Python world, Sebastian is the Author of FastAPI, which is rapidly becoming one of the standard asynchronous Python web frameworks. Sebastian, welcome. Thank you for your time.

Thank you very much, Ben. Thanks, everyone, for reading.

Where are you right now?

I'm in Berlin, Germany.

Where did you grow up?

I'm from Columbia. I've been working in a bunch of startups throughout the world in Latin America, the Middle East, and now in Germany.

Starting a web framework seems to be the quintessential open-source project, but it also seems like an audacious thing to do right now. There's been so many. Now, by design, they have to be opinionated. In a language like Python, there are hundreds of web frameworks. I'm curious to know what it was that made you create a folder, get in it and then start writing FastAPI?

I'm avoiding creating a framework for years. I was first trying to use all the other available frameworks and figure out how to solve the problems I had. I ended up using a bunch of flasks, a little bit with some jungle with a generous framework, trying and combining a bunch of plugins and trying all their frameworks to solve all the needs that I was having. I was working at several startups, building a bunch of products. We ended up pivoting a lot on building new things frequently. I ended up solving the same problems over and over again and finding some patterns that were frequent in many of these systems.

I always wanted to simplify all of that workload. At some point, I ended up creating a project generator like a cookie-cutter with Flask and a bunch of plugins. I brought all the developers. I was in charge of using it, but still, you have to let these decorators, parameters here, and these things there. Many difficult-to-manage components that were also fragile and plugins sometimes didn't talk very well to each other and all the stuff.

I was doing that. At the same time, I kept researching new frameworks and tools. I'm like, "What is the best way to do it?" At some point, I was even considering moving to TypeScript to be able to get all the type annotations on those features because I was already using TypeScript for a bunch of front-end and desktop applications or something like that.

Python 3.6 came with type annotations, and I realized that these types of annotations allow editors to give out the completion and time checks. Those red lines tell us where are the errors in the code before running it. All of that is provided with this type of annotations, more specifically by the editor knowing the types of variables and objects in the code.

I wanted to take advantage of that in Python, but there's still not a lot of that in Python, in general. It was not being used a lot because that was released a few years ago. I ended up finding another framework that was called API Star. It was doing almost everything I wanted. It was missing so much indication stuff that I wanted and needed. I was about to start contributing to that. I started all the standards and all the stuff to be able to contribute to that. Tom Christie, the author, who is the same author of Django REST Framework, had to deprecate or shut down the framework part of that project and convert it into a validation tool.

He was also at the same time starting Starlette, which is a web toolkit for Python using AC stuff. That was my cue. I was like, "This was the closest to the perfect tool for me. I need these features, but there's nothing that is better than this, and this is shutting down. Let's try this." At first, it was a lot of researching and studying the standards of an idea with schema or two, which are old combined in this standard. It's figuring out what will be the best design for the developer experience and how it will feel to develop with FastApi.

I spent a lot of time with a bunch of different editors trying to figure out like, "What are the things that are supported by those? What will ensure a great developer experience and then design everything around that and the standards?" I spent a lot of time figuring out how it would feel about working with FastAPI before building FastAPI.

The next thing was I contributed some PRs to Python. FastAPI is built on top of Starlette, which is this framework from the same avatar of Django REST framework. That is a very high-performance low-level toolkit. The other component of FastAPI is pydantic, which does all the data validation. Pydantic is based all on type annotations.

I wanted to have all of that. It's the same type of annotations that we already know. I wanted not to import some framework-specific class to define strengths when Python already has a way to annotate a variable as a string. I wanted to reuse all the information to make it super simple and have a standard Python code.

Certainly, it has a lot of extra features by using standard Python code with standard annotations. I ended up adding a couple of PRs to make it compatible with JSON Schema and a couple of other things. I integrated with Starlette and put them together with FastAPI, with all the open API support and dependency injection system, which allows simplifying a lot of the code and things like authentication, handling data, and a bunch of these things.

It was a lot of training on how to build up that framework. At some point, there were no other options to try. Let's try this and see if it works. It was solving a problem, not just for me but also for a lot of other people. It's having like a lot of adoption. That's awesome. It's also like Flask or Django, or even many others were designed in a time where the common way to build this framework was to render and generate HTML. Send it to a front end, and to have very tight integrations with, for example, databases or things like that, at least in the case of Django. It was the sign-up for a common use case at the time.

It's a lot more common to have APIs that communicate with a front end that is probably written in some framework, like Angular or React or DJS or something like that. Probably even TypeScript with a bunch of tooling and all that stuff. The backend ends up having to have a little more focus on building APIs that have all the best practices for APIs.

The other thing is that all these frameworks and tools didn't have the chance to use AC. They couldn't take advantage of these new features. What I did with FastAPI was take all the learnings from all these previous tools and frameworks, all the things that I liked from each of these tools, and try to combine them the best way that I can think of. Building APIs with best practices by default makes it super simple to write a code and have very good performance for the community.

There are two things here. The first is timing. For you, it couldn't exist before, like 3.6. It's a question of timing. It's common to use data stores that aren't sequel-based now. Django is very tightly tied to SQL itself. It's interesting because Flagsmith is written in Django and Django REST Framework. We're building out a big feature around a distributed API, like a global API. We're using a different data store. That's hard and painful to do in Django. We have to put a bunch of code out. Also, you're building on top of these other projects that provide so much of a platform for what you're writing.

FastAPI is built on top of the shoulders of giants. Starlette was built by Tom Christie, who is the same author of Django REST Framework, the same author of Uvicorn, which is the high-performance web server for these frameworks. He has a huge amount of experience. I'm leveraging that and pydantic. What software has been used before I adopted it?

Pydantic has a lot of features. The simplicity of using it as a developer is amazing and mind-blowing, but the internal code is one of the most complex codebases I have seen. It has to do all of these sophisticated tricks to be able to provide that simplicity for the end-users. It's on top of these giants of all these learnings from previous tools.

You're stretching the language at that point. It's now more designed to do. It's one of the reasons that people like it, but it can be difficult to do things, maybe in JavaScript or something that would be much easier. Putting it in directions that it maybe wasn't designed for.

Python is so huge. It's used for so many things. All the corp developers, for example, have no way to know all the possible fields where Python is used. They have no way to know all the frameworks and tools that Python is used. Python is leveraged in different ways. A change was expected to happen for Python 3.10 that would change some of the internals of Python and how these annotations work that wouldn't affect normal developers. They will affect some specific corner cases. I don't think I've been, and so I said, "Yeah." We didn't realize that on time because the change was waiting to be accepted for three years.

We realized at the last minute that this thing would affect a bunch of these used cases. Python is used by a lot of people. It probably will be better not to affect those used cases. It would still work, but there will be some caveats on paper, especially for new users trying to do something that seemed natural but was not supportive.

In the end, the key stakeholders or the key people that decided the future of Python decided to take that back and revert the change that was already accepted by contributing, to give us all time to figure out how to handle these things while still supporting these used cases. It's precisely because we are taking advantage of this type of annotations for more than what they were designed for.

They weren't designed for leaders and editors to be able to get errors and provide out of the completion of this stage. We are using them on top of that, which is the default. We are using it for doing data validation, data serialization, documentation, and in some cases, they can filter out. It's a lot of features packed into a very simple part of the syntax of the language.

We're thinking of the advantage of it. It has been quite useful for a lot of people, but there are also similar people who didn't even think that was a reasonable use case. It has proven to be very useful for other people. I'm pretty sure it was quite painful for the same person for all the more they had to do to revert what was already accepted. I feel they have a huge commitment with the Python community to make the decisions that favor all the community and to help all the different used cases to be able to be successful with Python even when that comes with difficulties.

This is a common story as well that you built it because you'd exhausted every other revenue, and you're like, "I need to build this now." You built it for yourself, but did you have a desire and a goal for 31,000-star projects on GitHub? When you pushed the first release to GitHub, did you think like, "I'm now going to go on Hacker News, Twitter and Product Time and all this stuff,” or were that not in your mind?

No. At that time, the most popular thing I had was Docker images for Flask and Django. In many cases, they were the de facto standard for looking at images for these tools and the communication for platforms. Several of these cloud platforms suggested using these images, which was the biggest thing I had. One had like 1,000 stars or something. I was so proud of it. I was hoping like, "Maybe these will get 50 people to come and start and say like, “This is maybe an interesting idea.” That was what I was expecting. I was hoping that it would be enough for people and companies to use it and for me to be able to keep using it because I enjoy the experience of working with it.

I started using it at the company I was working for and with the team that we're working. I enjoyed it. I'm wondering not to because I felt the user experience improvement was quite interesting. I share it in a couple of places and forums. It seems people liked it and the idea. Other people were hoping to see something like that would probably help realize how to do it. I never expected it to be this big. I thought that they would be one of these hipster neo frameworks that some weird startups use. Now in the latest vital developer survey of 2020, it was the third most used framework. It only has a few years of existence. The growth has been quite strange to me.

If we were starting Flagsmith now, I'm almost certain that we'd build it on FastAPI because the things that we cared about and needed were exactly what you described, like a REST API that doesn't serve server-rendered HTML because it doesn't need to and asynchronous performance. At the time, we started, and it was like, "We'll build it in Django and Django REST framework," because at the time, it was like a side project for the agency that I was running. Django and Django REST Framework are brilliant. I love both the products and the platforms, but there's so much magic going on if you look at the code now.

I don't work on the code that much anymore. I'm scared to do anything with it because there's so much magic going on behind the scenes. If you're not in complete control of it, the code can be quite hard to read. It's interesting. We need a REST API that was auto documenting, and has had some authentication built-in itself.

We also need to be serving thousands of requests a second because of the nature of the product. FastAPI would be the perfect solution for us. We're tied onto Django and DRF now. We need to build another side project, so we can start using it. Did the stars trickle or an after-launch straight away, the adoption, the success of the platform?

The first place where I thought about it was an issue in Starlette saying, "I know you built API Star and closed it. I want to build it again on top of Starlette. Would you want it to be part of Starlette or should I go outside?” It's like, "Let's get Starlette this core thing. You can build whatever you want on top of it. I will do it in my home." When I released it, I shared it there on Reddit and Hacker News.

The Hacker News algorithm is smaller than you.

It's very strange because I have shared the rest of the right space. It's quite useful and something that takes off, or it doesn't matter at all in Hacker News. I find it funny. It was quite popular on Hacker News and Reddit and that brought 500 stars or something like that. Some people knew about it, but then the rest of it was people sharing it with others. It has been growing linearly, like 1,000 or so and there was probably a bit more. It's like 24 months and has 30,000 stars. It has been people who share it with others, and they like it.

They go to other people and end up with other ideas. It's also that people like and try it. When they try it, they see what it does, and it's been and feels like to use it. They see the features they get. It's very quick to realize if you like it or not. I feel like people like it. They re-like it and read the recommendation, and they like it. They end up liking it a lot.

It's not like, "It's an okay tool," but they like it. That helps them spread the word, and other people end up liking it too. In the beginning, I probably spent more time writing marks down than Phyton because I wrote a lot of the commendations and I try to explain everything. For me, documentation has been one of the key components.

Yes, 90% of the time that I'm committing stuff to Flagsmith now is marked down.

I'm not alone. In many cases, it's like writing the whole thing, rereading it, removing a lot of stuff, and then reading it again and fixing stuff. It's like refactoring with markdown. I feel like that improves that rotational load, and people like it. They can get all the information they need. That also helps a lot in the spread of the adoption. It's easy to start using and enjoy it.

Is it just you that is in control of the project now? Who can commit to master, for example?

It's mainly me. If you check out the history, most of the core of the gold has been by me. Some people have made some great contributions and had great ideas. There's a particular bunch of people that help out a lot with issues and helping other people. It's like, FastAPI, Async, Python, and stuff. To see, the task that takes most of the time is replying to other users about their questions.

That, in many cases, is something that is written in the documentation or a bug in their own code. That's the majority of the cases. That's also the reason why I disabled the template to create a bug because people were creating a bug to say, "There's a bug in their code." They must have recommended like, "Don't this or do that," but there's a bunch of people that help a lot with those questions and help others.

That helps me a lot and saves a lot of time. That's also why I created the FastAPI People, which is a section in the documentation where I have the FastAPI experts. These people have helped others. It's a small reward for those spending so much time helping others and showing that they are experts in the topic because they are able to solve other people's problems.

Not even just their problem, but also other people's problems. That's one of the things that helps me, and the community contributes the most, and translations. I only speak a couple of languages. There's a lot of people contributing translations. Others come and review it and approve it. I can merge it. That's something that is quite purely a community effort. For the rest, it's me.

How do you manage your time? How do you not feel overwhelmed by 277 pull requests?

I don't manage my time. I quit my job. Thinking of all the occasions I have and now I'm already out of the previous company I was working for to be able to dedicate a high percentage of my time to these software products, FastAPI, and a bunch of strikes. I'm going to be taking in a lot more time to that. On the side, doing some consultancy for some external companies on some teams that help with the same decisions. I said, "You're the infrastructure or whatever." It's quite difficult to handle because it demands a lot of work and doing it mostly on weekends. It's not sustainable. That's also why I'm switching all of that right now to be able to grow it faster.

Most of the people that I've been speaking to are working on projects that have an obvious commercial angle to them and that they can sell like Flagsmith might sell on-premise or SaaS or something like that. For something like a web framework, that's close to impossible. How have you gone about to be able to make a living doing it? For a lot of people, it's a holy grail of being able to work on this stuff and make a living doing it. For a project that's not able to sell a SaaS version, has that been hard and challenging?

Yeah. There's no straightforward way to solve it. For example, I admire what they did at Explosion, the company I was working for, because they are the creators of spaCy, the natural language processing package that is open source. It's super popular. It has a great recommendation, free, and everyone can use it. They have a bunch of pre-trained models that everyone can use.

On the side, they have a commercial product that is the data annotation tool, Prodigy, and that is what they said. This tool, Prodigy, can integrate well with the open-source project spaCy. It's made to be able to integrate well with spaCy. It's a defined commercial product that compliments the open-source side but doesn't conflict with it.

That's amazing because they don't have conflicts of interest. They want to have as much adoption of spaCy as possible that they want to have the best documentation as possible because that brings more people that see like, "We can also use Prodigy." That makes them make spaCy awesome. I had seen similar companies that ended up having a model that is strongly based on support. They ended up preferring not to have good documentation so that people would pay for support. I don't like that. It's completely a difficult decision and a difficult thing how to solve.

I'm not building a company. Some VCs, similar companies have approached me. I'm like, "You should probably build that company right away." Now I don't want to build a company, at least not yet. I want to focus on the source side and the objectives I have for FastAPI. My main objective is to help a lot of teams be able to build products easily, fast and serve their local communities. It's something for the local communities and society to help a lot of people be able to be a little more productive. That's my main idea. I want to focus on that. On this side, I can do some consultancy with companies that already have a lot of the time booked up.

They helped me realize that we do to continue if there's some pattern or something that I can build that will compliment FastAPI or make sense. This is probably working well for now. FastAPI has this massive adoption that is a bit strange. Something will end up happening. I will be building something at some point, but for now, this works well enough.

If you had to go out to the community and say, "I want to do this as a living. It would be great if you're a large company making a product on top of it to sponsor me," or have people come to you and said, "We'd love to sponsor you?"

For example, I enabled it for sponsors as far as like, "You can get me a coffee if you want," but I didn't even promote it anywhere. It was like hitting all my GitHub profiles, and a bunch of people ended up coming and saying like, "I want to sponsor you. Can you work on this?" At some point, a very simple cloud provider that simplifies a lot of the work came and say like, "We want to sponsor you, but a bigger tier. We want to have a patent on the thing. Can we do this?" They were the ones to propose that. That's why I started with all the tiers of sponsorship.

For example, for that side, it's people that have ended up approaching me. On the consultancy side, it has been only people that have contacted me. I have received a bunch of offers and stuff. I feel they're people working with FastAPI or these tools and people interested in me also working on the open-source side. I'm also dedicated to that. They get a lot of my working time to FastAPI itself. That will benefit them because they are using it. At the same thing, it's quite strange and unbalanced because in many cases, companies that are not necessarily the most popular ones are the ones that are willing to sponsor, or work, or do something.

On the other side, there are huge companies that are using FastAPI internally. For example, I noticed that many of these companies are using FastAPI because someone else sent me the link, "They announced this blog post, Netflix or Uber or so-and-so are using FastAPI." There's a lot of people using FastAPI that I don't even know yet. There are strange interactions that are quite different from what I will have expected. When I was starting to develop, I was saying like, "There's this thing that is called open source." It's funny to see.

We got a password reset request from someone in a massive company who I won't name. We were like, "We don't know who you are." They'd been running the platform internally, and the person didn't realize. They contacted us to ask for a password reset. We're like, "I didn't know you were using the platform." It's interesting as well because we put in basic telemetry, anonymized telemetry into the platform. The other people I've been speaking to on the show who have got a product at that level, which is going to have a much higher level than a web framework, is acceptable. You can't do that as a web framework.

It wouldn't be acceptable in all my cases, which is something that is so low level. Some people have asked me also like, "Why don't you do that?" I would like to see how people are using FastAPI and also building FastAPI myself. I'm creating and deciding what to change, deprecate, features to add. If I don't have the feedback from the organizations using it, I will build up building to whatever I see. I have been working with a lot of projects in a lot of different areas with matching learning and through applications and a lot of well reasonably in a previous computer vision and on a bunch of things and pure databases and no sequel and sequel.

I can try to figure out the best way to improve it to all the used cases that I have seen, but I have no way to see all the ways that FastAPI is being used. I know there are companies, organizations, or even projects that are using it for things that I wouldn't have imagined they were using it. I remember that there was a project that was using FastAPI with web sockets to share an SSH conation via the browser with real-time interactions. I was like, "This is cool. I wouldn't have imagined that." Some people control sensors and stuff. I feel it's quite strange because it will help me a lot to have that feedback, like, "How are you using it? What is your used case? How can I improve FastAPI itself?"

Is it just you making these design decisions? How do you decide whether to add a new feature or a merger pull request?

It has been mostly me. That's why it takes me quite some time to accept or reject a pull request because, with every pull request, I check it very thoroughly. I check all the ideas and decisions. I'm like, "What will be a simpler way to do it?" There are many cases where it will have been simpler for me to be like, "Take a feature, request, and build it from scratch." I also want to appreciate all the effort the community's making to help. For example, there was a feature request about supporting some extra features, but I ended up checking, like, "What is the difference between one standard open API?"

JSON's came up with the new version of open API, the new version of JSON Schema, and the modifications that previous versions of the older. It gets quite complex and the ways that these things interact with each other. I spend a lot of things stalling them to figure out what will be the best way to lead. In some cases, I have some great ideas from the community and some people that say like, "Maybe this could be improved here or there." That's mostly how we build. In most cases, it's mainly me deciding what will be the best approach to solve it.

Do you think that's one of the reasons that it's been successful? You've got a vision for it. You're happy to try and execute on that. Have you considered a different way of doing that or not?

I have considered it. At some point, it will be that, but I still have so many ideas and things that I want to improve and change and update. I want to make sure that I can execute them in the best way I can because up until now, that has worked quite well. If you check the call within the connotation and the big jump, I don't know, 90% or something. I have worked quite well. I want to exploit that as much as possible.

I like to do as much as I can and they probably figured out other ways that I could manage it. It's fun because FastAPI is already using production in a lot of places in-house, with a lot of features, but I still have a quite big backlog of the things that I want to improve and add. I want to be able to do them in the best way that I can imagine doing them.

For now, I will keep the structure. I have the advantage of being able to work with many different technologies, teams, and skillsets throughout the years. I had the chance to try many different frameworks, tools, connections, databases, architectures, and ways to deploy. That has given me a lot of perspectives to figure out a way to optimize for all those different types of developers and firms, which are not all of the brothers and developers available and existing. It's a fair trade.

In terms of version upgrades and stuff, how did you do that? Rails, for example, are famous for having quite large jumps in the code and the APR surfaces between version changes. Are there any things that are in very early commits and designs of the platform that you're like, "I wish I hadn't done that? I’m saddled with it, and I don't want it to make it too hard for people to upgrade the platform and stuff like that?"

Not too much because I spent a lot of time redesigning the whole thing and figuring it out like, "Is this the best way? What else can I improve? How else can I change it?" I feel like the design is quite useful and well done, also because I'm optimizing some specific features like having able to complete and type annotations. The code is as simple as possible. There's almost no duplication at all needed of anything.

When you use a different framework or a combination of different tools, it's very common to need to say, "This is a string in someplace." Another place where you have to say, "This is a string in the recommendation or for validation." I need to have this extra recommendation for this specific parameter that I already declared somewhere else with this name. All of that is reduced to the minimum with FastAPI and the design that is there.

I have a clear intuition of the list of priorities that I want to optimize on how to do it. It has been working relatively well. It's funny about the pressure of migrations because FastAPI right now, being the third most used framework, is still zero-point something. I hadn't released version one because I wanted to wait to have version one from Starlette and Uvicorn and all the main features I wanted to do. They're established and working well.

Despite that, I still have a strict policy for doing a release, it's not because it's a still upon something, but it's similar as if it was semantic versioning. I don't see a way that it will change a lot from one version to the next. It's easy to upgrade from my Version 2. If people have this, they will spot the right places where things need to be changed and where things need to be updated. Despite being in this stage, I'm already having a lot of stuff for backward compatibility. I had several versions and a bunch of stuff for backward compatibility with pydantic.

It was 0.78, and then they released one, and some things changed there. I kept a lot of compatibility layers to be able to support for quite a while. I have tried to make it as simple as possible to operate and to keep updating the versions. FastAPI's components are quite simple. For example, it doesn't have an ORM as part of the framework. The API standards are also quite well-defined. There's not a lot that will need to change over time.

Are there any major features that you've got in mind? Do you feel like you're done from an actual features point of view?

I have quite a list of different things I want to do. I want to improve a lot of the stuff around authentication and integration with our school. Even though I have quite some documentation around the item, I won't cover all the possible cases. I'm going to cover more of that. I will probably explain more about all this, too, I feel like there is no clear place where all we do is explain that the standard is complex to grasp. Maybe I could explain the ideas repair and simplify the way that these tools are going to whisper. That's one of the areas.

I do want to build several side projects or complementary projects. I already set and have some lab material combining Python with SQLAlchemy to reduce the duplication of code when using SQL databases and make it based on type annotations and make it super simple to use while still using the most common commonly used Angular or SQLAlchemy.

I also want to work on a front-end component to make an automatic admin user interface based on an open API independent of the database. One advantage of Django is when you have all the pieces tightly coupled, you can make assumptions about all those basics. You can assume that you will have this specific database and types of authentications. You can make up a front-end user interface that connects to that, assuming that it will be using that.

In FastAPI, there is no specific database and authentication because it supports many types of authentications. I want to build something based on top of the standard for the ATS and another on top of internal FastAPI. It will probably not be as for the alternative that is connected to the database directly, but it will help with some of these used cases.

For the cases where people need another user interface for the database itself, there are a lot of packages for the database ORM itself that provide that functionality. I don't know. I also want a bunch of features, and also for Typer. The other project that I built does more or less the same idea, design, but for building common dining interface applications. It's built on top of Click, but it's all based on annotations. You write normal code, and it's converted to a common dining interface application. With Typer, I want to add a bunch of features, optimizations, and improvements as well. That's more some of the big chunks of the roadmap for me now.

There's still quite a lot of code to write. Are there any people or projects you want to say hello to or thank or tell our readers about that might be interesting?

There's probably more than I will remember. If you go to the recommendation of FastAPI, there's a section about alternatives and inspiration. There's a long list of different frameworks, people, and tools that FastAPI was learned from and inspired FastAPI. There's a lot in there. Some of the other people on this show are FastAPI experts that help a lot with questions and help others because they're all entirely helping us with full of kindness and are great.

The building blocks of these tools are Tom Christie, Samuel Coping, and the whole vital community letting us use and improve all these tools and things that, in a way, we can keep fostering all these communities that are built around Python with all the diversity that Python already has. There's a lot of people to thank. Those are some of the first ones, at least that comes to mind.

I'm looking at your documentation. You've got a huge amount on the design, and the external links are interesting to see. I've not seen that before. That's like a curated list of things, which is cool.

Essentially, there's a lot of articles and blog posts, and also, people like Michael Herman have an awesome list of FastAPI. You can get them. There's also a bunch of other additional tools and articles. FastAPI is built on top of the new standard for Python web frameworks based on AC Conway that is called ASCII. There's also the ASCII awesome list, which is from one of the core developers of HTTPS. He had me contributing to the same community. HTTPS is also by Tom Christie, which is the same as Starlette. In these same areas, combining this goes together. That's a very good resource as well because FastAPI is based on ASCII.

Anything that supports ASCII is already usable with FastAPI. It's not like there's a need for a lot of logins that are specific for FastAPI. In most cases, you can import the package for doing whatever you want to do, for doing cryptography, databases, whatever, or using it directly. When you need to have some type of integration, for example, with databases to have sessions, then you can use the integrated dependency injection system in FastAPI to connect them. For example, using Sanctuary is super simple or using different databases, or using monitoring tools. ASCII is a useful resource.

Sebastian, thanks so much for your time. Thank you so much for the project. I'm annoyed now that we can't use it. We need to start a new side project.

That's also one of those frequent questions, like, "Should we switch to FastAPI now?" I'm like, "It's not necessarily like that." Whenever you have a product working with Django, an old tool, and for example, if he doesn't need any new features and it's already stable, there's no need to switch to FastAPI. If you want to have the additional benefits, tools, or performance or the additional features, a good way to do it is to add little features of the same API that you already have. Migrate only a little piece of the API, only the section about items. I keep the users on the dealer site, and it's easy.

For example, with FastAPI, it's very easy to generate a single alchemy for the same you have in general and then use the same authentication you already have in Django. I have it documented on there. I forgot the name of the package for doing that, but then they have the same algorithm that Django uses. You can have the same database used by both Django and FastAPI.

There are some additional black magic cases where people have integrated Django over and directly into FastAPI, but that's more probably tricky. I would suggest if you want to try FastAPI, the first page with 10 or 15 minutes, you will know if you would like us to get it or not, but then if you want to migrate, I would suggest doing it gradually.

You were having a fronted proxy like traffic or engine, some specific area of the FastAPI, and the rest of the framework you already have. You can migrate and have features on top and make it very easy. That's a good approach. That wouldn't have that friction as well. Django has a lot of features on a lot of things that we would probably want to keep in many areas that you would want to. It will probably shine in many other areas. That's a good way to do it and see how much do you like it.

We have one part of our platform that gets a lot of traffic, and then most of it doesn't get so much. I did find some people who'd integrated FastAPI into a Django project where they need it, like the raw and the asynchronous performance. Maybe we will be asking questions about your project. Thank you again for the project. Congratulations on resigning from your job.

Thank you very much. Thank you for the invitation. That's a fun thing to congratulate.

Good luck in the future.