
Fastapi Project Structure
- 1 installs
- 4 repo stars
- Updated April 1, 2026
- ag2ai/resource-hub
fastapi-project-structure is a Claude Code skill that defines a standard directory layout and module organization for FastAPI applications.
About
This skill defines a standard directory layout and module organization for FastAPI applications. It lays out app/ with api, models, schemas, deps, services, and db packages, plus tests and Alembic migrations, and shows key files like main.py, the v1 router, config, and a DB session dependency. A developer uses it to scaffold a FastAPI project with clear conventions such as keeping ORM models and Pydantic schemas separate and moving business logic into services.
- Standard directory layout and module organization for FastAPI applications
- Separates api/models/schemas/deps/services/db plus tests and alembic migrations
- Enforces thin endpoints, versioned APIs, and Depends()-based dependency injection
Fastapi Project Structure by the numbers
- 1 all-time installs (skills.sh)
- Ranked #3,830 of 4,347 Backend & APIs skills by installs in the Skillselion catalog
- Data as of Jul 28, 2026 (Skillselion catalog sync)
fastapi-project-structure capabilities & compatibility
Free; a reference/template skill with no API key.
- Capabilities
- api scaffolding · backend architecture · project structure
- Use cases
- api development
- Pricing
- Free
What fastapi-project-structure says it does
Standard directory layout and module organization for FastAPI applications
Never put business logic in endpoint functions. Use services.
npx skills add https://github.com/ag2ai/resource-hub --skill fastapi-project-structureAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1 |
|---|---|
| repo stars | ★ 4 |
| Last updated | April 1, 2026 |
| Repository | ag2ai/resource-hub ↗ |
What it does
Scaffold a FastAPI application with a standard api/models/schemas/services/db layout and versioned routers.
Who is it for?
Developers scaffolding or organizing a FastAPI backend with clear separation of routers, models, schemas, and services.
Skip if: Non-FastAPI frameworks or frontend structure.
When should I use this skill?
The user is starting or restructuring a FastAPI project and needs a standard layout.
What you get
A versioned FastAPI project with api/models/schemas/deps/services/db separation and thin endpoints.
- FastAPI project directory layout
- router, config, and dependency conventions
By the numbers
- 5 rules in the Rules section
Files
FastAPI Project Structure
Standard Layout
project/
app/
__init__.py
main.py # FastAPI app instance and lifespan
config.py # Settings via pydantic-settings
api/
__init__.py
v1/
__init__.py
router.py # Aggregates all v1 routers
endpoints/
__init__.py
users.py
items.py
models/
__init__.py
user.py # SQLAlchemy / ORM models
item.py
schemas/
__init__.py
user.py # Pydantic request/response schemas
item.py
deps/
__init__.py
database.py # DB session dependency
auth.py # Auth dependencies
services/
__init__.py
user_service.py # Business logic
item_service.py
db/
__init__.py
session.py # Engine and session factory
base.py # Declarative base
tests/
__init__.py
conftest.py
test_users.py
test_items.py
alembic/ # Database migrations
versions/
env.py
alembic.ini
pyproject.tomlKey Conventions
app/main.py -- Application entry point
from contextlib import asynccontextmanager
from fastapi import FastAPI
from app.api.v1.router import api_router
from app.db.session import engine
@asynccontextmanager
async def lifespan(app: FastAPI):
# Startup: create tables, init connections
yield
# Shutdown: close connections
await engine.dispose()
app = FastAPI(title="My API", version="1.0.0", lifespan=lifespan)
app.include_router(api_router, prefix="/api/v1")app/api/v1/router.py -- Aggregate routers
from fastapi import APIRouter
from app.api.v1.endpoints import users, items
api_router = APIRouter()
api_router.include_router(users.router, prefix="/users", tags=["users"])
api_router.include_router(items.router, prefix="/items", tags=["items"])app/models/ vs app/schemas/
- models/: ORM models (SQLAlchemy). Represent database tables.
- schemas/: Pydantic models. Represent API request/response shapes.
Keep them separate. Never return an ORM model directly from an endpoint.
app/deps/ -- Dependency injection
Place reusable dependencies here. Common patterns:
# app/deps/database.py
from collections.abc import AsyncGenerator
from sqlalchemy.ext.asyncio import AsyncSession
from app.db.session import async_session_maker
async def get_db() -> AsyncGenerator[AsyncSession, None]:
async with async_session_maker() as session:
yield sessionapp/services/ -- Business logic
Endpoints should be thin. Move logic into service functions:
# app/services/user_service.py
from sqlalchemy.ext.asyncio import AsyncSession
from app.models.user import User
async def get_user_by_id(db: AsyncSession, user_id: int) -> User | None:
return await db.get(User, user_id)app/config.py -- Settings
from pydantic_settings import BaseSettings
class Settings(BaseSettings):
database_url: str
secret_key: str
debug: bool = False
model_config = {"env_file": ".env"}
settings = Settings()Rules
1. One router file per resource (users.py, items.py, etc.). 2. Never put business logic in endpoint functions. Use services. 3. Always version your API (/api/v1/, /api/v2/). 4. Use Depends() for all shared state (db sessions, auth, settings). 5. Keep Pydantic schemas and ORM models in separate directories.
Related skills
FAQ
Should ORM models and Pydantic schemas live together?
No; keep models/ (SQLAlchemy ORM models representing tables) and schemas/ (Pydantic request/response shapes) in separate directories and never return an ORM model directly from an endpoint.
Where should business logic go?
Endpoints should be thin; move logic into service functions under app/services/.