← Core Framework & Fundamentals

Select a question from the sidebar

15 questions in this topic

Question 1 / 15

What is FastAPI and what are its key features?

FastAPI is a modern, high-performance Python web framework for building APIs. It was created by Sebastian Ramirez and first released in 2018.

Key features:

Fast: Built on Starlette and Uvicorn (ASGI), performance comparable to Node.js and Go
Type hints: Leverages Python type annotations for automatic validation, serialization, and documentation
Automatic docs: Generates interactive Swagger UI and ReDoc documentation from your code
Data validation: Uses Pydantic for request/response validation with detailed error messages
Async support: Native async/await support for high-concurrency workloads
Dependency injection: Built-in DI system for clean, testable code
Standards-based: Fully compliant with OpenAPI 3.1 and JSON Schema
Editor support: Excellent autocomplete and type checking due to type hints

Why it is popular:

FastAPI combines the ease of use of Flask with the performance of async frameworks and the automatic validation of type-safe languages. It reduces bugs by catching type errors at request time rather than deep in business logic.

Pseudo Code

# FastAPI at a glance
import FastAPI

app = create FastAPI application

@app.GET("/items/{id}")
function get_item(id: integer, query: string = default):
    # id is auto-validated as integer
    # query is auto-validated as string with default
    return {"id": id, "query": query}

# Auto-generated docs at /docs (Swagger) and /redoc (ReDoc)
# Auto request validation, serialization, error responses

Code

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def read_root():
    return {"message": "Hello, FastAPI!"}

@app.get("/items/{item_id}")
def read_item(item_id: int, q: str = "default"):
    """item_id is validated as int, q is an optional query param."""
    return {"item_id": item_id, "q": q}

# Run with: uvicorn main:app --reload
# Visit http://127.0.0.1:8000/docs for Swagger UI
# Visit http://127.0.0.1:8000/redoc for ReDoc

# Quick verification with TestClient
from fastapi.testclient import TestClient

client = TestClient(app)
response = client.get("/items/42?q=search")
print(response.json())
print(response.status_code)

{'item_id': 42, 'q': 'search'}
200

Key Points

•FastAPI is built on Starlette (web) and Pydantic (data validation)
•Type hints drive validation, serialization, and auto-generated docs
•Native async/await support with ASGI for high concurrency
•Automatic interactive API docs at /docs and /redoc

Gotchas

•FastAPI requires Python 3.8+ (3.10+ recommended for modern type syntax)
•You need an ASGI server like Uvicorn to run FastAPI -- it cannot run standalone like Flask's development server
•FastAPI is the framework, Uvicorn is the server -- they are separate packages

FastAPI is a high-performance Python web framework that uses type hints for automatic validation, serialization, and API documentation. Built on Starlette and Pydantic, it supports async/await natively and auto-generates Swagger UI and ReDoc docs.

•Built on Starlette + Pydantic, type hints drive everything
•Auto-generates OpenAPI docs at /docs and /redoc

from fastapi import FastAPI

app = FastAPI()

@app.get("/items/{item_id}")
def read_item(item_id: int, q: str = "default"):
    return {"item_id": item_id, "q": q}

# Run: uvicorn main:app --reload
# Docs at /docs, /redoc

Requires an ASGI server (Uvicorn) to run -- pip install 'fastapi[standard]' includes it

Question 2 / 15

How does FastAPI compare to Flask and Django?

FastAPI vs Flask vs Django

Feature	FastAPI	Flask	Django
Type	Async API framework	Micro framework	Full-stack framework
Server	ASGI (Uvicorn)	WSGI (Gunicorn)	WSGI (Gunicorn)
Validation	Automatic (Pydantic)	Manual or extensions	Forms/DRF serializers
API Docs	Auto-generated	Manual (flask-restx)	Manual (DRF + drf-yasg)
Async	Native	Limited (Flask 2.0+)	Limited (Django 4.1+)
ORM	None built-in	None built-in	Django ORM built-in
Admin	None built-in	None built-in	Built-in admin panel
Learning curve	Low (if you know type hints)	Very low	Moderate

When to choose each:

FastAPI: APIs, microservices, high-concurrency, real-time features
Flask: Simple web apps, prototypes, or when you want maximum flexibility
Django: Full-featured web apps with admin, ORM, auth, templates out of the box

Performance:

FastAPI on Uvicorn is significantly faster than Flask/Django for I/O-bound workloads due to native async support. For CPU-bound work, the difference is minimal since Python's GIL limits all three equally.

Pseudo Code

# Flask style
@app.route('/items/<int:item_id>', methods=['GET'])
def get_item(item_id):
    # Manual validation needed
    return jsonify({"id": item_id})

# Django REST Framework style
class ItemView(APIView):
    def get(self, request, item_id):
        serializer = ItemSerializer(data=...)
        serializer.is_valid(raise_exception=True)
        return Response(serializer.data)

# FastAPI style
@app.get('/items/{item_id}')
def get_item(item_id: int) -> Item:
    # Validation is automatic from type hints
    return Item(id=item_id)

Code

# FastAPI: validation is automatic from type hints
from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Item(BaseModel):
    name: str
    price: float
    in_stock: bool = True

@app.post("/items/")
def create_item(item: Item):
    """Request body is auto-validated against the Item model.
    Invalid data returns 422 with detailed error messages.
    Swagger UI shows the schema automatically."""
    return {"item": item.model_dump(), "message": "created"}

# Compare: Flask requires manual validation
# @app.route('/items/', methods=['POST'])
# def create_item():
#     data = request.get_json()
#     if 'name' not in data:          # manual check
#         return jsonify(error='...'), 400
#     if not isinstance(data['price'], (int, float)):  # manual check
#         return jsonify(error='...'), 400
#     return jsonify(data), 201

from fastapi.testclient import TestClient
client = TestClient(app)

# Valid request
response = client.post("/items/", json={"name": "Widget", "price": 9.99})
print(response.json())

# Invalid request -- automatic 422 error
response = client.post("/items/", json={"name": "Widget", "price": "not-a-number"})
print(response.status_code)

{'item': {'name': 'Widget', 'price': 9.99, 'in_stock': True}, 'message': 'created'}
422

Key Points

•FastAPI provides automatic validation, serialization, and docs -- Flask/Django need extensions
•FastAPI is ASGI-native (async), Flask/Django are WSGI-based with limited async support
•Django is batteries-included (ORM, admin, auth); FastAPI and Flask are minimal by design
•FastAPI excels at API-first development; Django excels at full-stack web apps

Gotchas

•FastAPI has no built-in ORM, template engine, or admin panel -- you add what you need
•Flask 2.0+ supports async views but is still WSGI under the hood, limiting true concurrency
•Django REST Framework is not Django itself -- it is a separate package for building APIs

FastAPI is async-first with auto-validation and docs from type hints. Flask is a minimal WSGI framework requiring extensions for validation. Django is full-stack with ORM, admin, and auth built in. Choose FastAPI for APIs, Flask for simple apps, Django for full-featured web apps.

•FastAPI: auto validation + docs from types; Flask: manual; Django: ORM + admin built in
•FastAPI is ASGI (async), Flask/Django are WSGI

# FastAPI: type hints do the work
from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Item(BaseModel):
    name: str
    price: float

@app.post("/items/")
def create(item: Item):  # auto-validated, auto-documented
    return item.model_dump()

FastAPI has no built-in ORM or admin panel -- you must add them yourself

Question 3 / 15

What is ASGI and how does it differ from WSGI?

WSGI (Web Server Gateway Interface)

WSGI is the traditional Python web server interface (PEP 3333). It handles one request at a time per worker in a synchronous model.

ASGI (Asynchronous Server Gateway Interface)

ASGI is the async successor to WSGI. It supports:

