Gin con Go: seguridad, calidad y despliegue
Cierro un recorrido de 12 sesiones para construir APIs con Gin y Go, desde las primeras rutas hasta la seguridad, las pruebas, la observabilidad y el despliegue.
This publication is currently available in Spanish. Read the original ↗
Contexto
Comparto la primera versión completa de mi repositorio práctico de Gin con Go. El recorrido está organizado en 12 sesiones y avanza desde un servidor mínimo hasta una API con autenticación, pruebas, observabilidad y despliegue. Cada sesión incluye una explicación y un ejemplo que se puede ejecutar y modificar desde la terminal.
Lo que cubre el recorrido
- Fundamentos HTTP:
gin.Context, rutas, parámetros, query strings, grupos, respuestas JSON y códigos de estado. - Contratos de API: binding, DTOs, validación, errores consistentes, CRUD, filtros, orden determinista y paginación.
- Diseño mantenible: separación de configuración, handlers, servicios y repositorios, además de middleware, cabeceras de seguridad y CORS.
- Persistencia: PostgreSQL, migraciones, consultas parametrizadas, transacciones y límites claros entre HTTP y la capa de datos.
- Identidad y autorización: contraseñas con bcrypt, JWT con algoritmo permitido explícitamente, expiración, roles y ownership de recursos.
- Calidad: pruebas de tabla,
httptest, pruebas concurrentes, detector de carreras, fuzzing,go vety un workflow de integración continua. - Operación: logs estructurados, request IDs, health/readiness checks, métricas Prometheus, Docker Compose, usuario no root y apagado ordenado.
El aprendizaje que me llevo
Me resultó especialmente interesante comprobar que una API no termina cuando
devuelve un 200: también debe proteger sus límites, explicar sus errores,
ser observable y poder verificarse antes de desplegarse. Las decisiones
pequeñas —por ejemplo, derivar el owner_id del token, ordenar antes de
paginar o limitar las etiquetas de las métricas— evitan problemas difíciles de
detectar más adelante.
Gin y Go me parecen una combinación muy atractiva para servicios HTTP por su claridad, rendimiento y eficiencia operativa. Eso no significa que exista una regla universal según la cual siempre consuman menos RAM que Python o Java: el resultado depende de la carga, las dependencias, la configuración y el entorno. La comparación responsable requiere medir el caso real.
Enlaces
- Repositorio completo en GitHub
- Sesión 9: autenticación y autorización
- Sesión 10: pruebas y calidad
- Sesión 11: observabilidad y despliegue
- Sesión 12: retos y siguientes pasos
Próximo paso
El siguiente paso es medir estos ejemplos con cargas representativas y continuar con refresh tokens, rate limiting, trazas distribuidas y una persistencia más cercana a un entorno de producción.