fastapi
Building HTTP APIs with FastAPI and Pydantic.
-
Enforcing Client Identity Alongside Realm Roles
A Keycloak realm role lives on the user, not on the client, so a token minted for a low-trust public application can carry the same role claim as one minted for a trusted backend. This shows how to close that gap in a FastAPI dependency by checking the azp claim against an allow-list alongside the usual signature, issuer and role checks, with a self-contained pytest suite.
-
An OpenAI-Compatible Proxy in Front of a Local Model Server
Local model servers speak a shape close enough to the OpenAI API that existing SDKs and tools can point at them unmodified, but close enough is not the same as safe to expose. This builds a small FastAPI proxy that adds authentication and a health check that cannot itself trigger a model load.
-
One Dashboard on Five Unrelated Backends: Normalising at the Boundary
A dashboard that calls a ticketing system and a CI system directly inherits their different pagination styles, error shapes and auth schemes. This article builds a FastAPI backend-for-frontend that normalises both into one schema, degrades gracefully when an upstream is down, and shows how to test each adapter without touching a real upstream.
-
Closed-Vocabulary Pydantic Validation for a Public Ingest Endpoint
Pydantic ignores fields it does not recognise by default, so a client with a typo'd field name or an out-of-vocabulary value gets a 200 response and never learns their request did not do what they thought. This shows how to close the vocabulary with extra="forbid" and Literal types, and what that choice costs in forward compatibility.
-
An Exception Hierarchy and One Handler for FastAPI Error Responses
Raising HTTPException directly from inside route and service code gives every error path its own idea of what the response body should contain, and throws away the specific context that would make the error debuggable. This builds a small domain exception hierarchy and a single handler that turns any of them into a consistent, informative response.
-
Designing a Consistent FastAPI Response Envelope
When some endpoints return a bare object, others a list, and others a hand-rolled dict with a status field, every client has to special-case each one. This works through a generic response envelope built on Pydantic generics, a custom route class that applies it without repeating boilerplate in every endpoint, and the trade-offs that come with wrapping everything uniformly.
-
A Feature-Module Layout for a FastAPI Application That Keeps Growing
A FastAPI project that starts as one main.py and one routers.py works fine for the first few endpoints, then becomes a file everyone edits and nobody owns. This lays out a feature-module structure where each feature carries its own router, schemas and service code, with a complete runnable example and a test proving a new feature needs no change to existing files.