HTTP (like WSGI)
WebSockets (real-time bidirectional communication)
Long-lived connections (server-sent events, streaming)
Background tasks during request handling

Key differences:

Aspect	WSGI	ASGI
Concurrency	One request per thread/process	Many requests per event loop
WebSockets	Not supported	Native support
Streaming	Limited	Full support
Servers	Gunicorn, mod_wsgi	Uvicorn, Daphne, Hypercorn
Frameworks	Flask, Django	FastAPI, Starlette, Django Channels

Why ASGI matters for FastAPI:

When your API calls external services, databases, or file I/O, ASGI lets the server handle other requests while waiting. A single Uvicorn worker can handle thousands of concurrent connections versus a WSGI worker that blocks on one.

Pseudo Code

# WSGI interface (synchronous)
def wsgi_app(environ, start_response):
    # Can only handle one request at a time per worker
    status = '200 OK'
    headers = [('Content-Type', 'text/plain')]
    start_response(status, headers)
    return [b'Hello World']

# ASGI interface (asynchronous)
async def asgi_app(scope, receive, send):
    # Can handle many requests concurrently
    # scope: connection info (type, path, headers)
    # receive: get request body/messages
    # send: send response chunks
    await send({"type": "http.response.start", ...})
    await send({"type": "http.response.body", ...})

Code

# FastAPI is an ASGI app -- you can see this directly
from fastapi import FastAPI
import asyncio

app = FastAPI()

# Sync handler: FastAPI runs it in a thread pool automatically
@app.get("/sync")
def sync_endpoint():
    """Runs in a thread pool so it doesn't block the event loop."""
    import time
    time.sleep(0.1)  # Blocking call -- OK because it's in a thread
    return {"type": "sync"}

# Async handler: runs directly on the event loop
@app.get("/async")
async def async_endpoint():
    """Runs on the event loop -- must use async I/O."""
    await asyncio.sleep(0.1)  # Non-blocking
    return {"type": "async"}

# Demonstrating ASGI nature
print(f"FastAPI app type: {type(app)}")
print(f"Is callable: {callable(app)}")

# The ASGI interface FastAPI implements under the hood:
# async def __call__(self, scope, receive, send):
#     await super().__call__(scope, receive, send)

# WSGI comparison (Flask):
# from flask import Flask
# flask_app = Flask(__name__)
# # Flask implements: def __call__(self, environ, start_response)

FastAPI app type: <class 'fastapi.applications.FastAPI'>
Is callable: True

Key Points

•WSGI is synchronous (one request per worker); ASGI is async (many concurrent requests per worker)
•ASGI supports HTTP, WebSockets, and streaming natively; WSGI only supports HTTP
•FastAPI uses Uvicorn (ASGI server), Flask/Django traditionally use Gunicorn (WSGI server)
•Sync def handlers in FastAPI run in a thread pool automatically to avoid blocking the event loop

Gotchas

•Using blocking I/O (time.sleep, requests library) in an async def handler blocks the entire event loop
•ASGI does not automatically make CPU-bound code faster -- the GIL still applies
•Gunicorn can run ASGI apps too via gunicorn -k uvicorn.workers.UvicornWorker

WSGI is synchronous (one request per worker), ASGI is asynchronous (many concurrent requests per worker). FastAPI uses ASGI via Uvicorn, enabling WebSockets, streaming, and high concurrency. ASGI is the async successor to WSGI.

•ASGI = async, supports WebSockets + streaming; WSGI = sync, HTTP only
•FastAPI runs on Uvicorn (ASGI); Flask runs on Gunicorn (WSGI)

from fastapi import FastAPI
import asyncio

app = FastAPI()

# Async handler -- runs on the event loop
@app.get("/async")
async def async_endpoint():
    await asyncio.sleep(0.1)  # non-blocking
    return {"message": "async response"}

# Sync handler -- auto-runs in thread pool
@app.get("/sync")
def sync_endpoint():
    return {"message": "sync response"}

Never use blocking I/O (time.sleep, requests) inside async def -- it blocks the entire event loop

Question 4 / 15

What role does Starlette play in FastAPI?

Starlette is a lightweight ASGI framework that provides the core web functionality FastAPI is built on. FastAPI's FastAPI class directly inherits from Starlette's Starlette class.

What Starlette provides to FastAPI:

Routing system: Path matching, path parameters, route ordering
Request/Response classes: Request, Response, JSONResponse, HTMLResponse, etc.
Middleware support: CORS, GZip, sessions, trusted hosts
WebSocket support: Full WebSocket endpoint handling
Background tasks: BackgroundTask class for post-response work
Test client: TestClient based on httpx
Static files: Serving static assets
Exception handling: Base exception handlers and middleware

What FastAPI adds on top:

Pydantic integration: Automatic validation and serialization
Dependency injection: Depends() system
OpenAPI generation: Automatic Swagger/ReDoc docs
Security utilities: OAuth2, API keys, HTTP Bearer
Parameter declarations: Path(), Query(), Body(), Header(), Cookie()

The inheritance chain:

FastAPI -> Starlette -> object

This means any Starlette feature works directly in FastAPI. You can use Starlette middleware, mount Starlette sub-applications, or use its lower-level features when needed.

Pseudo Code

# FastAPI inherits from Starlette
class FastAPI(Starlette):
    # Adds Pydantic validation
    # Adds dependency injection
    # Adds OpenAPI schema generation
    # All Starlette features still available
    pass

# You can use any Starlette feature in FastAPI
app = FastAPI()
app.add_middleware(StarletteMiddleware)  # Works!
app.mount("/static", StaticFiles())      # Works!

Code

from fastapi import FastAPI
from starlette.applications import Starlette
from starlette.responses import HTMLResponse
from starlette.staticfiles import StaticFiles
from starlette.middleware.trustedhost import TrustedHostMiddleware

app = FastAPI()

# Proof: FastAPI inherits from Starlette
print(f"FastAPI bases: {FastAPI.__bases__}")
print(f"Is subclass of Starlette: {issubclass(FastAPI, Starlette)}")

# Using Starlette's response classes directly
@app.get("/html", response_class=HTMLResponse)
def get_html():
    return "<h1>This uses Starlette's HTMLResponse</h1>"

# Using Starlette middleware in FastAPI
app.add_middleware(
    TrustedHostMiddleware,
    allowed_hosts=["example.com", "*.example.com"]
)

# Mounting Starlette static files
# app.mount("/static", StaticFiles(directory="static"), name="static")

# Using Starlette's Request object
from starlette.requests import Request

@app.get("/info")
def get_info(request: Request):
    return {
        "client": request.client.host if request.client else None,
        "url": str(request.url),
    }

FastAPI bases: (<class 'starlette.applications.Starlette'>,)
Is subclass of Starlette: True

Key Points

•FastAPI directly inherits from Starlette -- it IS a Starlette app with extra features
•Starlette provides routing, request/response, middleware, WebSockets, and test client
•FastAPI adds Pydantic validation, dependency injection, and OpenAPI docs on top
•All Starlette features and middleware work directly in FastAPI

Gotchas

•Import from fastapi when possible (e.g., from fastapi import Request) even though it re-exports Starlette classes
•Starlette's own TestClient is re-exported as fastapi.testclient.TestClient
•When searching for solutions, Starlette docs are often relevant for FastAPI

Starlette is the ASGI framework that FastAPI inherits from. It provides routing, request/response handling, middleware, WebSockets, and the test client. FastAPI adds Pydantic validation, dependency injection, and auto-generated OpenAPI docs on top.

•FastAPI inherits from Starlette, adding validation and OpenAPI on top

from fastapi import FastAPI
from starlette.applications import Starlette

app = FastAPI()

# FastAPI IS a Starlette app
print(issubclass(FastAPI, Starlette))

True

Import from fastapi (not starlette) when both provide the same class

Question 5 / 15

What role does Pydantic play in FastAPI?

