Un backend en FastAPI listo para producción con un solo comando

Este comando me arma un backend en FastAPI listo para producción. Pero no lo inventó la IA: le enseñé las reglas con las que trabajo en empresas de Estados Unidos.

Si tu API cabe en un archivo, no lo necesitas. Si va a crecer, sigue leyendo.

Instálalo

Dentro de Claude Code, en cualquier proyecto:

/plugin marketplace add AchsDCerrillo/tezca_fastapi
/plugin install tezca-fastapi@tezca-fastapi-marketplace

¿Usas Codex, OpenCode, Gemini CLI, Antigravity, Copilot o Cursor? Clona el repo y corre el instalador. Te pregunta si lo quieres a nivel de proyecto o de usuario y para qué agentes:

git clone https://github.com/AchsDCerrillo/tezca_fastapi.git ~/tezca_fastapi
~/tezca_fastapi/install-skills.sh

Primero pregunta, luego escribe

Corro /tezca-fastapi:start-fast-api. Antes de escribir una línea me pregunta qué tablas, qué endpoints y a qué registro subo la imagen de Docker. No adivina. Pregunta.

Si el proyecto ya tiene código, me muestra lo que hay y pide permiso antes de cambiarlo.

Cuatro capas, una tarea cada una

router → service → repository → dao → base de datos

• El router solo recibe la petición HTTP y la pasa al service.
• El service tiene la lógica del negocio y lanza excepciones del dominio, como NotFoundError o ConflictError.
• El repository ejecuta las consultas y devuelve modelos de SQLAlchemy.
• El DAO arma la consulta, sin tocar la sesión.

Cada capa hace una sola cosa, y por eso la puedes probar sola. Así se ve una feature:

app/products/
  model/products_model_db.py       SQLAlchemy
  model/products_model_domain.py   Pydantic (peticiones y respuestas)
  products_dao.py                  arma las consultas
  products_repository.py           las ejecuta
  products_service.py              lógica del negocio
  products_router.py               solo HTTP
tests/products/                    dao, service y api

Para agregar una feature completa basta con pedirla:

/tezca-fastapi:add-new-feature
> agrega productos con nombre, precio y estado; CRUD en /products

Migraciones que corren solas

Alembic vive en sql/ y Docker Compose tiene un servicio migrate que aplica las migraciones pendientes antes de que arranque la API. El orden es siempre el mismo: base de datos, migraciones, API.

docker compose up --build
# db → migrate → api en http://localhost:8000/docs

Un solo formato de error

Todos los errores le llegan al cliente igual, con el detalle, un código y el id de la petición para buscarla en los logs:

{ "detail": "Product 42 not found", "code": "not_found", "request_id": "6f1c9e2a" }

Tests en cada feature

Cada feature trae tres tipos de prueba:

1. Consultas del DAO, sin base de datos.
2. El service, con el repository simulado.
3. La API, contra un Postgres real con las migraciones aplicadas y un rollback por prueba.

make check   # ruff + mypy + pytest

CI/CD desde el primer commit

En cada pull request corren lint, tipos y tests. Cuando creas un release en GitHub, corren los tests, se construye la imagen, se sube a tu registro (Docker Hub, GHCR, ECR u otro) y el tag nuevo queda escrito en tu docker-compose.prod.yml.

gh release create v0.1.0 --generate-notes

Por qué lo hice así

La IA escribe rápido. Lo que no sabe es ordenar un proyecto para que aguante dos años. Eso se lo enseñé yo, con las mismas reglas que uso en mi trabajo: capas con límites claros, migraciones que nadie tiene que acordarse de correr, errores predecibles y pruebas desde el día uno.

Instálalo, córrelo en tu siguiente proyecto y cuéntame qué le cambiarías.