Stack tecnológico¶
Todas las plataformas del ecosistema funcionan sobre un mismo stack. No es casualidad: quien pasa de un repositorio a otro no tiene nada nuevo que aprender, y una corrección de seguridad puede desplegarse en todos los sistemas con la misma forma.
En qué se diferencia Gerege Nexus
Gerege Nexus corre sobre el mismo stack (Go · chi ·
pgx · sin ORM · Next.js App Router), pero difiere en tres cosas: es un
monolito modular (los módulos se compilan en un solo binario y se
distribuyen por inquilino mediante una tienda de aplicaciones), migra con
goose y se apoya solo en PostgreSQL, sin Redis. Versiones: Go 1.25 ·
Next.js 15.
Backend¶
| Componente | Elección |
|---|---|
| Lenguaje | Go 1.26 |
| HTTP | net/http de la biblioteca estándar + el router go-chi/chi |
| Base de datos | PostgreSQL — jackc/pgx (pgxpool), SQL escrito a mano |
| Caché / sesiones | Redis |
| Arquitectura | Clean Architecture — handler → usecase → repository → domain |
¿Por qué no hay ORM?
La capa de datos se escribe en SQL a mano sobre pgx. Las razones: usar
directamente las capacidades que viven en lo hondo de PostgreSQL —
Row-Level Security (RLS), CTE, LISTEN/NOTIFY, JSONB — en lugar de hacerlo
a través de la abstracción de un ORM; y no tener que adivinar qué consulta
se generará al final.
La regla dura de Clean Architecture: no hay back-imports. El núcleo de
negocio (domain, usecase) nunca importa un framework web. Eso es lo que
garantiza que la capa HTTP pueda sustituirse sin tocar la lógica de negocio.
Frontend¶
| Componente | Elección |
|---|---|
| Framework | Next.js 15/16, App Router |
| Patrón | BFF (Backend-for-Frontend) |
| Capa de datos | TanStack Query |
Qué significa aquí BFF: el navegador nunca habla directamente con el backend. Solo habla con rutas de Next.js del mismo dominio, y estas hacen de proxy hacia el backend desde el lado del servidor.
El resultado: el token nunca llega al JavaScript del cliente — se usa una sesión por cookie, y el XSS deja de ser un vector de robo de tokens. Encima se añade doble protección CSRF: cabecera propia más comprobación de origin.
Móvil y escritorio¶
| Plataforma | Tecnología |
|---|---|
| iOS | Swift, SDK SPM (GeregeSmartID) + una app por marca |
| Android | SDK en Kotlin / Jetpack Compose |
| macOS | Cliente RP en SwiftUI + kit de token USB |
| Windows | MSIX (firmado) |
| Web RP | SDK de TypeScript |
Pipeline de IA¶
Construido sobre Gemini, como cliente REST sin SDK más function calling:
- chat de texto y chat de voz,
- STT (voz → texto) y TTS (texto → voz),
- traducción en directo,
- base de conocimiento en pgvector, indexada desde el código y la documentación,
- respuestas en el idioma del usuario; widget de chat que no exige iniciar sesión.
System prompt por capas: salvaguardas fijadas en el código, más el alcance y
las instrucciones que el administrador configura desde la base de datos. Así el
asistente se mantiene dentro de los límites previstos. La herramienta
search_knowledge ancla las respuestas en datos reales de la base de
conocimiento y evita las inventadas.
Criptografía¶
El código de firma está portado de un original en Java/Spring, de modo que debe seguir siendo plenamente compatible a nivel de protocolo. Eso queda fijado con frozen golden vectors:
- serialización de punto EC comprimido según SEC1,
- semántica de
BigInteger.toByteArray()de Java (comportamiento del byte de signo).
El servidor Go, el SDK de iOS y el SDK de Android deben producir resultados idénticos byte a byte.
Nunca borre un golden vector
Los ficheros golden.json no se pueden regenerar. Son la única prueba
de compatibilidad con el sistema original. Cualquier cambio en el código
criptográfico debe comprobarse con estas pruebas.
Infraestructura¶
| Componente | Elección |
|---|---|
| Contenedores | Docker Compose |
| CI/CD | GitHub Actions (con runners Windows/macOS autoalojados) |
| Edge | nginx — terminación TLS, rate limit, proxy inverso |
| Certificados | Let's Encrypt (certbot, webroot) |
| Documentación | MkDocs Material + mkdocs-static-i18n, multilingüe |
Consulte Despliegue y CI/CD para el detalle.
Observabilidad¶
- OpenTelemetry — trazado distribuido,
- Prometheus — métricas (
/metrics), - Zap — logs estructurados,
- Registro de auditoría — encadenado por hash, solo de adición; lo leen solo los administradores y su integridad puede verificarse.
Cerrado en producción
/metrics y /swagger están protegidos por bearer token en producción.
Exponen la estructura interna, así que dejarlos abiertos es un riesgo de
divulgación de información.
Pruebas¶
- Pruebas unitarias — en la capa de lógica de negocio,
- pruebas de integración con testcontainers — contra PostgreSQL/Redis reales,
- pruebas de golden vector — para la compatibilidad criptográfica.