I Got Tired of Rebuilding FastAPI Projects, So I Built FastStrapy

#automation #backend #cli #python

Every new FastAPI project started the same way.

Create folders.

Set up configuration.

Add environment variables.

Configure Alembic.

Copy files from another repository.

Repeat.

It wasn't difficult—it was just repetitive. And after a while, every project looked slightly different because I was copying from different starting points.

So I decided to automate the process.

That's how FastStrapy was born.

The Goal

I wanted a developer experience similar to create-next-app.

Instead of spending the first 20–30 minutes setting up a project, I wanted to run a command, answer a few prompts, and immediately start building the API.

uvx faststrapy create-app

Designing the Architecture

I wanted FastStrapy to be easy to extend as new features and templates are added.

Instead of writing one large generator, I split the project into a few independent pieces.

ProjectConfig

Everything begins with a typed ProjectConfig.

The CLI collects user input once, validates it, and every generator works from that same configuration.

Having a single source of truth makes the generation pipeline predictable and keeps components loosely coupled.

Registry-Based Generators

Rather than maintaining a growing chain of conditionals, generators register themselves.

When FastStrapy runs, it discovers the registered generators and executes them in order.

Adding a new generator doesn't require modifying existing logic, which makes the architecture easier to maintain.

Jinja2 Templates

Instead of constructing files in Python, FastStrapy renders Jinja2 templates.

Templates can include conditional logic, allowing the generated project to adapt based on the selected options while keeping the generation code simple.