Pydantic is the data validation library that powers FastAPI's automatic request/response handling. FastAPI uses Pydantic v2 for:

1. Request body validation

When you declare a parameter with a Pydantic model type, FastAPI automatically parses the JSON body and validates every field.

2. Response serialization

Using response_model, FastAPI serializes your return value through a Pydantic model, filtering out fields not in the schema.

3. OpenAPI schema generation

Pydantic models automatically generate JSON Schema, which FastAPI uses for Swagger/ReDoc docs.

4. Settings management

Pydantic's BaseSettings reads from environment variables with type validation.

Key Pydantic v2 features used in FastAPI:

BaseModel for schemas
Field() for constraints (min/max, regex, description)
field_validator / model_validator for custom validation
model_dump() for serialization (replaces .dict() from v1)
model_config dict (replaces class Config from v1)
ConfigDict for model configuration

Pseudo Code

# Pydantic handles the full request lifecycle in FastAPI

1. Request arrives with JSON body
2. FastAPI extracts body -> passes to Pydantic model
3. Pydantic validates types, constraints, custom validators
4. If invalid -> automatic 422 response with error details
5. If valid -> your function receives a typed Python object
6. On response -> Pydantic serializes output via response_model
7. Schema -> auto-generates OpenAPI docs

Code

from pydantic import BaseModel, Field, field_validator, ConfigDict
from fastapi import FastAPI
from fastapi.testclient import TestClient

app = FastAPI()

class ItemCreate(BaseModel):
    """Pydantic model for request validation."""
    model_config = ConfigDict(str_strip_whitespace=True)

    name: str = Field(min_length=1, max_length=100, description="Item name")
    price: float = Field(gt=0, description="Price must be positive")
    tags: list[str] = []

    @field_validator("name")
    @classmethod
    def name_must_be_capitalized(cls, v: str) -> str:
        if not v[0].isupper():
            raise ValueError("Name must start with uppercase")
        return v

class ItemResponse(BaseModel):
    """Pydantic model for response serialization."""
    name: str
    price: float
    tags: list[str]
    # Note: internal fields like 'id' or 'created_at' can be excluded

@app.post("/items/", response_model=ItemResponse)
def create_item(item: ItemCreate):
    # item is already validated by Pydantic
    print(f"Received: {item.model_dump()}")
    return item  # Serialized through ItemResponse

client = TestClient(app)

# Valid request
response = client.post("/items/", json={"name": "Widget", "price": 9.99, "tags": ["sale"]})
print("Valid:", response.json())

# Invalid: price is negative
response = client.post("/items/", json={"name": "Widget", "price": -5})
print("Invalid price status:", response.status_code)

# Invalid: name not capitalized
response = client.post("/items/", json={"name": "widget", "price": 9.99})
print("Invalid name status:", response.status_code)

Received: {'name': 'Widget', 'price': 9.99, 'tags': ['sale']}
Valid: {'name': 'Widget', 'price': 9.99, 'tags': ['sale']}
Invalid price status: 422
Invalid name status: 422

Key Points

•Pydantic validates request bodies automatically -- invalid data returns 422 with detailed errors
•response_model filters and serializes output through a Pydantic model
•Pydantic models auto-generate JSON Schema used for Swagger/ReDoc docs
•Use Pydantic v2 syntax: model_dump(), field_validator, model_config (not .dict(), @validator, class Config)

Gotchas

•Pydantic v2 is a major rewrite -- v1 syntax like .dict(), @validator, and class Config still work but are deprecated
•field_validator needs @classmethod decorator in Pydantic v2
•model_dump() replaces .dict() and model_dump_json() replaces .json()

Pydantic provides data validation and serialization for FastAPI. When you declare a Pydantic model as a parameter type, FastAPI auto-validates the request body and returns 422 on errors. It also generates the OpenAPI schema for docs.

•Pydantic validates requests and serializes responses automatically
•Use model_dump() not .dict() (Pydantic v2)

from pydantic import BaseModel, Field
from fastapi import FastAPI

app = FastAPI()

class Item(BaseModel):
    name: str = Field(min_length=1)
    price: float = Field(gt=0)

@app.post("/items/")
def create(item: Item):  # auto-validated
    return item.model_dump()  # Pydantic v2 serialization

Pydantic v2 syntax differs from v1 -- use field_validator, model_config, model_dump()

Question 6 / 15

How do you install and create a basic FastAPI application?

Installation

FastAPI can be installed in two ways:

pip install fastapi              # Core only
pip install 'fastapi[standard]'  # Core + Uvicorn + extras

The [standard] option includes:

uvicorn: ASGI server to run the app
httpx: For TestClient
jinja2: Template support
python-multipart: Form/file upload support

Creating a basic app:

Create a main.py file
Import FastAPI and create an instance
Define route handlers with decorators
Run with Uvicorn

Running the app:

Development: uvicorn main:app --reload (auto-reloads on code changes)
Production: uvicorn main:app --host 0.0.0.0 --port 8000 --workers 4
Programmatic: uvicorn.run("main:app", reload=True) in a script

The main:app syntax means: in the file main.py, use the variable named app.

Pseudo Code

# Step 1: Install
pip install 'fastapi[standard]'

# Step 2: Create main.py
import FastAPI
app = FastAPI()

@app.GET("/")
function root():
    return greeting message

# Step 3: Run
uvicorn main:app --reload

Code

# main.py -- A complete basic FastAPI application
from fastapi import FastAPI

# Create the FastAPI instance
app = FastAPI(
    title="My API",
    version="1.0.0",
)

@app.get("/")
def root():
    return {"message": "Hello, World!"}

@app.get("/health")
def health_check():
    return {"status": "healthy"}

@app.get("/items/{item_id}")
def get_item(item_id: int, q: str | None = None):
    result = {"item_id": item_id}
    if q:
        result["q"] = q
    return result

# Verify it works with TestClient
from fastapi.testclient import TestClient

client = TestClient(app)
print(client.get("/").json())
print(client.get("/health").json())
print(client.get("/items/1?q=test").json())

# Run with: uvicorn main:app --reload
# Or programmatically:
# if __name__ == "__main__":
#     import uvicorn
#     uvicorn.run("main:app", host="127.0.0.1", port=8000, reload=True)

{'message': 'Hello, World!'}
{'status': 'healthy'}
{'item_id': 1, 'q': 'test'}

Key Points

•pip install 'fastapi[standard]' includes Uvicorn and common extras
•uvicorn main:app --reload is the standard development command
•main:app means 'the app variable in main.py'
•--reload flag auto-restarts on code changes (development only)

Gotchas

•The --reload flag should never be used in production -- it watches files and restarts, adding overhead
•python-multipart must be installed for Form data and file uploads (included in [standard])
•uvicorn.run() with reload=True requires passing the app as a string 'main:app', not the object directly

Install with pip install 'fastapi[standard]', create an app instance with app = FastAPI(), define routes with decorators like @app.get("/"), and run with uvicorn main:app --reload.

•'fastapi[standard]' includes Uvicorn, httpx, and common extras
•uvicorn main:app --reload for development

# pip install 'fastapi[standard]'
from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def root():
    return {"message": "Hello, World!"}

# Run: uvicorn main:app --reload

Never use --reload in production -- it adds file-watching overhead

Question 7 / 15

How does FastAPI automatically generate OpenAPI/Swagger documentation?

FastAPI automatically generates an OpenAPI 3.1 schema from your code and serves two interactive documentation UIs:

How it works:

You define routes with type hints, Pydantic models, and parameter declarations
FastAPI inspects these at startup and builds a complete OpenAPI schema
The schema is served as JSON at /openapi.json
Two UI renderers consume this schema:
- Swagger UI at /docs -- interactive, lets you try API calls
- ReDoc at /redoc -- clean read-only documentation

