Technology · Backend
FastAPI
Async Python · Pydantic validation · OpenAPI · Dependency injection
FastAPI is how a Python service gets a boundary worth trusting. Request and response shapes are declared as types and validated automatically, the OpenAPI documentation is generated from those same declarations rather than maintained beside them, and the async model handles the waiting that dominates any endpoint sitting in front of a model or a database.
How TrivialWorks uses it.
We reach for FastAPI when a Python capability needs to be callable by the rest of a system: a retrieval service, an inference endpoint, a data job's control surface. Because the schema is the code, the contract between a Node product API and a Python service cannot quietly drift — a mismatch fails at the boundary with a clear error rather than surfacing as strange behaviour three layers away. Its async model also suits AI endpoints particularly well, where a request spends most of its life waiting on something else.
Decision guide
Should your project use FastAPI?
Practical selection guidance — the conversation we would have with you before writing a line of code.
When it’s the right choice
- APIs in front of Python AI, ML or data capability, called by another service or a frontend
- Endpoints whose request and response contracts must be explicit, validated and self-documenting
- Model-backed and I/O-bound endpoints where async concurrency keeps a process useful while it waits
- Streaming responses — token-by-token model output delivered as it is generated rather than buffered to the end
When it isn’t
- A product API with no Python dimension — that is Node work for us, and introducing a second runtime to avoid it is a poor trade
- CPU-bound request handling, where Python's execution model makes it the wrong place for heavy computation inside the request path
- Server-rendered web applications with templates and sessions — a different class of framework fits that better
Consider Node.js — The service is product logic — our default, and one language across the stack.
Consider Django — You need a full web application with admin, ORM and auth included, rather than an API in front of Python capability.
Best use cases
Where FastAPI makes practical sense.
Retrieval and inference endpoints
RAG and model calls exposed as validated, documented APIs the rest of the system can depend on without reading the implementation.
Streaming AI responses
Model output streamed to the interface as it is produced, so a long answer feels immediate rather than absent then sudden.
Contracts between services
Typed schemas shared with a Node product API, so a change to either side surfaces as an error at the boundary rather than a bug in production.
Data job control surfaces
Endpoints to trigger, monitor and inspect pipeline runs, so operational work does not require shell access to a server.
Proof
Where it shows up in our work.
No published case study names this stack yet — most of our work ships under NDA, and we would rather show you nothing than invent something. The work ledger shows how we handle that honestly.
Related services
Services that commonly use it.
Questions
FastAPI, asked straight.
Why FastAPI rather than Express or Node for this service?
We would use Node — unless the service exists because of Python's AI and data libraries, which is the usual reason a Python service exists at all. At that point FastAPI gives it a typed, documented boundary. The decision is made by the ecosystem the work needs, not by preference for a framework.
How does a Python service fit with our Node application?
As a separate service behind a defined HTTP contract. The Node application stays the product — routing, authentication, business logic — and calls the Python service for the AI or data work. One boundary, typed on both sides, with each language doing what it is genuinely better at.
Is it fast enough for production traffic?
For the I/O-bound work these services do — waiting on models, databases and other APIs — comfortably, because async concurrency keeps the process busy while requests wait. Where a workload is CPU-bound, the honest answer is that it belongs somewhere other than inside a Python request handler, and we will say so.
Do we get API documentation?
Generated from the code, not written alongside it. FastAPI produces an OpenAPI schema and browsable docs from the same type declarations that validate requests, so the documentation cannot drift from behaviour — a distinction that matters most on the services other teams integrate against.
Thinking about FastAPI?
Send the requirement and you get back a functional specification — screens, data model, stack and an estimate — at no charge. If FastAPI is the wrong choice for it, that will be in there too.