5 Things weve learned building large APIs with FastAPI - Maarten Huijsmans

In this talk we explore some of the common challenges in building FastAPI apps, and share how we solved them: 1. Minimizing the global state with dependency injection 2. Reducing the complexity of testing a FastAPI app 3. Pitfalls of async FastAPI 4. Supporting multiple authentication schemes 5. Modeling the relations between patch, response, and database models … {ts:237} there because fast API itself is defined in the global State um why is the bad practice it's pretty hard to patch um in unit tests for example or if you want to um have access to the global State you have to import it from another file you easily end up in circular dependencies {ts:255} or inline import statements and the moment you start doing that you should know that you're doing things wrong like I did um so I had to read a little bit of documentation and change some codes um so what is the most easy solution um for avoiding a little bit of global {ts:273} state is make that connection in your endpoint this is also okay but the downside of this is that when you're connecting to a database um these clients usually have um connection pools so if you do this what you see here um you don't really use the connection pools because you're always setting up {ts:292} the database connection when there is an incoming request so this is not super efficient either um so so the thing is um fast API has a mechanism called dependency injection if you know a little bit of spring in Java you're familiar with the dependency injection mechanism um in Python is not really common but fast API adopted the … {ts:1218} um with dependency injection this is the part that I struggled a bit with um because in the last function you see okay we want a user so we inject that user and then on uh above that function you see we inject the odd scheme and then the odd scheme tries to fetch uh {ts:1238} the fake decode token tries to fetch a user from the database um the big downside I see here or that I experience here is that you have to do that on every endpoint that you write so it's a lot of duplication of codes um that's the first thing I I dislike a bit and {ts:1255} the second thing I struggled with is if you want to support two authentication schemes you have to basically write it like this you try to fetch a JWT token or an API key but the problem is that if there is no JWT token present the first statement will already fail so it {ts:1275} basically becomes an end operation so they both have to be present you can solve this in an easy way by making both of them um not F like make them both fail silently um like setting Auto error to false but then you're actually … {ts:1461} code um but what were the issues we had with this is that um yeah the BS become hard to to read um and um if you want to change the API contract we couldn't um unless we did the database migration and the other way around if we want to change a model a {ts:1481} field in the database which then automatically reflects into a breaking change in the API contract and our apis are exposed to our customers or to our clients and you cannot easily make um you cannot EAS break your contract