What gets documented automatically:

Path parameters with types
Query parameters with defaults and constraints
Request body schemas (from Pydantic models)
Response schemas (from response_model)
Status codes
Tags for grouping
Docstrings become operation descriptions
Field(description=...) becomes field descriptions
summary and description parameters in decorators

Customizing docs:

Add summary, description, tags to route decorators
Use docstrings on handler functions
Set response_description on routes
Use Pydantic Field(description=..., examples=[...]) for field docs
Configure app-level metadata (title, version, description, terms, contact, license)

Pseudo Code

# FastAPI doc generation pipeline
1. At startup, inspect all route decorators
2. For each route, extract:
   - Path parameters + types
   - Query parameters + defaults
   - Body schema from Pydantic models
   - Response schema from response_model
   - Tags, summary, description
3. Build OpenAPI 3.1 JSON schema
4. Serve schema at /openapi.json
5. Swagger UI at /docs reads the schema
6. ReDoc at /redoc reads the schema

Code

from fastapi import FastAPI, Query
from pydantic import BaseModel, Field

app = FastAPI(
    title="Bookstore API",
    description="A sample API for managing books",
    version="2.0.0",
    contact={"name": "API Support", "email": "support@example.com"},
    license_info={"name": "MIT"},
)

class BookCreate(BaseModel):
    """Schema for creating a new book."""
    title: str = Field(min_length=1, description="The book title")
    author: str = Field(description="Author full name")
    price: float = Field(gt=0, description="Price in USD", examples=[29.99])

class BookResponse(BaseModel):
    id: int
    title: str
    author: str
    price: float

@app.get(
    "/books/",
    response_model=list[BookResponse],
    tags=["books"],
    summary="List all books",
)
def list_books(
    skip: int = Query(default=0, ge=0, description="Records to skip"),
    limit: int = Query(default=10, le=100, description="Max records"),
):
    """Retrieve a paginated list of books from the catalog."""
    return []

@app.post(
    "/books/",
    response_model=BookResponse,
    status_code=201,
    tags=["books"],
    summary="Create a book",
)
def create_book(book: BookCreate):
    """Add a new book to the catalog."""
    return BookResponse(id=1, **book.model_dump())

# Access the generated OpenAPI schema programmatically
schema = app.openapi()
print(f"API Title: {schema['info']['title']}")
print(f"Version: {schema['info']['version']}")
print(f"Paths: {list(schema['paths'].keys())}")

API Title: Bookstore API
Version: 2.0.0
Paths: ['/books/']

Key Points

•OpenAPI schema is auto-generated at /openapi.json from type hints and Pydantic models
•Swagger UI at /docs is interactive (try requests); ReDoc at /redoc is read-only
•Docstrings, Field(description=...), and decorator params all feed into the docs
•app.openapi() gives programmatic access to the generated schema

Gotchas

•Disable docs in production with app = FastAPI(docs_url=None, redoc_url=None) if your API is not public
•If you override openapi() method, it caches the result -- clear app.openapi_schema = None to regenerate
•Docstrings support Markdown formatting in the docs UI

FastAPI inspects your type hints, Pydantic models, and decorators at startup to build an OpenAPI 3.1 schema (at /openapi.json). Swagger UI is served at /docs and ReDoc at /redoc -- both are auto-generated, no extra config needed.

•Docs auto-generated at /docs (Swagger) and /redoc (ReDoc) from your code

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI(title="My API", version="1.0.0")

class Item(BaseModel):
    name: str
    price: float

@app.post("/items/", response_model=Item, tags=["items"])
def create_item(item: Item):
    """Create a new item."""  # Shows in docs
    return item

# /docs -> Swagger UI, /redoc -> ReDoc, /openapi.json -> raw schema

Disable docs in production if your API is not public: FastAPI(docs_url=None, redoc_url=None)

Question 8 / 15

What is the typical project structure for a FastAPI application?

FastAPI does not enforce a project structure, but the community has converged on a pattern that scales well.

Small project (single file):

main.py
requirements.txt

Medium project (package):

app/
  __init__.py
  main.py          # FastAPI app creation, lifespan
  config.py        # Settings (Pydantic BaseSettings)
  models.py        # SQLAlchemy/DB models
  schemas.py       # Pydantic request/response models
  database.py      # DB engine, session
  dependencies.py  # Shared dependencies
  routers/
    __init__.py
    items.py       # APIRouter for /items
    users.py       # APIRouter for /users
tests/
  __init__.py
  conftest.py
  test_items.py
  test_users.py

Large project (domain-driven):

app/
  __init__.py
  main.py
  core/
    config.py
    security.py
    database.py
  items/
    router.py
    schemas.py
    models.py
    service.py
    dependencies.py
  users/
    router.py
    schemas.py
    models.py
    service.py
tests/
alembic/

Key principles:

Separate schemas from models: Pydantic schemas (API) vs SQLAlchemy models (DB)
Use APIRouter: One router per resource/domain
Centralize config: Use Pydantic BaseSettings for environment variables
Keep main.py thin: Only app creation, middleware, and router includes

Pseudo Code

# main.py -- thin entry point
app = FastAPI()
app.include_router(items_router, prefix="/items")
app.include_router(users_router, prefix="/users")

# routers/items.py -- domain logic
router = APIRouter(tags=["items"])

@router.get("/")
def list_items(db = Depends(get_db)):
    return db.query(Item).all()

# schemas.py -- Pydantic models (API contracts)
# models.py  -- SQLAlchemy models (DB tables)
# These are SEPARATE concerns

Code

# app/main.py -- Thin entry point
from contextlib import asynccontextmanager
from fastapi import FastAPI

@asynccontextmanager
async def lifespan(app: FastAPI):
    # Startup: initialize resources
    print("Starting up...")
    yield
    # Shutdown: cleanup resources
    print("Shutting down...")

app = FastAPI(title="My App", lifespan=lifespan)

# Include routers
from app.routers import items, users
app.include_router(items.router, prefix="/items", tags=["items"])
app.include_router(users.router, prefix="/users", tags=["users"])

# -----------------------------------------------
# app/routers/items.py -- Domain router
from fastapi import APIRouter, Depends

router = APIRouter()

@router.get("/")
def list_items():
    return [{"id": 1, "name": "Widget"}]

@router.get("/{item_id}")
def get_item(item_id: int):
    return {"id": item_id, "name": "Widget"}

# -----------------------------------------------
# app/schemas.py -- Pydantic schemas (API contract)
from pydantic import BaseModel

class ItemCreate(BaseModel):
    name: str
    price: float

class ItemResponse(BaseModel):
    id: int
    name: str
    price: float

# -----------------------------------------------
# app/config.py -- Centralized settings
from pydantic_settings import BaseSettings

class Settings(BaseSettings):
    database_url: str = "sqlite:///./app.db"
    debug: bool = False
    secret_key: str = "change-me"

    model_config = {"env_file": ".env"}

settings = Settings()
print(f"Debug mode: {settings.debug}")

Debug mode: False

Key Points

•Separate Pydantic schemas (API) from SQLAlchemy models (DB) -- they serve different purposes
•Use APIRouter per resource/domain and include_router in main.py
•Keep main.py thin: app creation, middleware, router registration
•Use Pydantic BaseSettings for configuration from environment variables

Gotchas

•schemas.py (Pydantic) and models.py (SQLAlchemy) are different -- do not mix API contracts with DB models
•Circular imports are common if routers import from main.py -- use dependency injection to avoid this
•Use lifespan context manager, not the deprecated @app.on_event('startup') decorator

FastAPI projects typically have main.py (app setup), routers/ (APIRouter per resource), schemas.py (Pydantic models), models.py (DB models), and config.py (settings). Keep main.py thin and use include_router to compose the app.

•Routers per resource, schemas separate from DB models, thin main.py

