Hi, I’m Fast Eddy! As a backend web developer who spends most of my time with FastAPI, I’ve learned that maintainable, scalable project structure is the foundation of any robust API. Let’s break down how you can structure your FastAPI projects so they remain clear, scalable, and ready for growth—whether you’re working solo or leading a larger team.

Why Project Structure Matters

FastAPI makes it super easy to spin up endpoints fast. But as your project grows, you’ll quickly hit organizational hiccups if you stick with the default, single-file approach. Taking a bit of time to set up a thoughtful structure upfront can save countless headaches (and refactors) later.

Common Project Structure

Let’s look at a directory layout that works well for most mid- to large-sized projects:

myfastapiapp/
│
├── app/
│   ├── __init__.py
│   ├── main.py            # Application entrypoint
│   ├── api/               # Routers and API logic
│   │   ├── __init__.py
│   │   └── v1/
│   │       ├── __init__.py
│   │       ├── endpoints/
│   │       │   ├── __init__.py
│   │       │   ├── users.py
│   │       │   └── items.py
│   │       └── dependencies.py
│   ├── core/              # Core app configs, settings, security, etc.
│   │   ├── __init__.py
│   │   ├── config.py
│   │   └── security.py
│   ├── models/            # Pydantic and ORM models
│   │   ├── __init__.py
│   │   ├── user.py
│   │   └── item.py
│   ├── crud/              # CRUD operations, DB logic
│   │   ├── __init__.py
│   │   ├── user.py
│   │   └── item.py
│   ├── db/                # Database session, metadata
│   │   ├── __init__.py
│   │   └── session.py
│   └── utils/             # Utility/helper functions
│       ├── __init__.py
│       └── email.py
├── tests/
│   ├── __init__.py
│   ├── test_users.py
│   └── test_items.py
├── alembic/               # Database migrations (if using Alembic)
├── .env
├── requirements.txt
├── Dockerfile
└── README.md

Key Principles

1. Separation of Concerns:

• Keep endpoints, business logic, and data models in their own modules.
• Avoid massive files that conglomerate unrelated logic.

2. API Versioning:

• Nest endpoints under /api/v1/ (and so on) directories from the start. This simplifies future upgrades and backward compatibility.

3. Dependency Injection:

• Place shared dependencies (auth, DB sessions, etc.) in dedicated dependencies.py files.

4. Config Management:

• House settings and startup logic in core/ for better organization and single sourcing of truth (read more in my previous article: "Managing Environment Variables in FastAPI Applications").

5. Utility Layer:

• Utilities or helpers go in a utils/ folder to keep business logic clean.

Practical Example: Adding a User Endpoint

Suppose you want to add /users endpoints. Here’s what you’d do:

• Create a users.py file under both models/ and crud/ for the schemas and CRUD functions.
• Add endpoint logic to api/v1/endpoints/users.py.
• Route all /users requests from your main router file (api/v1/__init__.py).
• Wire up dependencies in api/v1/dependencies.py as needed.

Scaling Up

This structure supports the addition of:

• More teams or developers (clear file boundaries help code reviews and onboarding)
• New API versions
• Plugins or third-party integrations
• Automated testing in the tests/ directory

Summary

Properly structuring your FastAPI application sets you up for easier maintenance, painless scaling, and happier developers. A clear directory layout is the unsung hero of a project’s success.

Have your own best practices or run into structure headaches recently? Share your thoughts below or ping me on Dev Chat!

— Fast Eddy

Hi everyone! Fast Eddy here. Today, I’m tackling an important topic that every API developer needs to consider: how to implement rate limiting in FastAPI applications. Without proper rate limiting, your API could be susceptible to abuse, accidental overload, or even denial-of-service attacks. In this article, I’ll explore some effective strategies and walk through a practical implementation so your FastAPI APIs stay performant and healthy.

Why Rate Limit?

Rate limiting restricts how often a client can call your API endpoints during a given timeframe. Reasons to implement rate limits include:

• Protection from abuse: Prevent malicious users from flooding your API.
• Fairness: Allocate resources equitably among all users.
• Capacity management: Keep backend services stable and responsive.

Common Rate Limiting Strategies

1. Fixed Window: Allows a certain number of requests per fixed period (e.g., 100 requests per minute).
2. Sliding Window: Offers a smoother rate limit calculation by sliding the window over smaller intervals.
3. Token Bucket/Leaky Bucket: Provides more flexibility, letting traffic burst up to a point while maintaining an average rate.

For most use-cases, the fixed window is simple and effective, so let’s see how to implement it in FastAPI.

Implementing Fixed Window Rate Limiting with FastAPI

While FastAPI doesn’t have built-in rate limiting, you can easily add it with middleware or dependencies. For demonstration, I’ll use the popular slowapi library, which integrates seamlessly with FastAPI.

Install Required Packages

pip install slowapi

Basic Setup

from fastapi import FastAPI, Request
from slowapi import Limiter, _rate_limit_exceeded_handler
from slowapi.util import get_remote_address
from slowapi.errors import RateLimitExceeded

app = FastAPI()
limiter = Limiter(key_func=get_remote_address)
app.state.limiter = limiter
app.add_exception_handler(RateLimitExceeded, _rate_limit_exceeded_handler)

@app.get("/resource")
@limiter.limit("5/minute")  # Limit to 5 requests per minute per IP
async def resource(request: Request):
    return {"message": "You have access!"}

Key Points:

• The Limiter uses the client’s remote address by default.
• The @limiter.limit decorator specifies the allowed rate (e.g., 5 requests per minute).
• If a client exceeds the limit, a 429 Too Many Requests response is returned.

Customizing Limits

You can also set different limits for different endpoints, or even impose user-specific limits if you have authentication and unique identifiers.

@limiter.limit("10/minute;100/day", key_func=lambda request: request.headers['X-API-KEY'])
def user_specific(request: Request):
    # Get user from API key, for example
    ...

Best Practices

• Communicate limits: Include proper headers (like Retry-After) to inform clients of rate limits.
• Backed by external storage: For multiple server instances, persist rate limit counters in Redis or similar.
• Monitoring: Log and monitor rate limit events for insights and security.

Conclusion

Rate limiting is a must-have for any production API. With FastAPI and helpful tools like slowapi, implementation is straightforward. Protect your service, ensure fairness, and keep things running smoothly!

Let me know your favorite approach to rate limiting, or if you have other FastAPI tips you want to see next!

Happy coding,

Fast Eddy