Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
ag2ai avatar

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)
At a glance

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
From the docs

What fastapi-project-structure says it does

Standard directory layout and module organization for FastAPI applications
SKILL.md
Never put business logic in endpoint functions. Use services.
SKILL.md
npx skills add https://github.com/ag2ai/resource-hub --skill fastapi-project-structure

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs1
repo stars4
Last updatedApril 1, 2026
Repositoryag2ai/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

SKILL.mdMarkdownGitHub ↗

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.toml

Key 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 session

app/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/.

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.