# app/main.py
from fastapi import FastAPI
from app.routers import items, users

app = FastAPI()
app.include_router(items.router, prefix="/items", tags=["items"])
app.include_router(users.router, prefix="/users", tags=["users"])

# app/routers/items.py
from fastapi import APIRouter
router = APIRouter()

@router.get("/")
def list_items():
    return []

Do not mix Pydantic schemas and SQLAlchemy models in the same file

Question 9 / 15

How do you run a FastAPI application with Uvicorn?

Uvicorn is the recommended ASGI server for running FastAPI. It is based on uvloop (a fast event loop) and httptools (a fast HTTP parser).

Command line usage:

uvicorn main:app [options]

Common options:

Option	Description	Default
`--reload`	Auto-reload on changes	Off
`--host`	Bind address	127.0.0.1
`--port`	Port number	8000
`--workers`	Number of worker processes	1
`--log-level`	Logging level	info
`--ssl-keyfile`	SSL key file	None
`--ssl-certfile`	SSL cert file	None

Development vs Production:

Dev: uvicorn main:app --reload --log-level debug
Prod: uvicorn main:app --host 0.0.0.0 --port 8000 --workers 4
Prod (Gunicorn): gunicorn main:app -w 4 -k uvicorn.workers.UvicornWorker

Using Gunicorn with Uvicorn workers is recommended for production because Gunicorn manages worker processes (restart on crash, graceful shutdown), while Uvicorn handles async connections within each worker.

Pseudo Code

# Development
uvicorn module:variable --reload

# Production (Uvicorn only)
uvicorn module:variable --host 0.0.0.0 --workers N

# Production (Gunicorn + Uvicorn workers)
gunicorn module:variable -w N -k uvicorn.workers.UvicornWorker

# Programmatic
import uvicorn
uvicorn.run("module:variable", host, port, reload)

Code

# Different ways to run a FastAPI app

# 1. Command line (most common)
# Development:
#   uvicorn main:app --reload
# Production:
#   uvicorn main:app --host 0.0.0.0 --port 8000 --workers 4
# With Gunicorn (production):
#   gunicorn main:app -w 4 -k uvicorn.workers.UvicornWorker

# 2. Programmatic (useful for debugging)
from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def root():
    return {"status": "running"}

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(
        "main:app",     # Must be string for reload to work
        host="127.0.0.1",
        port=8000,
        reload=True,     # Development only
        log_level="info",
    )

# 3. Verify with TestClient (no server needed)
from fastapi.testclient import TestClient
client = TestClient(app)
print(client.get("/").json())

{'status': 'running'}

Key Points

•uvicorn main:app --reload for development; add --host 0.0.0.0 --workers N for production
•main:app means the 'app' variable in 'main.py' -- both parts are customizable
•Gunicorn with UvicornWorker is the recommended production setup for process management
•Programmatic uvicorn.run() requires string app reference ('main:app') when reload=True

Gotchas

•--reload watches all files including data files -- use --reload-dir to limit scope
•--workers > 1 is incompatible with --reload (reload only works with single worker)
•uvicorn.run(app) with the object directly works but breaks reload since it cannot re-import

Run with uvicorn main:app --reload for development. For production, use uvicorn main:app --host 0.0.0.0 --workers 4 or gunicorn main:app -w 4 -k uvicorn.workers.UvicornWorker for process management.

•main:app = 'app' variable in 'main.py'; --reload for dev only

# Development
# uvicorn main:app --reload

# Production
# uvicorn main:app --host 0.0.0.0 --port 8000 --workers 4

# Programmatic
if __name__ == "__main__":
    import uvicorn
    uvicorn.run("main:app", host="127.0.0.1", port=8000, reload=True)

--workers and --reload cannot be used together

Question 10 / 15

What are path operations in FastAPI?

A path operation in FastAPI is the combination of an HTTP method and a URL path. The term comes from the OpenAPI specification where each endpoint is called an "operation" on a "path".

Components:

Path: The URL (e.g., /items/{item_id})
Operation: The HTTP method (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD, TRACE)
Decorator: @app.get(), @app.post(), etc.
Function: The handler that runs when the path + method match

HTTP method semantics:

Method	Purpose	Idempotent	Has Body
GET	Read	Yes	No
POST	Create	No	Yes
PUT	Full update	Yes	Yes
PATCH	Partial update	No*	Yes
DELETE	Remove	Yes	Optional

Decorator parameters:

status_code: Default response status
tags: Group in docs
summary: Short description
description: Long description (overrides docstring)
response_model: Output schema
deprecated: Mark as deprecated
responses: Additional response schemas

Pseudo Code

# A path operation = HTTP method + URL path + handler function

@app.METHOD("/path")
def handler(params):
    # Process request
    return response

# FastAPI provides decorators for all HTTP methods:
# @app.get()    - Read
# @app.post()   - Create
# @app.put()    - Full replace
# @app.patch()  - Partial update
# @app.delete() - Remove
# @app.options(), @app.head(), @app.trace()

Code

from fastapi import FastAPI
from fastapi.testclient import TestClient
from pydantic import BaseModel

app = FastAPI()

class Item(BaseModel):
    name: str
    price: float

# Store for demonstration
items_db: dict[int, dict] = {}
next_id = 1

@app.get("/items/", tags=["items"], summary="List all items")
def list_items():
    """Retrieve all items from the store."""
    return list(items_db.values())

@app.post("/items/", status_code=201, tags=["items"])
def create_item(item: Item):
    global next_id
    record = {"id": next_id, **item.model_dump()}
    items_db[next_id] = record
    next_id += 1
    return record

@app.get("/items/{item_id}", tags=["items"])
def get_item(item_id: int):
    return items_db.get(item_id, {"error": "not found"})

@app.put("/items/{item_id}", tags=["items"])
def replace_item(item_id: int, item: Item):
    items_db[item_id] = {"id": item_id, **item.model_dump()}
    return items_db[item_id]

@app.delete("/items/{item_id}", status_code=204, tags=["items"])
def delete_item(item_id: int):
    items_db.pop(item_id, None)

client = TestClient(app)

# POST -- create
resp = client.post("/items/", json={"name": "Widget", "price": 9.99})
print(f"POST: {resp.status_code} {resp.json()}")

# GET -- read
resp = client.get("/items/1")
print(f"GET:  {resp.status_code} {resp.json()}")

# PUT -- update
resp = client.put("/items/1", json={"name": "Gadget", "price": 19.99})
print(f"PUT:  {resp.status_code} {resp.json()}")

# DELETE -- remove
resp = client.delete("/items/1")
print(f"DEL:  {resp.status_code}")

POST: 201 {'id': 1, 'name': 'Widget', 'price': 9.99}
GET:  200 {'id': 1, 'name': 'Widget', 'price': 9.99}
PUT:  200 {'id': 1, 'name': 'Gadget', 'price': 19.99}
DEL:  204

Key Points

•A path operation = HTTP method decorator + URL path + handler function
•FastAPI has dedicated decorators: @app.get(), @app.post(), @app.put(), @app.patch(), @app.delete()
•Decorator parameters control status code, tags, summary, response model, and deprecation
•Each HTTP method has specific semantics: GET reads, POST creates, PUT replaces, DELETE removes

Gotchas

•PUT replaces the entire resource; PATCH updates partial fields -- do not confuse them
•DELETE returning 204 means no content -- the response body is empty
•The function name is used as the operation_id in OpenAPI -- keep them unique

Path operations combine an HTTP method with a URL path via decorators like @app.get("/items/"). FastAPI provides @app.get(), @app.post(), @app.put(), @app.patch(), @app.delete() for standard CRUD operations.

•Each HTTP method has a decorator: @app.get(), @app.post(), @app.put(), @app.delete()
•status_code parameter sets the default response code

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Item(BaseModel):
    name: str

