Three-layer foundation
API → Service → CRUD/DAO layers with clear boundaries and code generation — productive in 30 minutes
The numbers speak for developers' real choices
Seats available · Be the first sponsor
Three-layer core, plugin ecosystem, AI-first collaboration
Three-layer foundation
API → Service → CRUD/DAO layers with clear boundaries and code generation — productive in 30 minutes
Plugin ecosystem
AI, Auth, Storage, Notification — install and remove cleanly; private registries for enterprises
AI project context
fba skills + LLMs.txt help Claude Code, Cursor, Codex and more understand project conventions
Auth & permissions built-in
JWT, RBAC, data permissions, OAuth 2.0 and other enterprise essentials included
Cache, queue & ops
Redis, Celery, end-to-end logging, and timezone support when you need them
One-click container deploy
Docker Compose ready with production-ready MySQL / PostgreSQL setups
More teams are building the next generation of backends with fba
fba is not about “how to write an endpoint”, but the permission, logging, layering, deployment, and maintainability problems that appear once a team really starts collaborating.
Three-layer architecture + plugins give my focus back to the business. With AI, the pace goes all the way up.
The best part is the clear boundaries: API for protocol, Service for business, CRUD/DAO for data access. New maintainers can find their place quickly.
The plugin marketplace is the right direction: install what you need, remove what you don’t, without sticking to the main project.
With Trace IDs, troubleshooting takes far fewer detours.
I care more about delivery cost. With Docker Compose, monitoring, and logging already in place, promoting from test to production feels much safer.
This is not just writing code — it feels like a dimension-reduction strike. Elegant architecture plus a powerful plugin ecosystem, amplified by AI, is a real productivity boost for backend work.
RBAC, JWT, and caching are already there — new projects no longer need half a day of scaffolding.
The further a project goes, the more you feel the value of unified layering. Code is not placed by personal habit, and reviews spend far less time debating “where should this go?”
Code generation is a real time-saver, especially for repetitive admin modules.
The architecture is not heavy, but the engineering constraints you need are there. For mid/back-office systems and internal platforms, the balance is just right.
The directory structure is obvious at a glance — much less explaining needed.
MySQL and PostgreSQL are both covered, and with plugin-based extension the main project does not have to get messier as business grows.
Deployment, troubleshooting, and handovers are all easier than with a hastily assembled FastAPI project.
Many scaffolds only get you “running”. fba feels more like the common pre-production concerns already wired together. You do not have to use everything, but it is there when you need it.
LLMs docs and skills are friendly to AI tools. When building solo, asking about conventions while coding really helps avoid pitfalls.
Questions you might be asking
What does fba add on top of plain FastAPI?
Why three-layer architecture instead of DDD?
Does it support multi-tenancy?
Can it be used commercially?
Which databases are supported?
How do I enable AI-powered workflows?
If fba saved you time, treat the author to a milk tea and help us go further
Support us