Litestar

The other modern ASGI framework. Low interview probability on its own, but knowing it exists — and why it exists — is a useful signal about how you evaluate tools.

What it is

An ASGI framework in the same space as FastAPI: type-driven, async-native, automatic OpenAPI. It began as a fork-in-spirit of FastAPI’s ideas with different opinions about structure and dependency injection.

from litestar import Litestar, get, post
from pydantic import BaseModel

class UserDTO(BaseModel):
    name: str
    email: str

@get("/users/{user_id:int}")
async def get_user(user_id: int) -> UserDTO:
    return await load_user(user_id)

@post("/users")
async def create_user(data: UserDTO) -> UserDTO:
    return await save_user(data)

app = Litestar([get_user, create_user])

Note the shape difference: handlers are collected and passed to the app, rather than registered onto it via decorators bound to an app instance.

Where it differs from FastAPI

Two genuine technical points:

• msgspec is faster than Pydantic for serialisation, so Litestar tends to benchmark better on throughput-heavy JSON workloads. Whether that matters depends on whether serialisation is your bottleneck, which it usually isn’t.
• Layered dependency injection means dependencies declared at app or controller level apply to everything below without repeating Depends() in each signature. Cleaner for large applications; less explicit at the call site.

The built-in SQLAlchemy plugin with repository patterns and DTOs removes a chunk of boilerplate that FastAPI leaves to you.

Would you choose it

Honest answer: usually not, and for non-technical reasons.

FastAPI’s ecosystem advantage is decisive — more tutorials, more StackOverflow answers, more third-party integrations, more people who already know it. On a team, that’s worth more than a serialisation benchmark.

Litestar is a reasonable choice when you’re starting fresh, the team values the layered DI and controller structure, and you’ll benefit from the built-in data-layer tooling.

The reasoning worth stating in an interview: ecosystem size is a legitimate technical criterion, not a cop-out. Time to resolve a problem matters more than requests per second on a framework that isn’t your bottleneck.

Interview angle

• “Have you looked at Litestar?” — an ASGI framework in FastAPI’s space with layered dependency injection, optional class-based controllers, msgspec serialisation and a built-in SQLAlchemy plugin. Technically credible; much smaller ecosystem.
• “Is it faster than FastAPI?” — on serialisation-heavy benchmarks, typically yes, because msgspec beats Pydantic there. That rarely decides anything, since serialisation is seldom the bottleneck in a real service.
• “Would you use it over FastAPI?” — usually not. The ecosystem gap dominates: fewer integrations, fewer answers when you hit a problem, fewer engineers who know it. Ecosystem size is a real technical criterion, not an excuse.
• “When would you pick it?” — a greenfield project where the layered DI and controller structure fit how the team wants to organise a large codebase, and the built-in SQLAlchemy repository tooling saves meaningful boilerplate.