Una plataforma de generación de código: de un schema SQL o un contrato OpenAPI a un servicio backend que compila —no un scaffold, un servicio con forma de producción que seguís manejando después.
Crear un servicio CRUD en Spring Boot es siempre el mismo camino: la entidad, el repository, el service, el controller, los DTOs, el setup de seguridad, el cableado de observabilidad. Es trabajo mecánico, y cuando se repite entre varios equipos, cada servicio termina con convenciones apenas distintas. Esa divergencia es cara de revertir después.
apigen toma un schema SQL o un contrato OpenAPI y genera ese servicio completo: persistencia, seguridad, observabilidad, Dockerfile, manifiestos de Kubernetes, CI. La diferencia con un scaffolder es que el output sigue siendo editable —podés sobrescribir templates sin forkear, y previsualizar antes de generar.
Genera para 12 combinaciones de lenguaje y framework. Nueve de ellas pasan por un job de CI que compila el proyecto generado con el toolchain nativo de cada lenguaje (go build, cargo check, dotnet build, tsc) en lugar de comparar contra strings esperados. Esa distinción importa: un golden test en verde no garantiza que el código compile.
Desarrollador único. Arrancó en diciembre de 2024 como una librería REST genérica de Spring Boot. Diseñé cada módulo, escribí cada línea que no se autogeneraba. Mi background en Java/Spring me dio la opinión para codificar; APiGen es la plataforma alrededor de esa opinión.
APiGen empezó en diciembre de 2024 como una librería REST genérica de Spring Boot — el repositorio linkeado arriba. El código original es un patrón de base-controller / base-service / base-repository con generics, auditoría con Hibernate Envers, conversión con ModelMapper, manejo centralizado de excepciones y paginación, sobre Spring Boot 3 y Java 21.
El objetivo era modesto: codificar mis convenciones preferidas para dejar de reescribir los mismos controllers, el mismo setup de seguridad, los mismos manejadores de excepciones en cada servicio.
A medida que la librería maduró durante 2025, la pregunta cambió. Si las convenciones ya están codificadas, ¿por qué el usuario tiene que escribir las entidades siquiera? ¿Por qué no generarlas desde el schema? Y después: si el engine puede generar Java/Spring, ¿por qué no Kotlin? ¿Python? ¿Go?
Para enero de 2026 el proyecto se convirtió en una plataforma completa de generación de código — la versión que describe el resto de esta página. El link de arriba apunta a la librería genérica original para que el punto de partida sea verificable; la plataforma que creció a partir de ahí no es pública.
La decisión temprana más determinante. Los parsers (SQL, OpenAPI) producen una representación intermedia normalizada. Los templates consumen ese IR. Ninguno de los dos lados sabe que el otro existe.
Esa separación es lo que hizo pensables los 12 lenguajes de destino. Sumar Kotlin no toca el parser de SQL. Sumar GraphQL no toca el pipeline de codegen.
Tradeoff: el IR es rígido por diseño. No hay atajo desde "esta rareza de OpenAPI" directo a "esta anotación de Java". Cada atajo tiene que pasar por el IR, o la abstracción deja de rendir.
APiGen trae 22 módulos: 4 librerías, 4 generadores, 13 feature packs (gateway, GraphQL, gRPC, chaos engineering, recomendación, analytics, BFF, notificaciones, búsqueda, observabilidad, y más), y una capa MCP.
Las features no son flags siempre-encendidas. Son módulos separados a los que un proyecto se suscribe. Un equipo que necesita gRPC incluye el pack de gRPC; uno que no lo necesita no arrastra nada extra en su build. Cada pack se versiona de forma independiente — el pack de chaos puede avanzar sin tocar el de gateway.
Tradeoff: disciplina en los límites de los módulos. Cada feature pack paga un pequeño costo de setup y de mantenimiento de contrato. Dejar que las features se filtraran al core habría hecho la experiencia temprana más rápida — y la limpieza posterior mucho peor.
El mismo engine de codegen corre detrás de una CLI (generación local, preview, validación), un servidor HTTP (endpoints de preview, flujos compartidos por el equipo), un plugin de IDE (autoría dentro del editor) y un servidor MCP (los asistentes de IA manejan la generación como una herramienta).
Elegir esto el día uno obligó a que el engine tuviera forma de librería desde el principio, no una CLI con una API atornillada después. Eso hizo que la integración con MCP saliera casi gratis cuando llegó.
Crecer a lo ancho primero. APiGen escaló hacia afuera rápido — 12 combinaciones de lenguaje/framework, 9 dialectos de base de datos, 13 feature packs — mientras que Java/Spring es el único destino en el que tengo plena confianza operativa. La plataforma parece completa en el papel, pero un usuario que cae en Elixir o Clojure recibe un camino menos maduro que uno que cae en Java.
Si empezara de nuevo, comprimiría la matriz. Dos lenguajes (Java + Python, o Java + Kotlin) y tres bases de datos (Postgres, MySQL, Mongo) a fondo antes de crecer a lo ancho. "Soporta 12 lenguajes" vende mejor que "soporta 2" — pero la reputación de ingeniería importa más que el marketing.
22 módulos Gradle organizados en 4 capas:
El grafo de build se mantiene limpio porque el contrato lo hace cumplir el BOM compartido más la separación entre módulos de API e implementación. Sin ciclos, sin estado mutable compartido entre módulos.
Hablemos sobre tu próximo proyecto o conocé más sobre mi experiencia.