Chapter 10 — Django & Flask Compared

Conventions reduce local choices; flexibility increases local choices. Both have costs.

FastAPI:

from fastapi import FastAPI
 
app = FastAPI()
 
 
@app.get("/health")
def health() -> dict[str, str]:
    return {"status": "ok"}

Flask:

from flask import Flask, jsonify
 
app = Flask(__name__)
 
 
@app.get("/health")
def health():
    return jsonify({"status": "ok"})

Django (view):

from django.http import JsonResponse
 
 
def health(request):
    return JsonResponse({"status": "ok"})

All can serve APIs well; surrounding ecosystem and defaults drive long-term fit.

Django built-ins:

• ORM, migrations, auth, admin, templating, forms.

Flask built-ins:

• routing and request lifecycle only; extensions provide ORM/auth/migrations.

FastAPI built-ins:

• API routing, OpenAPI generation, Pydantic validation, async support.

Surface area choices influence delivery speed and consistency.

FastAPI natively centers ASGI and async handlers.

Django supports ASGI in modern versions, but many legacy projects remain primarily sync-oriented.

Flask is traditionally WSGI-first; async support exists but ecosystem choices vary.

Async readiness matters most for high-concurrency I/O and websocket-heavy workloads.

Django provides cohesive testing and migration tooling with convention-driven project layouts.

Flask offers flexibility but requires explicit tool stack decisions.

FastAPI pairs well with pytest and Alembic, but architecture discipline is team-defined rather than framework-imposed.

Migrations are usually incremental:

• keep existing framework core,
• extract isolated service boundaries,
• add gateway layer for coexistence,
• move one domain at a time.

Big-bang rewrites rarely land on schedule.