@app.get("/items/")
def list_items():
    return []

@app.post("/items/", status_code=201)
def create_item(item: Item):
    return item.model_dump()

Handler function names must be unique -- they become operation IDs in the OpenAPI schema

Question 11 / 15

How does FastAPI handle automatic data serialization?

FastAPI automatically serializes return values to JSON using a multi-step process:

Serialization pipeline:

Return value from your handler (dict, Pydantic model, list, etc.)
response_model filtering -- if response_model is set, the output is filtered through that Pydantic model (removes extra fields, applies aliases)
JSON-compatible conversion -- FastAPI's jsonable_encoder() converts Python objects to JSON-compatible types (datetime -> string, UUID -> string, Pydantic model -> dict)
JSONResponse -- wraps the result in a JSONResponse with proper Content-Type headers

What gets auto-serialized:

dict and list -- passed directly
Pydantic BaseModel -- converted via .model_dump()
datetime, date, time -- ISO 8601 strings
UUID -- string representation
Enum -- .value
bytes -- base64 encoded
SQLAlchemy models -- converted if response_model is set
Nested combinations of all the above

jsonable_encoder:

This utility function converts any Python object to a JSON-safe structure. Useful when you need to serialize data outside of a response (e.g., before storing in a DB).

Pseudo Code

# FastAPI serialization pipeline
def handle_response(return_value, response_model=None):
    if response_model:
        # Filter through Pydantic model
        return_value = response_model.model_validate(return_value)
    
    # Convert to JSON-compatible dict
    json_data = jsonable_encoder(return_value)
    # datetime -> "2024-01-15T..."
    # UUID -> "550e8400-..."
    # Pydantic model -> dict
    
    return JSONResponse(content=json_data)

Code

from datetime import datetime, date
from uuid import UUID, uuid4
from enum import Enum
from fastapi import FastAPI
from fastapi.encoders import jsonable_encoder
from fastapi.testclient import TestClient
from pydantic import BaseModel

app = FastAPI()

class Status(str, Enum):
    active = "active"
    inactive = "inactive"

class UserDB(BaseModel):
    """Full user model (internal)."""
    id: UUID
    name: str
    email: str
    hashed_password: str  # Should NOT be in response
    status: Status
    created_at: datetime

class UserResponse(BaseModel):
    """Filtered user model (API response)."""
    id: UUID
    name: str
    email: str
    status: Status
    created_at: datetime

@app.get("/user", response_model=UserResponse)
def get_user():
    # Return full DB model -- response_model filters out hashed_password
    return UserDB(
        id=uuid4(),
        name="Alice",
        email="alice@example.com",
        hashed_password="$2b$12$secret",
        status=Status.active,
        created_at=datetime(2024, 1, 15, 10, 30),
    )

# Using jsonable_encoder directly
data = {
    "id": uuid4(),
    "created": datetime.now(),
    "date": date.today(),
}
encoded = jsonable_encoder(data)
print(f"UUID type: {type(encoded['id'])}")
print(f"Datetime type: {type(encoded['created'])}")

client = TestClient(app)
resp = client.get("/user")
user = resp.json()
print(f"Has password: {'hashed_password' in user}")
print(f"Has email: {'email' in user}")
print(f"Status: {user['status']}")

UUID type: <class 'str'>
Datetime type: <class 'str'>
Has password: False
Has email: True
Status: active

Key Points

•FastAPI auto-serializes dicts, Pydantic models, datetimes, UUIDs, Enums to JSON
•response_model filters output -- prevents internal fields (like passwords) from leaking
•jsonable_encoder() converts any Python object to JSON-compatible types
•Pydantic models are serialized via model_dump(), not manually

Gotchas

•Without response_model, ALL fields in the returned dict/model are included in the response
•SQLAlchemy models need response_model to serialize properly -- they are not Pydantic models
•jsonable_encoder converts in-place for dicts -- it does not deep-copy

FastAPI auto-serializes return values to JSON. Dicts, Pydantic models, datetimes, UUIDs, and Enums are all converted automatically. Use response_model to filter which fields appear in the response.

•Return dicts, Pydantic models, or complex types -- FastAPI serializes to JSON
•response_model filters out fields not in the schema

from fastapi import FastAPI
from pydantic import BaseModel
from datetime import datetime

app = FastAPI()

class UserOut(BaseModel):
    name: str
    joined: datetime

@app.get("/user", response_model=UserOut)
def get_user():
    # datetime auto-serialized to ISO string
    return {"name": "Alice", "joined": datetime.now(), "secret": "hidden"}
    # "secret" is filtered out by response_model

Without response_model, all returned fields are exposed -- including sensitive data

Question 12 / 15

What is the OpenAPI schema and how does FastAPI use it?

The OpenAPI Specification (formerly Swagger) is a standard format for describing REST APIs. It defines endpoints, parameters, request/response schemas, authentication, and more in a machine-readable JSON or YAML document.

FastAPI generates OpenAPI 3.1:

FastAPI builds the OpenAPI schema automatically from:

Route decorators (@app.get, @app.post, etc.)
Path/query/header/cookie parameters with types
Pydantic models (request bodies, response models)
Docstrings and description parameters
Tags, deprecation markers, status codes

Schema structure:

{
  "openapi": "3.1.0",
  "info": {"title": "...", "version": "..."},
  "paths": {
    "/items/": {
      "get": { ... },
      "post": { ... }
    }
  },
  "components": {
    "schemas": { ... }  // Pydantic model definitions
  }
}

What uses the schema:

Swagger UI (/docs) -- interactive API explorer
ReDoc (/redoc) -- clean API documentation
Code generators -- generate client SDKs in any language
API testing tools -- Postman, Insomnia can import it
API gateways -- validate requests against the schema

Pseudo Code

# How FastAPI builds the OpenAPI schema

1. At startup, iterate all registered routes
2. For each route:
   a. Extract HTTP method and path
   b. Inspect function signature for parameters
   c. Convert Pydantic models to JSON Schema
   d. Collect tags, summary, description, status codes
3. Assemble into OpenAPI 3.1 document
4. Cache the result (generated once)
5. Serve at /openapi.json

Code

from fastapi import FastAPI, Query
from pydantic import BaseModel
import json

app = FastAPI(
    title="Pet Store",
    version="1.0.0",
    description="A sample API",
)

class Pet(BaseModel):
    name: str
    species: str
    age: int

@app.get("/pets/", response_model=list[Pet], tags=["pets"])
def list_pets(limit: int = Query(default=10, le=100)):
    """List all pets with optional limit."""
    return []

@app.post("/pets/", response_model=Pet, status_code=201, tags=["pets"])
def create_pet(pet: Pet):
    """Add a new pet."""
    return pet

# Access the generated OpenAPI schema
schema = app.openapi()

# Explore the schema structure
print(f"OpenAPI version: {schema['openapi']}")
print(f"Title: {schema['info']['title']}")
print(f"Paths: {list(schema['paths'].keys())}")
print(f"Methods for /pets/: {list(schema['paths']['/pets/'].keys())}")
print(f"Schemas: {list(schema.get('components', {}).get('schemas', {}).keys())}")

# The raw schema is available at /openapi.json
# print(json.dumps(schema, indent=2))  # Full schema

OpenAPI version: 3.1.0
Title: Pet Store
Paths: ['/pets/']
Methods for /pets/: ['get', 'post']
Schemas: ['Pet', 'ValidationError', 'HTTPValidationError']

Key Points

•OpenAPI is a standard specification for describing REST APIs in machine-readable format
•FastAPI auto-generates OpenAPI 3.1 from type hints, Pydantic models, and decorators
•The schema is served at /openapi.json and consumed by Swagger UI and ReDoc
•Code generators and API tools (Postman, etc.) can import the schema to build clients

Gotchas

