Backend med Python & FastAPI — moderna och skalbara API:er
FastAPI är det ledande Python-ramverket för asynkrona REST-API:er. Det kombinerar Pythons inbyggda type hints med automatisk Pydantic-validering, automatiskt genererad OpenAPI-dokumentation och ASGI-prestanda i nivå med Node.js — utan att offra kodens läsbarhet.
FastAPI — Python-ramverket för API:er
FastAPI körs på Uvicorn (ASGI-server) med Gunicorn för flera processer i produktion. En enkel endpoint som läser från Redis-cache behöver inte fråga databasen vid varje förfrågan. Inbyggd Dependency Injection gör det möjligt att testa vilket lager som helst isolerat utan komplicerade mockar: autentisering, databassession, rate limiting — allt är ett injicerbart beroende.
OpenAPI 3.1-dokumentationen genereras automatiskt från type hints — Swagger UI och ReDoc finns på `/docs` och `/redoc` under utveckling. Pydantic v2-schemat (en Rust-baserad validerare) validerar förfrågningar och svar 10–20 gånger snabbare än Pydantic v1. Varje ogiltigt fält ger ett 422 med tydliga, lokaliserade felmeddelanden.
- Inbyggt async/await — icke-blockerande I/O för alla databas- och HTTP-operationer
- BackgroundTasks för operationer efter svaret (e-post, webhook, logg)
- Inbyggt WebSocket-stöd för realtidsfunktioner (chatt, notiser)
- Rate limiting med slowapi (baserat på limits) — per IP och per användare
- Middleware för CORS, komprimering (gzip/brotli), request ID och tidtagning
PostgreSQL, SQLAlchemy och Alembic
Vi använder SQLAlchemy 2.0 async (asyncpg-drivrutin) för alla databasoperationer. Modellerna definieras med Mapped-typer — typsäkra, utan strängar. Komplexa frågor skrivs i SQLAlchemy Core (kontrolleras vid kompilering) eller som ren SQL via `text()` med bind-parametrar — aldrig strängsammanfogning (fullständigt skydd mot SQL-injektion).
Alembic-migreringar genereras automatiskt från modelländringar och granskas manuellt innan de tillämpas. Varje migrering har testade `upgrade()` och `downgrade()`. I produktion körs migreringarna i CI före driftsättning — databasen är alltid i synk med koden. Connection pooling via asyncpg med poolstorlek som kan konfigureras per tjänst.
- Row-level locking med `SELECT ... FOR UPDATE` för kritiska samtidiga operationer
- Fulltextsökning med pg_trgm och tsvector — ingen Elasticsearch behövs i enkla fall
- JSONB för semistrukturerad data med GIN-indexering
- Partitionerade tabeller för tabeller med miljontals rader (loggar, händelser)
Redis-cache och horisontell skalning
Redis 7 används för applikationscache (TTL per endpoint), sessionslagring (JWT refresh tokens med selektiv återkallning), pub/sub för realtidshändelser och köer för bakgrundsjobb (Celery eller ARQ). Cachestrategin är cache-aside med explicit invalidering — inte blind TTL som kan servera föråldrad data.
- JWT-autentisering med access token (15 min) + refresh token i Redis (7 dagar)
- Celery + Redis-broker för asynkrona uppgifter (PDF-generering, e-post, importer)
- Health check-endpoint `/health` med status för DB, Redis och driftsättningsversion
- Strukturerad JSON-loggning (structlog) — kompatibel med Loki/Datadog/ELK
Fördelar och begränsningar
Fördelar
- ASGI-prestanda i nivå med Node.js och Go för I/O.
- OpenAPI-dokumentation som genereras automatiskt från type hints.
- Snabb Pydantic v2-validering med tydliga 422-fel.
- Läsbar kod, Python är bekant för de flesta team.
Begränsningar
- Python är fortfarande långsammare än Go eller Rust på CPU-intensiva uppgifter.
- async/await kräver disciplin — ett blockerande anrop blockerar hela event loopen.
- Yngre ekosystem än Django när det gäller batteries-included-funktioner.
- Innehåller ingen inbyggd ORM eller admin — du väljer dem separat.
Kort slutsats
Välj FastAPI för asynkrona REST-API:er, mikrotjänster och backends för SPA/mobil. För extremt CPU-bundna applikationer eller monoliter med färdig admin kan Go respektive Django passa bättre.
Specifikationstabell
| Förmåga | Gräns / tröskel | Typisk användning | |
|---|---|---|---|
| Samtidighet | async/await, icke-blockerande I/O | CPU-bundet arbete kräver separata workers | API:er med många DB-/HTTP-anrop |
| Latens | Läsning från Redis-cache utan databasanrop | Ökar med serialisering av stora payloads | SaaS-backend, mobil, realtid |
| Validering & dokumentation | Pydantic v2 + automatisk OpenAPI 3.1 | Komplext schema ökar starttiden | Publika API:er med Swagger/ReDoc |
| Typisk kostnad | Öppen källkod, körs på 1 vCPU | Horisontell skalning kräver fler processer | Från MVP till produktion |
FastAPI jämfört med alternativ
| Kriterium | FastAPI | Django / Express |
|---|---|---|
| Asynkron prestanda | Utmärkt (inbyggt ASGI) | Django delvis, Express bra |
| Automatisk OpenAPI-dokumentation | Ja, från type hints | Kräver extra paket |
| Inbyggd admin / ORM | Nej (du väljer separat) | Django: ja; Express: nej |
Vanliga frågor
Är FastAPI snabbare än Django?
Ja på I/O. FastAPI körs asynkront på ASGI och hanterar därför många fler samtidiga förfrågningar med DB-/HTTP-anrop än klassisk synkron Django. Django har däremot fler inbyggda funktioner.
Vad är FastAPI inte lämpligt för?
För mycket CPU-bundna uppgifter (bildbehandling, tung numerisk beräkning) är Python långsammare än Go eller Rust; dem flyttar du till separata workers. Och det följer inte med någon färdig admin som i Django.
Behöver FastAPI en ORM?
Inte nödvändigtvis. Vi använder SQLAlchemy 2.0 async med Alembic för migreringar, men du kan skriva ren SQL. ORM ingår inte, så du väljer den utifrån projektet.
Hur skalar jag en FastAPI-backend?
Horisontellt: du kör flera Uvicorn-processer under Gunicorn, bakom en lastbalanserare, med Redis-cache och tunga uppgifter flyttade till Celery. En tillståndslös design gör att du kan lägga till instanser vid behov.