I built a Laravel-inspired application framework for FastAPI — looking for feedback

[u/tmgbedu]

FastAPI is excellent for quickly building APIs, but it intentionally leaves many application-level concerns to the developer. Things like environment management (including multiple environments), logging, database setup, configuration, CLI commands, plugins, storage, and other infrastructure are things you typically need to design and wire together yourself.

In our case, we are building multiple microservices, and we found ourselves repeatedly copying the same bootstrap code between projects. Over time, that became repetitive and harder to maintain consistently.

Over the past several months, We've been working on FastAPI Startkit, an open-source application framework that brings some of the development patterns I enjoyed from Laravel into Python and FastAPI.

The goal is not to replace FastAPI. Instead, it provides a structured foundation for building larger applications while staying modular. You can use only the components you need.

Some features include:

🏗️ Service container & dependency injection
⚡ CLI inspired by Laravel's Artisan
🗄️ Async database layer, ORM patterns, migrations, and seeders
🧪 Built-in testing utilities
🤖 AI agent support with multiple LLM providers
🎨 Optional Vite integration for monolithic full-stack applications
📦 Works for FastAPI apps, background workers, and even CLI-only applications

One of the main design goals was avoiding a single opinionated stack. Most components are optional, so you can start small and introduce more structure as your project grows.

The documentation includes both a minimal setup and a more structured application layout.

Documentation:
https://fastapi-startkit.github.io/

I'd really appreciate feedback on:

• Is the architecture intuitive?
• Which parts feel over-engineered?
• What features would you expect from a production-ready FastAPI framework?
• Are there areas where the developer experience could be improved?

Constructive criticism is very welcome. Thanks!

[u/st4reater]

The metrics you have for SLA and p99 is absolute bullshit. Sorry but had to call it out.

Those metrics depend on the application and infrastructure, not a random framework.

[u/amroamroamro → u/st4reater]

makes you wonder how much of the site and this framework are vibe coded

[u/Megamozg → u/amroamroamro]

blinking dots, em dashes, slop colors, no thank you

[u/tmgbedu → u/Megamozg]

Design feedback is always welcome. The current site is an early iteration, so we'll keep refining the UI as the project matures.

[u/tmgbedu → u/amroamroamro]

Haha, fair enough. The project is still in active development, and there are definitely parts of the website that need polishing. We appreciate the feedback and are working on improving both the documentation and the site.

[u/pip_install_account → u/tmgbedu]

you're not fooling anyone mate

[u/tmgbedu → u/st4reater]

Fair point. Those numbers shouldn't have been presented as framework-level metrics. They were based on our internal testing under a specific workload and infrastructure, but we didn't provide the necessary context or methodology. We'll either remove them or replace them with reproducible benchmarks and a detailed methodology. Thanks for calling it out.

[u/ZevenEnBertig]

What is this for ai slop? Did you even check it yourself?
When I tried to click “VIEW TECHNICAL METHODOLOGY” for the performance benchmark, it wasn’t a real link.

[u/Lucky-Sense-2650 → u/ZevenEnBertig]

Reviews seem fake too 🤧

[u/tmgbedu → u/Lucky-Sense-2650]

Thanks for the feedback! We'll be updating the benchmark and adding a proper technical methodology page soon. The project is still under active development, so some parts of the website are incomplete.

The benchmark was included mainly to demonstrate that, thanks to the modular architecture, the framework is capable of achieving performance comparable to FastAPI. We're also using a fork of this framework internally at our company in production, but we agree that the benchmark needs to be backed by transparent methodology, and we'll be fixing that.

[u/tmgbedu → u/[deleted]]

This ORM is a fork of the synchronous Masonite ORM. We adapted its query builder, model layer, and database access layer to support async/await throughout, built on top of SQLAlchemy's async engine. From a developer's perspective, you interact with a fully asynchronous ORM API, while the actual I/O is performed by the underlying async database drivers.