•The schema is cached after first generation -- changes require app restart or clearing app.openapi_schema
•OpenAPI 3.1 uses JSON Schema 2020-12, which differs slightly from OpenAPI 3.0's subset
•Custom response types (StreamingResponse, FileResponse) do not auto-generate schemas -- document them manually with responses={}

OpenAPI is a standard format for describing REST APIs. FastAPI auto-generates an OpenAPI 3.1 schema at /openapi.json from your routes and Pydantic models. Swagger UI (/docs) and ReDoc (/redoc) render this schema as interactive documentation.

•OpenAPI schema auto-generated at /openapi.json from your code

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI(title="My API")

class Item(BaseModel):
    name: str

@app.get("/items/", response_model=list[Item])
def list_items():
    return []

schema = app.openapi()
print(schema["openapi"])  # '3.1.0'

3.1.0

Schema is cached on first access -- restart the app to regenerate after code changes

Question 13 / 15

How do you add metadata to your FastAPI application (title, version, description)?

FastAPI accepts metadata parameters that populate the OpenAPI schema and appear in the auto-generated documentation.

App-level metadata:

title -- API name (shown as heading in docs)
description -- Supports Markdown, appears below the title
version -- API version string
terms_of_service -- URL to terms
contact -- Dict with name, url, email
license_info -- Dict with name, url
openapi_url -- Path for the schema (default: /openapi.json)
docs_url -- Path for Swagger UI (default: /docs)
redoc_url -- Path for ReDoc (default: /redoc)

Tag metadata:

You can describe tags with openapi_tags to add descriptions and external doc links to each tag group in the docs.

Route-level metadata:

summary -- Short description (or the function name)
description -- Detailed description (or the docstring)
response_description -- Description of the response
tags -- List of tag strings
deprecated -- Boolean to mark as deprecated

Pseudo Code

# App-level metadata
app = FastAPI(
    title="...",
    description="Markdown supported",
    version="1.0.0",
    contact={name, email, url},
    license_info={name, url},
)

# Tag descriptions
app = FastAPI(openapi_tags=[
    {name, description, externalDocs}
])

# Route-level metadata
@app.get("/path", summary="...", tags=["tag"])
def handler():
    """Docstring becomes description."""

Code

from fastapi import FastAPI

# Define tag metadata
tags_metadata = [
    {
        "name": "users",
        "description": "Operations with users. Manage user accounts.",
    },
    {
        "name": "items",
        "description": "Manage items in the store.",
        "externalDocs": {
            "description": "External docs",
            "url": "https://example.com/docs",
        },
    },
]

app = FastAPI(
    title="My Awesome API",
    description="""## A full-featured API

This API supports:
- **User management**
- **Item CRUD operations**

> Markdown is fully supported in descriptions.
""",
    version="2.1.0",
    terms_of_service="https://example.com/terms",
    contact={
        "name": "API Support Team",
        "url": "https://example.com/support",
        "email": "support@example.com",
    },
    license_info={
        "name": "MIT",
        "url": "https://opensource.org/licenses/MIT",
    },
    openapi_tags=tags_metadata,
)

@app.get(
    "/users/",
    tags=["users"],
    summary="List all users",
    response_description="A list of user objects",
)
def list_users():
    """Retrieve all registered users.

    This endpoint returns a paginated list.
    """
    return []

@app.get("/items/", tags=["items"], deprecated=True)
def list_items_v1():
    """Deprecated: Use /v2/items/ instead."""
    return []

schema = app.openapi()
print(f"Title: {schema['info']['title']}")
print(f"Version: {schema['info']['version']}")
print(f"Contact: {schema['info']['contact']['name']}")
print(f"License: {schema['info']['license']['name']}")

Title: My Awesome API
Version: 2.1.0
Contact: API Support Team
License: MIT

Key Points

•Pass title, description, version, contact, and license_info to FastAPI() constructor
•description supports full Markdown formatting in the docs
•openapi_tags adds descriptions to tag groups shown in Swagger UI and ReDoc
•Route-level summary, description, tags, and deprecated customize each endpoint's docs

Gotchas

•The docstring of a handler function becomes the description in docs -- summary defaults to function name if not set
•Setting docs_url=None disables Swagger UI entirely (useful for production)
•openapi_tags order determines the display order of tag groups in the docs

Pass title, description, version, contact, and license_info to FastAPI(). Use openapi_tags for tag descriptions. Route-level metadata uses summary, tags, and deprecated parameters.

•Metadata is passed to FastAPI() and appears in auto-generated docs

from fastapi import FastAPI

app = FastAPI(
    title="My API",
    description="A sample API with metadata",
    version="1.0.0",
    contact={"name": "Support", "email": "help@example.com"},
)

@app.get("/items/", tags=["items"], summary="List items")
def list_items():
    """Retrieve all items."""  # becomes description in docs
    return []

docstring becomes the route description; summary defaults to function name if omitted

Question 14 / 15

What is the difference between Swagger UI and ReDoc in FastAPI?

FastAPI serves two documentation UIs that both consume the same OpenAPI schema but present it differently:

Swagger UI (`/docs`)

Interactive: You can fill in parameters and execute API calls directly from the browser
Try it out: Has "Try it out" button for each endpoint
Authorization: Supports entering auth tokens/API keys for authenticated requests
Layout: Vertically stacked, operation-focused
Best for: Developers testing and debugging the API during development

ReDoc (`/redoc`)

Read-only: No ability to execute API calls
Three-panel layout: Navigation, content, and code samples side by side
Clean design: Better for documentation that will be shared with consumers
Search: Built-in search across all endpoints
Best for: API documentation for external consumers, stakeholders

Customization:

Both can be disabled or moved to different URLs. You can also replace them with custom documentation pages.

Feature	Swagger UI	ReDoc
URL	`/docs`	`/redoc`
Interactive	Yes	No
Try requests	Yes	No
Auth support	Yes	No
Search	No	Yes
Layout	Single column	Three panel

Pseudo Code

# Both UIs read from the same OpenAPI schema
schema = GET /openapi.json

# Swagger UI renders at /docs
#   -> Interactive, "Try it out" button, auth support

# ReDoc renders at /redoc
#   -> Read-only, three-panel, cleaner layout

# Disable either or both:
app = FastAPI(docs_url=None)     # No Swagger
app = FastAPI(redoc_url=None)    # No ReDoc
app = FastAPI(docs_url=None, redoc_url=None)  # No docs

Code

from fastapi import FastAPI

# Default: both enabled
app_default = FastAPI(title="Default Docs")
# Swagger UI at /docs, ReDoc at /redoc

# Custom paths
app_custom = FastAPI(
    title="Custom Paths",
    docs_url="/api/docs",      # Move Swagger UI
    redoc_url="/api/redoc",    # Move ReDoc
    openapi_url="/api/openapi.json",  # Move schema
)

# Disable both (production)
app_no_docs = FastAPI(
    title="No Docs",
    docs_url=None,
    redoc_url=None,
)

# Disable only ReDoc
app_swagger_only = FastAPI(
    title="Swagger Only",
    redoc_url=None,
)

print(f"Default docs_url: /docs")
print(f"Custom docs_url: /api/docs")
print(f"No docs: docs_url=None, redoc_url=None")

# Check that the openapi schema still generates
schema = app_no_docs.openapi()
print(f"Schema still generated: {'info' in schema}")

Default docs_url: /docs
Custom docs_url: /api/docs
No docs: docs_url=None, redoc_url=None
Schema still generated: True

Key Points

•Swagger UI (/docs) is interactive -- execute API calls directly from the browser
•ReDoc (/redoc) is read-only with a clean three-panel layout for documentation
•Both consume the same OpenAPI schema from /openapi.json
•Either or both can be disabled by setting docs_url=None or redoc_url=None

Gotchas

