Opening
Chacc
Stop rebuilding the same API. Plug it in like an app.
A plug-and-play platform on FastAPI: install a module and get a working API, while the platform handles the database, migrations and deployment.
At a glance
The result
3 official modules so far: Authentication, File Manager and Outbound, installed with pip or Docker.
What I did
Refined the Authentication module, and built and refined the Outbound messaging module.
The problem
Every new API project starts by rebuilding the same things.
01 What shipped
In focus: the platform and its modules.
How ChaCC works
.chacc module
Authentication
User sign-in, ready to install
.chacc module
File Manager
Files and uploads, ready to install
.chacc module
Outbound
Outbound messaging to other services
Any module
Your module
Build or download one, then install it
ChaCC backbone
Runtime · Database · Migrations · Dependencies · CLI · Deployment
One working API, each module under its own prefix
Where it’s heading
Where it’s heading
3
official modules so far: Authentication, File Manager and Outbound.
pip + Docker
Install from PyPI, or run it from Docker Hub
Open source
Open for developers to test and contribute
“It’s a really cool product for developers, I can’t wait until it’s fully available publicly...”
What I learned: Building authentication for a modular system as a junior taught me to design for independence first. A module that only works alongside the others isn’t really a module.
02 What I did
Backend engineering on two of the official modules.
Backend work in a team of 4 developers: refining the Authentication module, and building and refining the Outbound messaging module.
Project
Open source · for Python API developers
My role
Backend engineering
Timeline
Over 2 months
Team
Team of 4 developers
Question
Why modules, not a framework?
Each feature is a .chacc package with its own routes and models, so it can be added, removed or shared on its own.
Question
Why run migrations on startup?
The backbone compares models with the database and applies safe changes, with preview, safe auto and full modes.
03 The story behind it
Every new API project starts by rebuilding the same things.
Authentication, database models, migrations and deployment get written again for each project, even when the logic barely changes.
That setup takes time from the features that make each project different, and every copy is one more place for bugs to hide.
Starting a new API, every time
01
Set up the project structure again
02
Rewrite authentication from scratch
03
Recreate the models and migrations
04
Wire up deployment one more time
05
Only then start on the feature that matters
From building APIs as developers
“I really wish I wouldn’t waste time redesigning features that I already did in other projects…”
Bringing it into focus
The real need: features you install once and reuse, without breaking each other.
What we kept seeing
Haven’t I written this exact code before?
The question behind every new project
What it needed
Modules that plug into one backbone, each with its own routes, models and migrations.
Chapter 04 — Bringing it into focus
More detail · Research
What kept repeating across API projects
Before building anything, we listed what kept repeating.
Project A
AuthenticationRebuilt
ModelsRebuilt
MigrationsRebuilt
DeploymentRebuilt
The feature that matters
Project B
AuthenticationRebuilt
ModelsRebuilt
MigrationsRebuilt
DeploymentRebuilt
The feature that matters
Project C
AuthenticationRebuilt
ModelsRebuilt
MigrationsRebuilt
DeploymentRebuilt
The feature that matters
What we found
- The same features were rebuilt in almost every project.
- Setup work delayed the features that mattered.
- Copied code drifted apart and broke in different ways.
- Features needed to work alone, and still fit together.
Technical notes
Stack and trade-offs, for engineers and recruiters · Python · FastAPI · PyPI · Docker
Stack
- PythonLanguage
- FastAPIAPI framework
- PyPIInstall with pip
- Docker HubContainer image
- MkDocs (Material)Documentation
My part
Backend work in a team of 4 developers: refining the Authentication module, and building and refining the Outbound messaging module.
How it works
Modules.
Each feature is a .chacc package mounted on a central backbone.
Models.
Models inherit ChaCCBaseModel, which adds UUIDs, timestamps and soft delete.
Migrations.
They run on startup in preview, safe auto or full mode.
Status
Still in progress: developers are invited to test it and contribute.
An invitation
Need a backend your team won’t rebuild next year?
Booking calls now · Pick a time that suits you