Is Your FastAPI Code a Mess? Use This Architecture Pattern

Key Takeaways

Hey, welcome back. So far current entire API lives in one file. That's fine when you have three endpoints, but his rag API now has injection endpoints, query endpoints, session management, config, and it's all growing. One file become impossible to navigate very quickly. In this video, we look at API router, fast API's ways to split your application into clean organized modules. Let's get into it. Look at Karan's main.py. Nine endpoints already and the comment at the top says it all. Getting out of control. Three injection endpoints, one query endpoint, three session endpoints, two config endpoints, and it's still growing. The warning at the bottom captures the problem perfectly. Too many endpoints in one file, hard to navigate, hard to test, hard to scale. If a teammate wants to work on sessions while Karan works on injection, they are both editing the same file. The fix is API router. API router is a mini fast API app for a group of related endpoints. It works exactly the same way as app. Same decorators, same depends, same response models. The only difference is it doesn't run on its own. It's get registered into main It's get registered into the main app. Look at the Swagger UI on the right. Notice how endpoints are grouped by tags, users, items, customs, admin. That's exactly what router gives you. Each feature groups has its own section in the docs. Clean, navigable, and easy for any team member to find what they're looking for. So, creating a router takes three steps. Import API router from fast API, create an instance with a prefix and a tags, then define endpoints on its using at the rate router instead of at the rate app. Everything else stays identical. Look at the code. The router has prefix /documents and tags as documents. That means at the rate router.post/ingest becomes post/documents/ingest. And at the rate router.get document ID becomes get/documents /document ID. You set the prefix once on the router and every route inside it inherits it automatically. The dependencies works exactly the same way. Verify API key and the dependencies works exactly the same way. Verify API key and get DB are injected the same way they would be in main.py. And registering routers in main.py is three lines. Import each router module, create the app, call include router for each one. That's it. FastAPI registers every endpoint from every router automatically. Look at how clean this main.py is. No Pydantic models, no dependency functions, no endpoint logic. Just the app and three include router calls. This is what main.py should always look like in real project. An assembly point, not a place where business logic lives. So, this is what current's full projects looks like with everything properly organized. Main.py handles app setup and router registration only. Dependencies.py holds all shared dependencies, authorization, DB, LLM client. Database.py handles the connection setup. The routers folder The routers folder has one file per feature, documents, sessions, config. The models folder separate request and response Pydantic models into their own files and .env at the bottom holds environment variables, which we will cover in the next video. Every file has exactly one job. When something breaks, you know which file to open. When you add a feature, you add one router file and one include router line. That's the structure you want. So, a quick recap. API router lets you split your FastAPI application into clean feature modules. Set a prefix on the router and every endpoint inside it inherit it automatically. Register everything in main.py with include router and keep main.py clean. It should only assemble the application, not contain any endpoint logic. The next video, we tackle settings and environment variable. Right now, Karan has API key and database URL hardcoded or sitting in random places. Pydantic settings gives us a clean, type-safe way to manage all of that. See you there.