Python- og FastAPI-backend — moderne og skalerbare API-er
FastAPI er det ledende Python-rammeverket for asynkrone REST-API-er. Det kombinerer Pythons innebygde type hints med automatisk Pydantic-validering, automatisk generert OpenAPI-dokumentasjon og asynkron kjøring på ASGI — uten at lesbarheten i koden går på bekostning.
FastAPI — asynkront Python-rammeverk på ASGI
FastAPI kjører på Uvicorn (ASGI-server) med Gunicorn for flere prosesser i produksjon. Endepunkter som leser fra Redis-cache, slipper spørringer mot databasen. Innebygd Dependency Injection gjør at hvert lag kan testes isolert uten komplekse mock-er: autentisering, databasesesjon og rate limiting er alle avhengigheter som kan injiseres.
OpenAPI 3.1-dokumentasjonen genereres automatisk fra type hints — Swagger UI og ReDoc er tilgjengelig på `/docs` og `/redoc` i utvikling. Pydantic v2 (med en valideringskjerne skrevet i Rust) validerer forespørsler og svar. Alle ugyldige felt returnerer en 422 med tydelige, lokaliserte feilmeldinger.
- Innebygd async/await — ikke-blokkerende I/O på alle DB- og HTTP-operasjoner
- BackgroundTasks for operasjoner etter svaret (e-post, webhook, logg)
- Innebygd WebSocket-støtte for sanntidsfunksjoner (chat, varsler)
- Rate limiting med slowapi (basert på limits) — per IP og per bruker
- Middleware for CORS, komprimering (gzip/brotli), request ID og timing
PostgreSQL, SQLAlchemy og Alembic
Vi bruker SQLAlchemy 2.0 async (asyncpg-driver) til alle databaseoperasjoner. Modellene er definert med Mapped-typer — typesikkert, uten strenger. Komplekse spørringer skrives i SQLAlchemy Core (kontrollert ved kompilering) eller ren SQL via `text()` med bind-parametere — aldri strenginterpolering (fullstendig forebygging av SQLi).
Alembic-migreringer genereres automatisk fra endringer i modellene og gjennomgås manuelt før de brukes. Hver migrering har testede `upgrade()` og `downgrade()`. I produksjon kjører migreringene i CI før utrulling — databasen er alltid synkronisert med koden. Connection pooling via asyncpg med pool-størrelse som kan konfigureres per tjeneste.
- Row-level locking med `SELECT ... FOR UPDATE` for kritiske samtidige operasjoner
- Fulltekstsøk med pg_trgm og tsvector — uten Elasticsearch i enkle tilfeller
- JSONB for semistrukturerte data med GIN-indeksering
- Partisjonerte tabeller for tabeller med millioner av rader (logger, hendelser)
Redis-caching og horisontal skalering
Redis 7 brukes til applikasjonscache (TTL per endepunkt), sesjonslagring (JWT refresh tokens med selektiv tilbakekalling), pub/sub for sanntidshendelser og køer for bakgrunnsjobber (Celery eller ARQ). Cachestrategien er cache-aside med eksplisitt ugyldiggjøring — ikke blind TTL som kan servere utdaterte data.
- JWT-autentisering med access token (15 min) + Redis refresh token (7 dager)
- Celery + Redis-broker for asynkrone oppgaver (PDF-generering, e-post, importer)
- Helsesjekk-endepunkt `/health` med status for DB, Redis og utrullingsversjon
- Strukturert JSON-logging (structlog) — kompatibelt med Loki/Datadog/ELK
Fordeler og begrensninger
Fordeler
- Innebygd async/await på ASGI, med ikke-blokkerende I/O.
- OpenAPI-dokumentasjon generert automatisk fra type hints.
- Rask Pydantic v2-validering med tydelige 422-feil.
- Lesbar kode, og Python er kjent for de fleste team.
Begrensninger
- Python er fortsatt tregere enn Go eller Rust på CPU-intensive oppgaver.
- async/await krever disiplin — ett blokkerende kall blokkerer hele event loop-en.
- Yngre økosystem enn Django når det gjelder batteries-included-funksjoner.
- Har ikke innebygd ORM eller admin — du velger dem separat.
Kort vurdering
Velg FastAPI for asynkrone REST-API-er, mikrotjenester og backend for SPA/mobil. For ekstremt CPU-bundne applikasjoner eller monolitter med ferdig admin kan henholdsvis Go og Django passe bedre.
Spesifikasjonstabell
| Egenskap | Grense / terskel | Typisk bruk | |
|---|---|---|---|
| Samtidighet | async/await, ikke-blokkerende I/O | CPU-bundne oppgaver krever separate workere | API-er med mange DB-/HTTP-kall |
| Latens | Redis-cache foran databasen på lesetunge endepunkter | Øker ved serialisering av store payloads | SaaS-backend, mobil, sanntid |
| Validering og dokumentasjon | Pydantic v2 + OpenAPI 3.1 automatisk | Komplekse skjemaer øker oppstartstiden | Offentlige API-er med Swagger/ReDoc |
| Typisk kostnad | Åpen kildekode, kjører på 1 vCPU | Horisontal skalering krever flere prosesser | Fra MVP til produksjon |
FastAPI mot alternativer
| Kriterium | FastAPI | Django / Express |
|---|---|---|
| Async-modell | Innebygd (ASGI) | Django delvis, Express ja |
| Automatisk OpenAPI-dokumentasjon | Ja, fra type hints | Krever ekstra pakker |
| Innebygd admin / ORM | Nei (du velger separat) | Django: ja; Express: nei |
Ofte stilte spørsmål
Hva er forskjellen på FastAPI og Django?
FastAPI kjører async på ASGI med ikke-blokkerende I/O, mens klassisk Django behandler forespørsler synkront. Django har til gjengjeld flere innebygde funksjoner, som admin og ORM.
Hva er FastAPI ikke egnet til?
For sterkt CPU-bundne oppgaver (bildebehandling, tung numerisk beregning) er Python tregere enn Go eller Rust; dem flytter du over på separate workere. Og det kommer ikke med ferdig admin slik som Django.
Trenger FastAPI en ORM?
Ikke nødvendigvis. Vi bruker SQLAlchemy 2.0 async med Alembic for migreringer, men du kan skrive ren SQL. ORM-en er ikke inkludert, så du velger den ut fra prosjektet.
Hvordan skalerer jeg en FastAPI-backend?
Horisontalt: du kjører flere Uvicorn-prosesser under Gunicorn, bak en lastbalanserer, med Redis-cache og tunge oppgaver flyttet til Celery. Stateless design gjør det mulig å legge til instanser ved behov.