Caso de estudio 03 / 17Next.js Front-End
Orquestación de mapas 3D en vivo con gestión de recursos de GPU
Gestor de marcos que mantiene un mapa WebGL activo por fila, verifica cada cuadro por lectura de píxeles y usa terreno local sin conexión.
Stack
- React
- Next.js
- TypeScript
- CesiumJS
- WebGL
- ECharts
- Headless Chrome
01 · Cómo funciona
- HoyaModificado en este trabajo
- Flujo de datos
Qué hace
Cada fila del tablero de la plataforma de monitoreo incrusta un mapa 3D en vivo con su perfil de elevación, que los operadores usan para ubicar alarmas y fugas a lo largo de una línea. Diseñé el gestor de marcos que gobierna esos mapas: cuántos quedan activos, dónde se ubica cada uno, cuándo se aparta o se restaura y cómo se verifica cada cuadro renderizado antes de que lo vea un operador.
Leer más
Primero la exactitud, después la velocidad, y cada modo de falla contabilizado en la página de salud de la plataforma.
6 conexiones· elige un componente para ver su recorrido
- Fila del tablero a Gestor de marcos de mapa: posición de ranura, 2×/s
- Gestor de marcos de mapa a Marco de mapa 3D: lo ubica, muestra o aparta
- Marco de mapa 3D a Canvas de GPU: dibuja un cuadro completo
- Canvas de GPU a Control de marca oculta: lectura de la marca oculta
- Control de marca oculta a Gestor de marcos de mapa: imagen errónea: tapa, rehace
- Gestor de marcos de mapa a Página de salud: cuenta cada caso por hora
02Resultados
- R01Cuanto más bajo, mejor
Mapas del tablero reconstruidos tras 11 min de ausencia
Antes 75%, después 0%, a cero. Cuanto más bajo, mejor.AntesDespués - R02Cuanto más bajo, mejor
Mapas 3D activos por fila del tablero
Antes 2, después 1, 2× menor. Cuanto más bajo, mejor.AntesDespués - R03Cuanto más bajo, mejor
Tiempo de mapa en blanco al cambiar de vista
Antes 6.4 s, después 0 s, a cero. Cuanto más bajo, mejor.AntesDespués
Qué logró
- Integridad del mapa: cuadros cruzados posibles con gráficos integrados → un contexto WebGL activo por fila por diseño, 0 fallas en más de 600 cuadros verificados
- Volver al tablero: 75 % de los mapas reconstruidos → 0 %, los mapas apartados se restauran en su lugar
Leer más
- Cambio de vista: 6.4 s de mapa en blanco → ningún cuadro en blanco
- Caída del servicio de terreno: sin mapa tras 30 s → terreno local en unos 4 s
- Legibilidad en tema oscuro de la escala y la leyenda del perfil: contraste 2.6:1 → 10.9:1
El desafío
Los operadores informaron una fila del tablero que mostraba el mapa de otro sistema. Datos, identidad y ubicación estaban correctos: la falla estaba por debajo de la aplicación. En equipos con gráficos integrados, una fila podía mantener hasta tres contextos WebGL activos compitiendo por memoria de GPU compartida, y sus imágenes se mezclaban en un mismo canvas. Ninguna ruta del código estaba mal, así que ninguna corrección puntual era confiable: la arquitectura debía hacer imposible la falla por diseño y detectarla si alguna vez reaparecía.
Leer más
El mismo diseño debía absorber los modos de falla cotidianos de la plataforma: un mapa en blanco durante 6.4 s en cada cambio de vista, la mayoría de los mapas reconstruidos desde cero tras una ausencia breve y ningún mapa cuando el servicio de terreno en línea dejaba de responder.
Qué aprendí
Hay que medir lo que llega a la pantalla, no lo que informa el código: el gestor de marcos llegó a registrar 98 ms para un cambio que tardó 15.5 s en aparecer. Cuando la memoria de GPU resultó ser la restricción dominante, un contexto activo por fila pasó a ser un invariante, y renuncié a la precarga aunque aceleraba los primeros cambios.
Leer más
Un primer cambio más lento es un precio aceptable por un mapa que siempre es el correcto. Saber qué no construir importó tanto como lo demás: descarté el precalentamiento de teselas porque el tiempo hasta el primer byte ya era bajo.
Stack
- React
- Next.js
- TypeScript
- CesiumJS
- WebGL
- ECharts
- Headless Chrome
Habilidades
- Renderizado 3D en la web
- Gestión de recursos de GPU
- Ingeniería de confiabilidad
- Análisis de causa raíz
- Visualización de datos accesible

