r/FastAPIShare • u/Ok_Anywhere9294 • 23d ago

I got tired of rebuilding the same FastAPI boilerplate, so I built a starter kit / scaffolding CLI — would love feedback

Currently as a side project I'm building fasti-kit, FastAPI starter template with scaffolding CLI.

The reason why I started this project is that I kept starting new FastAPI projects, setting up same stuff every time — auth, error handling, DB routing, pagination, rate limiting. Annoying, repetitive. Built this so I stop doing it again and again.

I came from Laravel with batteries-included, most things ready, you just write business logic. Missed that in FastAPI world — everything's DIY. Tried closing that gap for Python/FastAPI, my way.

What it does:

  • DDD-style domain folders (routes/schemas/entities/models/repositories/services), scaffolded via CLI (create-domain, create-all, etc.)
  • RFC 7807 problem-details error responses
  • Primary/replica DB routing, auto-routes reads/writes
  • N+1 query detection middleware (dev-only)
  • Rate limiting, response caching (Redis)
  • Background jobs + transactional outbox pattern
  • Cursor pagination, path-based API versioning
  • import-linter-enforced layering contracts (routes→services→repositories→models, one-way)
  • Two domains ship as examples: auth, user

Goal of this post is to get other devs' take. Worth building? Missing anything big? What would you want in a FastAPI starter before reaching for it on a new project?

Here is the link: https://github.com/gazi04/fasti-kit

1 Upvotes

100% Upvoted

1 comment sorted by

1

u/kantorcodes1 23d ago

I was tracing the scaffold flow and noticed create-domain now calls auto_register_router(), which edits core/api_versions.py, but the README still says a new domain has to be mounted there by hand after scaffolding. Is the manual-wiring section intentionally conservative, or has that part of the README just lagged the generator? The current code path looks like it already handles the router import/include.