Frontend Flutter

Los adjuntos muestran que el cliente principal del producto es una app Flutter. Esta página resume cómo debe integrarse con el backend.

Reglas generales

• Usar Authorization: Bearer <jwt> en toda llamada protegida.
• No llamar OAuth con fetch; el login es navegación real.
• Guardar el token con una estrategia segura definida por el equipo.
• Respetar el hash de callback que devuelve el backend.

Callback de OAuth

Cuando el usuario inicia sesión con Google o GitHub, el backend redirige al frontend web con una URL parecida a esta:

/auth/callback#access_token=<jwt>&expires_at=<iso8601>&provider=<Google|GitHub>

La ruta del frontend web debe:

1. leer window.location.hash;
2. extraer access_token y expires_at;
3. guardar la sesión;
4. redirigir a la pantalla principal.

Si hay error, el hash trae error=<codigo>.

Registro y login con contraseña

El backend también soporta:

• POST /api/auth/register
• POST /api/auth/login
• POST /api/auth/forgot-password

Estos sí son requests JSON normales.

hasLocalPassword

El frontend debe usar hasLocalPassword para decidir si muestra acciones de contraseña local:

• false: ocultar o deshabilitar cambios de contraseña local;
• true: habilitar acciones de recuperación o actualización.

Pantallas que consumen la API

Pantalla	Endpoint principal
Dashboard general	/api/metrics/platform
Login	/api/auth/login y /api/auth/login/{provider}
Mis bases	/api/me/databases
Detalle de base	/api/me/databases/{id}/password, pause, resume, delete
DNS	/api/me/dns
N8N	/api/me/n8n y /api/me/n8n/provision
IA	/api/me/ai-keys y /api/ai/generate

Formato de datos útil

Los objetos de base suelen incluir:

• databaseInstanceId
• host
• port
• databaseName
• databaseUser
• engine
• status
• usedSpaceBytes
• maxSpaceBytes
• lastActivity
• createdAt

Manejo de estados

El frontend debe distinguir al menos estos estados:

• Active
• Paused
• Orphaned
• Deleted

Ver la lógica completa en Ciclo de vida de bases.

Recomendación práctica

Si una pantalla depende de varias fuentes, conviene:

• cargar primero el JWT y el perfil;
• después cargar el dashboard;
• y por último los recursos auxiliares como DNS, N8N o IA.

Así se evita bloquear el render principal por una integración secundaria.