Construir una página de dominios global que realmente muestre todo

El problema

sh0 despliega stacks complejos. Un solo despliegue de WordPress crea tres servicios: el contenedor WordPress, MySQL y phpMyAdmin. ¿Un despliegue Laravel? Misma historia -- Laravel, MySQL, phpMyAdmin. Cada servicio tiene hasta cuatro URL de acceso: interna (contenedor a contenedor), local (mapeo de puerto del host), externa (cuando está habilitada) y dominio (la URL pública).

La página /domains original solo mostraba las entradas de la tabla domains en la base de datos -- los registros de dominios públicos con estado de DNS y SSL. Útil, pero no mostraba el panorama completo. Un usuario que desplegaba Redis no podía ver redis:6379 o localhost:54878 en ningún lugar de esta página. Tenía que navegar a cada aplicación individualmente para encontrar las URL de los servicios.

El feedback del CEO fue directo: "todas estas URL deberían estar en una sola página."

La decisión arquitectónica

Teníamos tres opciones:

1. Frontend N+1 -- Obtener todas las aplicaciones, luego GET /api/v1/apps/:id/services para cada una. Simple pero lento (Docker inspect por contenedor por aplicación).

1. Nuevo endpoint global -- GET /api/v1/services/urls que agrega todas las URL de servicios en una sola llamada. Una solicitud HTTP, pero el backend realiza todos los Docker inspect.

1. Híbrido -- Usar el existente GET /api/v1/services (que devuelve registros básicos de la BD) y luego obtener las URL en tiempo real por lotes.

Elegimos la opción 2. El razonamiento: esta es una herramienta autoalojada que corre en la misma máquina que Docker. Las llamadas por socket Unix al demonio Docker son rápidas. La experiencia de usuario de un solo indicador de carga que se resuelve en menos de un segundo supera una cascada de solicitudes con carga progresiva.

El backend: extraer, extender, exponer

El handler existente list_services para GET /api/v1/apps/:id/services ya tenía 180 líneas de lógica de construcción de URL: Docker inspect para mapeos de puertos en tiempo real, construcción de URL internas, formateo de URL locales (con detección de prefijo HTTP), búsqueda de dominios en la tabla domains y construcción de URL de conexión para servicios de base de datos.

En lugar de duplicar todo esto, extrajimos el código en un helper compartido:

rustasync fn build_service_infos(
    state: &AppState,
    app: &App,
    services: &[AppService],
    domains: &[Domain],
    env_map: &HashMap<String, String>,
) -> Result<Vec<ServiceInfoResponse>> {
    // Docker inspect, construcción de URL, correspondencia de dominios...
}

El handler por aplicación ahora llama a este helper. El nuevo handler global itera sobre todas las aplicaciones con sus servicios, llama al mismo helper para cada una y envuelve cada resultado con app_id y app_name:

rust#[derive(Serialize)]
pub struct GlobalServiceInfoResponse {
    pub app_id: String,
    pub app_name: String,
    #[serde(flatten)]
    pub service: ServiceInfoResponse,
}

El #[serde(flatten)] es clave -- significa que la salida JSON tiene todos los campos en el nivel superior, sin anidamiento. El tipo del frontend se extiende naturalmente:

typescriptexport interface GlobalAppServiceInfo extends AppServiceInfo {
    app_id: string;
    app_name: string;
}

El frontend: una tabla para gobernarlos a todos

La página /domains reescrita es una tabla única con seis columnas: App, Servicio, Interna, Local, Dominio, Estado. El orden importa -- App primero porque "¿a qué aplicación pertenece esto?" es siempre la primera pregunta. Estado al final porque es contexto secundario.

Cada celda de URL tiene copiar al portapapeles y (cuando corresponde) un icono de enlace externo. El filtro de búsqueda funciona sobre nombres de servicios, nombres de aplicaciones, imágenes y todos los tipos de URL. Un desplegable de estado filtra entre en ejecución y detenido.

El resultado: desde una sola página, puedes ver que tu despliegue WordPress tiene wordpress:8000 internamente, localhost:61637 localmente y my-wordpress.sh0.app como dominio público. Su servicio phpMyAdmin está en phpmyadmin:80 / http://localhost:65240 / my-wordpress-phpmyadmin.sh0.app. Y su MySQL está en mysql:3306 / localhost:62876 sin dominio público (como era de esperar).

El debate sobre el orden de columnas

La primera versión ponía Servicio primero, luego App. Después de ver la tabla renderizada con datos reales, el CEO pidió invertirlo. Cuando escaneas una página con más de 15 filas distribuidas en 5 aplicaciones desplegadas, el nombre de la aplicación es el ancla -- agrupa visualmente las filas incluso sin agrupación explícita. El nombre del servicio es el detalle dentro de ese grupo.

Este es un patrón recurrente en el diseño de dashboards: la columna que te ayuda a encontrar lo que buscas debe ir primero, no la columna con más detalle.

Lo que también hicimos en esta sesión

Esta sesión fue densa. Más allá de la página de dominios:

• Corrección de un nombre de template incorrecto -- codeigniter4.yaml no se encontraba porque el frontend buscaba codeigniter. Una sesión anterior renombró el archivo para que coincidiera con el campo name interno pero rompió la cadena de búsqueda. Un renombramiento + un cambio de campo lo resolvieron.

• Traslado de las claves API a su propia pestaña de configuración -- Estaban enterradas en la sección MCP Server. Ahora tienen una entrada dedicada en la barra lateral con su propio icono, haciéndolas descubribles para los usuarios que quieren acceso API sin conocer MCP.

• Adición de anotaciones OpenAPI faltantes -- Tres endpoints (GET /domains, GET /services, GET /services/urls) no tenían anotaciones utoipa, por lo que eran invisibles en la documentación de la API. Anotaciones agregadas + registradas.

• Actualización de la documentación API del sitio de marketing -- La tabla "Otros endpoints" faltaba 7 categorías (Servicios, Backups, Certificados, Proyectos, Redirecciones, Entornos de vista previa, Configuración). Todas agregadas con conteo de endpoints y descripciones.

El ciclo construir-auditar-enviar

Todo esto se hizo en una sola sesión: planificar, implementar, verificar tipos (svelte-check --threshold error devuelve 0 errores), verificar compilación Rust (cargo check pasa), commit, push. La checklist de pruebas tiene 19 elementos de verificación en 6 categorías para que el CEO los revise.

La metodología se mantiene: construir incrementalmente, verificar en cada paso, hacer commits atómicos. No hay PR de 500 líneas que toman un día para revisar -- solo commits enfocados que hacen bien una sola cosa.