•Disabling docs_url and redoc_url does NOT disable the OpenAPI schema -- /openapi.json is still accessible unless you set openapi_url=None
•Swagger UI's 'Try it out' sends real requests to your API -- be careful with destructive operations
•Custom OAuth2 flows in Swagger UI require additional configuration via swagger_ui_init_oauth

Swagger UI (/docs) is interactive -- you can test API calls in the browser. ReDoc (/redoc) is read-only with a cleaner layout for documentation. Both read the same OpenAPI schema. Either can be disabled with docs_url=None or redoc_url=None.

•Swagger UI is interactive with 'Try it out'; ReDoc is read-only with cleaner layout

from fastapi import FastAPI

# Both enabled by default
app = FastAPI(title="My API")
# /docs  -> Swagger UI (interactive)
# /redoc -> ReDoc (read-only)

# Disable for production
# app = FastAPI(docs_url=None, redoc_url=None)

Setting docs_url=None does not disable /openapi.json -- set openapi_url=None to fully hide the schema

Question 15 / 15

How does FastAPI achieve high performance compared to other Python frameworks?

FastAPI is one of the fastest Python web frameworks. Its performance comes from multiple layers:

1. ASGI + Uvicorn

Uvicorn uses uvloop (a C-based event loop, 2-4x faster than asyncio) and httptools (a C-based HTTP parser)
ASGI allows handling thousands of concurrent connections with a single process

2. Starlette

Minimal overhead routing with compiled path matching
Lightweight request/response objects
No unnecessary middleware in the default stack

3. Pydantic v2 (Rust core)

Pydantic v2 rewrote the validation engine in Rust (pydantic-core)
5-50x faster than Pydantic v1 for validation and serialization
This directly impacts every request that uses models

4. Async I/O

async def handlers run on the event loop without blocking
While waiting for DB/HTTP/file I/O, the server handles other requests
A single Uvicorn worker can handle thousands of concurrent I/O-bound requests

5. Sync handler optimization

def (non-async) handlers run in a thread pool, avoiding event loop blocking
FastAPI detects which handlers are async and routes them appropriately

Performance context:

For I/O-bound work: FastAPI ~ Node.js, Go (thousands of concurrent requests)
For CPU-bound work: Same as any Python framework (limited by GIL)
Benchmarks show FastAPI handling 2-5x more requests/sec than Flask for concurrent workloads

Pseudo Code

# Why FastAPI is fast -- layered optimizations

Layer 1: Uvicorn (server)
  - uvloop: C-based event loop (2-4x faster than asyncio)
  - httptools: C-based HTTP parser

Layer 2: Starlette (framework)
  - Compiled path matching
  - Lightweight request/response
  - Minimal middleware overhead

Layer 3: Pydantic v2 (validation)
  - Rust-based core (pydantic-core)
  - 5-50x faster than Pydantic v1

Layer 4: async/await (concurrency)
  - Non-blocking I/O
  - Single process handles thousands of connections
  - sync def handlers auto-routed to thread pool

Code

import asyncio
from fastapi import FastAPI
from fastapi.testclient import TestClient
import time

app = FastAPI()

# Async handler -- non-blocking, runs on event loop
@app.get("/async")
async def async_handler():
    # In real code: async DB query, async HTTP call, etc.
    await asyncio.sleep(0.01)  # Non-blocking
    return {"handler": "async"}

# Sync handler -- auto-runs in thread pool
@app.get("/sync")
def sync_handler():
    # Blocking code is OK here -- FastAPI uses a thread pool
    time.sleep(0.01)
    return {"handler": "sync"}

# Performance benefit of async: concurrent requests
# With async handlers, while one request awaits I/O,
# the server processes other requests on the same thread.

# Pydantic v2 performance (Rust core)
from pydantic import BaseModel

class Item(BaseModel):
    name: str
    price: float
    tags: list[str] = []

# Validation is fast because pydantic-core is written in Rust
start = time.perf_counter()
for _ in range(10000):
    Item(name="Widget", price=9.99, tags=["sale"])
elapsed = time.perf_counter() - start
print(f"10k Pydantic v2 validations: {elapsed:.3f}s")

client = TestClient(app)
print(client.get("/async").json())
print(client.get("/sync").json())

10k Pydantic v2 validations: 0.0XXs
{'handler': 'async'}
{'handler': 'sync'}

Key Points

•Uvicorn uses uvloop (C event loop) and httptools (C HTTP parser) for raw speed
•Pydantic v2's Rust core (pydantic-core) makes validation 5-50x faster than v1
•Async handlers enable handling thousands of concurrent I/O-bound requests per worker
•Sync def handlers are auto-routed to a thread pool so they do not block the event loop

Gotchas

•FastAPI performance gains are for I/O-bound work -- CPU-bound tasks are still limited by Python's GIL
•Using blocking libraries (requests, time.sleep) in async def handlers negates all performance benefits
•Benchmarks vary wildly based on workload type -- always profile your specific use case

FastAPI's speed comes from Uvicorn (C-based event loop + HTTP parser), Starlette (minimal overhead), Pydantic v2 (Rust validation core), and native async/await. For I/O-bound work, it rivals Node.js and Go. For CPU-bound work, it is still limited by Python's GIL.

•Speed from: Uvicorn (C event loop), Pydantic v2 (Rust core), async I/O

from fastapi import FastAPI
import asyncio

app = FastAPI()

# Async: runs on event loop, handles many concurrent requests
@app.get("/fast")
async def fast():
    await asyncio.sleep(0.01)  # Non-blocking I/O
    return {"speed": "fast"}

# Sync: auto-threaded, won't block event loop
@app.get("/also-fast")
def also_fast():
    return {"speed": "also fast"}

Using blocking I/O in async def handlers kills performance -- use sync def or async libraries

Built by onllm.dev

Home GitHub Support awesomePrep

What is FastAPI and what are its key features?

Key features:

Why it is popular:

How does FastAPI compare to Flask and Django?

FastAPI vs Flask vs Django

When to choose each:

Performance:

What is ASGI and how does it differ from WSGI?

WSGI (Web Server Gateway Interface)

ASGI (Asynchronous Server Gateway Interface)

Key differences:

Why ASGI matters for FastAPI:

What role does Starlette play in FastAPI?

What Starlette provides to FastAPI:

What FastAPI adds on top:

The inheritance chain:

What role does Pydantic play in FastAPI?

1. Request body validation

2. Response serialization

3. OpenAPI schema generation

4. Settings management

Key Pydantic v2 features used in FastAPI:

How do you install and create a basic FastAPI application?

Installation

Creating a basic app:

Running the app:

How does FastAPI automatically generate OpenAPI/Swagger documentation?

How it works:

What gets documented automatically:

Customizing docs:

What is the typical project structure for a FastAPI application?

Small project (single file):

Medium project (package):

Large project (domain-driven):

Key principles:

How do you run a FastAPI application with Uvicorn?

Command line usage:

Common options:

Development vs Production:

What are path operations in FastAPI?

Components:

HTTP method semantics:

Decorator parameters:

How does FastAPI handle automatic data serialization?

Serialization pipeline:

What gets auto-serialized:

jsonable_encoder:

What is the OpenAPI schema and how does FastAPI use it?

FastAPI generates OpenAPI 3.1:

Schema structure:

What uses the schema:

How do you add metadata to your FastAPI application (title, version, description)?

App-level metadata:

Tag metadata:

Route-level metadata:

What is the difference between Swagger UI and ReDoc in FastAPI?

Swagger UI (/docs)

ReDoc (/redoc)

Customization:

How does FastAPI achieve high performance compared to other Python frameworks?

1. ASGI + Uvicorn

2. Starlette

3. Pydantic v2 (Rust core)

4. Async I/O

5. Sync handler optimization

Performance context:

Core Framework & Fundamentals

Swagger UI (`/docs`)

ReDoc (`/redoc`)