Skip to content
Back to skills

Fastapi Structure Guide

ASecurity

Trigger when the user wants to create a new FastAPI project, add new files/folders (features), refactor existing code, or asks about architectural best practices. This skill enforces a strict layered architecture and specific development workflow.

  • 207 stars
  • 0 votes
  • 0 copies
  • 3 views
  • Added February 7, 2026
developmentpythonsqlfastapidockertestingrefactoringgitapidatabasesecurity

Works with

  • cli
  • api

Security analysis

A100/100

Pro scans all 9 files and shows the line behind each finding

Scanned February 12, 2026

npx -y skills add NeverSight/skills_feed --skill fastapi-structure-guide --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Fastapi Structure Guide?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Fastapi Structure Guide
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/neversight-fastapi-structure-guide/badge)](https://www.skillsdirectory.com/skills/neversight-fastapi-structure-guide)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: fastapi-structure-guide
description: "Trigger when the user wants to create a new FastAPI project, add new files/folders (features), refactor existing code, or asks about architectural best practices. This skill enforces a strict layered architecture and specific development workflow."
---

# FastAPI Structure Guide

## Intent

Use this guide whenever generating code for a FastAPI project, specifically when:

1. **Scaffolding** a brand new project.
2. **Adding a new feature** (e.g., "Add an Order module") which requires creating files across multiple layers.
3. **Refactoring** existing code to meet clean architecture standards.

You must strictly adhere to the **Core Principles**, **Project Structure**, **Development Workflow**, and **Coding Rules** defined below.

---

## I. Core Principles

Before writing a single line of code, adhere to these four guiding principles:

1. **Separation of Concerns:**
* **API Layer:** Responsible only for "Reception" (parsing requests, validating parameters).
* **Service Layer:** Responsible for "Business" (logic calculation, decision making).
* **DB/Model Layer:** Responsible for "Data" (storage access, shape definition).
* *Rule:* Never write business logic inside an API Route function.


2. **Dependency Injection:**
* Do not instantiate components directly (e.g., `service = UserService()`).
* Use FastAPI's `Depends` for injection.
* **Flow:** DB Session -> injected into -> Service -> injected into -> API Route.


3. **Config Centralization:**
* Strictly prohibit hardcoded passwords, keys, or URLs in the code.
* Manage all configurations via **Pydantic Settings** and read from environment variables (`.env`).


4. **Mirrored Testing:**
* The test directory structure must mirror the source code directory structure 1:1.
* Use **SQLite In-Memory** and **Dependency Overrides** to mock the real environment.



---

## II. Recommended Project Structure

Use this standardized directory structure when creating files or folders:

```text
my-fastapi-project/
├── app/                        # Core Application Source
│   ├── __init__.py
│   ├── main.py                 # 🚀 App Entry: Routes mounting, Exception handling
│   ├── api/                    # 🌐 Interface Layer (Routes)
│   │   ├── __init__.py
│   │   └── v1/                 # Version Control
│   │       ├── __init__.py
│   │       ├── api.py          # Router Aggregation (Include Routers)
│   │       └── endpoints/      # Specific Business Endpoints
│   │           ├── __init__.py
│   │           ├── users.py
│   │           └── items.py
│   ├── core/                   # ⚙️ Infrastructure Configuration
│   │   ├── __init__.py
│   │   ├── config.py           # Pydantic Settings (Env Config)
│   │   ├── logging.py          # Logging Config
│   │   └── security.py         # Auth/Hashing Tools
│   ├── db/                     # 🗄️ Database Layer
│   │   ├── __init__.py
│   │   ├── session.py          # DB Connection & Session Factory
│   │   └── tables.py           # SQLAlchemy ORM Definitions (DB Schema)
│   ├── models/                 # 📝 Data Transfer Objects (DTOs)
│   │   ├── __init__.py
│   │   ├── user.py             # Pydantic Models (Request/Response)
│   │   └── item.py
│   └── services/               # 🧠 Business Logic Layer
│       ├── __init__.py
│       ├── base.py             # Optional: Base Service Class
│       ├── user_service.py     # User-related business logic
│       └── item_service.py
├── tests/                      # ✅ Test Cases (Mirrored Structure)
│   ├── __init__.py
│   ├── conftest.py             # Pytest Fixtures (DB override, Client)
│   └── api/
│       └── v1/
│           └── endpoints/
│               └── test_users.py
├── .env                        # 🔐 Local Env Vars (Gitignored)
├── .gitignore
├── docker-compose.yaml         # Local Dev Orchestration
├── Dockerfile                  # Image Build
├── pyproject.toml              # Dependency Management (Recommend uv)
└── README.md

```

### Directory Responsibilities

1. **`app/api/` (Interface Layer)**
* **Responsibility:** Handle HTTP protocol specifics only.
* **Contains:** Path definitions, HTTP methods (GET/POST), status codes, dependency injection declarations.
* **Input/Output:** Pydantic Schemas.
* **Rule:** This layer must be "thin". Functions should strictly be 5-10 lines, calling the Service layer and returning results.


2. **`app/services/` (Business Logic Layer)**
* **Responsibility:** The brain of the application. Handles complex business rules, calculations, and permission checks.
* **Contains:** CRUD operations, 3rd-party API logic, data processing.
* **Input/Output:** Pydantic Schemas or Raw Data -> ORM Objects or Pydantic Schemas.
* **Rule:** Service classes must accept `Session` via `__init__` for easy testing mocks.


3. **`app/models/` (Data Transfer Object Layer)**
* **Responsibility:** Define data "shape" and validation rules for the API.
* **Contains:** Pydantic Models (`BaseModel`).
* **Distinction:** These are *not* DB tables. They are for API input/output (e.g., `UserCreate` vs `UserResponse`).


4. **`app/db/` (Data Access Layer)**
* **Responsibility:** Physical DB connection and Table definitions.
* **Contains:** `session.py` (Engine/SessionLocal), `tables.py` (SQLAlchemy Base models/Columns).


5. **`app/core/` (Cross-Cutting Concerns)**
* **Responsibility:** Infrastructure supporting the app.
* **Contains:** Config loading (`config.py`), logging, security tools. Code here is business-agnostic.



---

## III. Creation Rules (General Development Workflow)

When implementing a new feature, follow these **5 Standard Steps** in order:

### Step A: Define Data Storage (Database Layer)

* **Principle:** Everything starts with data. Determine how the resource looks in the DB.
* **Action:** Add new SQLAlchemy ORM class in `db/tables.py` (or specific file in `db/models/`).
* **Naming:** PascalCase for Class (Singular), snake_case for Table Name (Plural).

### Step B: Define Interaction Contract (Schemas/DTO Layer)

* **Principle:** Define how data moves over the network. Validate Input (Create/Update) and Normalize Output (Response).
* **Action:** Create a new file in `models/`.
* **Naming:** `resource_name.py`. Typically includes `Create`, `Update`, `Response` variants.

### Step C: Implement Business Logic (Service Layer)

* **Principle:** Write the "Verbs". This is the bridge between DB and API.
* **Action:** Create a new file in `services/`.
* **Naming:** `resource_name_service.py`. Class name ends with `Service`.

### Step D: Expose API Interface (API Layer)

* **Principle:** Define the entry point for external access.
* **Action:** Create a new file in `api/v1/endpoints/`.
* **Naming:** `resource_names.py` (Plural) to reflect RESTful style.

### Step E: Registration & Wiring

* **Principle:** New router files are isolated by default; they must be explicitly registered.
* **Action:** Modify `api/v1/api.py` to include the new router.

---

## IV. Coding Rules

### Rule 1: API Routes Must Be "Dumb"

**❌ Wrong (Logic Leakage):**

```python
@router.post("/users")
def create_user(user: UserCreate, db: Session = Depends(get_db)):
    # Error: Logic and DB ops directly in route
    hashed_password = hash_pw(user.password)
    db_user = User(email=user.email, password=hashed_password)
    db.add(db_user)
    db.commit()
    return db_user

```

**✅ Correct (Call Service):**

```python
@router.post("/users")
def create_user(
    user: UserCreate, 
    service: UserService = Depends(get_user_service) # Injected Service
):
    # Correct: Only forwards the request
    return service.create_user(user)

```

### Rule 2: Service Layer Must Use Dependency Injection

Service classes should not create the DB Session themselves; they must receive it in `__init__`.

```python
class UserService:
    def __init__(self, session: Session):
        self.session = session  # ✅ Dependency Injection

    def create_user(self, data: UserCreate):
        # Business logic...
        pass

```

### Rule 3: Config Must Use Pydantic

Never use `os.getenv("KEY")` scattered in the code.

```python
# app/core/config.py
class Settings(BaseSettings):
    DB_URL: str
    SECRET_KEY: str

settings = Settings()

# Usage in other files
from app.core.config import settings
print(settings.DB_URL)

```

Files in this skill

  • SKILL.md8.5 KB
  • description_cn.txt218 B
  • description_de.txt310 B
  • description_en.txt248 B
  • description_es.txt316 B
  • description_fr.txt348 B
  • description_ja.txt442 B
  • description_ko.txt312 B
  • description_tw.txt218 B

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.