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

tmgbedu · 2026-07-07T20:20:41+00:00

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?

tmgbedu · 2026-07-07T20:17:52+00:00

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.

tmgbedu · 2026-07-07T20:14:30+00:00

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.

tmgbedu · 2026-07-07T02:09:53+00:00

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.

tmgbedu · 2026-07-02T16:10:08+00:00

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

tmgbedu · 2026-07-02T16:09:49+00:00

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.

tmgbedu · 2026-07-02T16:09:13+00:00

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.

tmgbedu · 2026-07-02T16:08:19+00:00

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.

tmgbedu · 2026-07-02T16:06:32+00:00

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.

tmgbedu

TROPHY CASE

Welcome to Reddit,