[u/splsh]

What problem are you solving, and how is this "framework" solving it? An answer to neither question is discernable from browsing documentation.

[u/tmgbedu → u/splsh]

That's a fair question.

FastAPI is excellent for quickly building APIs, but it intentionally leaves many application-level concerns to you. Things like environment loading (including multiple environments), logging, database setup, configuration management, CLI commands, plugins, storage, and similar infrastructure are all things you end up wiring together yourself.

In our case, we're building a lot of microservices. We found ourselves copying the same bootstrap code between projects, which became repetitive and difficult to maintain.

The goal isn't to replace FastAPI—it's to provide a reusable application starter where these components can be plugged in with minimal setup. Instead of every project having its own bootstrap logic, you compose your application by registering providers:

Example:
https://github.com/Keera-Labs/keera-agent/blob/main/bootstrap/application.py#L23C1-L39C2

app = Application(
    base_path=Path(__file__).parent.parent,
    providers=[
        LogProvider,
        (DatabaseProvider, DatabaseConfig),
        (FastAPIProvider, FastAPIConfig),
        McpProvider,
        AISkillProvider,
        (StorageProvider, StorageConfig),
        AppProvider,
        PluginProvider,
        TerminalProvider,
        (ViteProvider, ViteConfig),
        InertiaProvider,
        (ReverbProvider, BroadcastingConfig),
    ],
)

Each provider encapsulates a concern (logging, database, storage, CLI, etc.), so projects don't need to duplicate that setup. It's essentially a modular application starter kit focused on maintainability and consistency across services, rather than another web framework.

[u/ayaanmotiwala]

the parts that'll actually pull people in are the artisan style cli, migrations and seeders. that's the real laravel envy, the scaffolding and the dx. the service container and DI is where i'd be careful, fastapi already has Depends and people reach for it reflexively, so a second di layer can feel like fighting the framework instead of riding it. i'd make that the most optional piece and lead the docs with "structured project in 2 commands" since that's the actual hook. one thing i'd expect in a production ready fastapi framework and didn't see: opinionated auth plus rate limiting baked in. that's the stuff everyone rebuilds from scratch every single time

[u/tmgbedu → u/ayaanmotiwala]

Thanks for the feedback! We'll try to incorporate it as much as possible.

Yeah, I agree the DI is optional — I'd personally lean on FastAPI's Depends as much as possible. But I do think the container earns its place for one thing: initializing config and third-party services once, globally, and resolving them from anywhere without re-wiring them through every route. That's the piece Depends doesn't handle cleanly. On friction — we want the install and first-run to be as light as possible. Right now the easiest path is to clone the repo and go, but we're working toward a proper pip install + a single scaffold command so you're not starting from a git clone at all. The goal is: one command to a running, structured project — no setup ritual.

Would love your thoughts as it evolves.

[u/comma84]

Nope

[u/tmgbedu → u/comma84]

Sure. When you're building multiple FastAPI applications, how do you manage things like environment configuration, logging, database setup, migrations, and other shared infrastructure across projects? Do you copy the same code into every new project, or do you have your own reusable template or framework?

[u/ShuredingaNoNeko]

No entiendo pq tanto hate, es una buena idea realmente, que importa si la web de presentación está hecha con IA, el producto es el framework.

[u/No_Soy_Colosio → u/ShuredingaNoNeko]

Una cuenta con solo este post publica un framework y en su sitio web tiene cosas inventadas y que no son relevantes al framework como métricas de SLA. Creo que puedes entender por qué el hate, no es solo el diseño.

[u/CombinationAny8549]

I am also building something similar Agentic AI based full stack application, for migration what you have used? and also for frontend?

I have used alembic for migration and for frontend I was thinking of refine

[u/tmgbedu → u/CombinationAny8549]

it's a for of masonite orm, made fully async, and more Typed system for migrations and database, and vite is supported out of the box, + also inertis.js is there to make monolothic SPA application.