Especificación · PolariScore

Infraestructura tecnológica

Dos aplicaciones de cliente, dos procesos, una sola base de datos. Ninguna tiene backend propio para los datos: el navegador habla directo con Firebase, y eso explica la mayor parte de sus virtudes y de sus límites.

Arquitectura

Navegador Firebase SDK Chart.js · SheetJS Nginx TLS · enrutamiento por dominio polariscore-estable 127.0.0.1:3121 · oficial planitone.co/polariscore HTML + Bootstrap polariscore (v1) 127.0.0.1:3101 polariscore.planitone.co Vite + Tailwind Firebase · sigunitropico Realtime Database prefijo PolariScore/ Storage · evidencias Auth · Google Sign-In una sola base para las dos el navegador habla directo con Firebase

Componentes

PiezaEstable (oficial)v1
Procesopolariscore-establepolariscore
Puerto interno31213101
Códigoapps/polariscore-estableapps/polariscore
Dominioplanitone.co/polariscore/polariscore.planitone.co
ServidorNode.js con Express: estáticos + rutas limpias. Sin lógica de datos.
FrontendHTML monolítico, Bootstrap, Chart.js y ECharts por CDN.Vite + Tailwind con design system propio, Chart.js empaquetado.
CompilaciónNinguna: se edita el HTML y listo.Requiere build; la salida va a public/dist/.
CorreoNodemailer sobre un relé SMTP, con endpoint propio.
InstalableSí: manifiesto y trabajador de servicio.
DatosFirebase RTDB, Storage y Auth del proyecto sigunitropico.

Lo que implica no tener backend de datos

A favor

  • Los cambios se ven en tiempo real, sin API intermedia que mantener.
  • Las dos versiones comparten datos sin ningún esfuerzo de sincronización.
  • Publicar una corrección en la estable es copiar un archivo.

En contra

  • La seguridad real depende de las reglas de la base, no del código de la página.
  • La lógica de cálculo vive duplicada: cada versión la implementa por su cuenta y pueden divergir —y divergen—.
  • Los totales se persisten desde el navegador de quien abre la ficha.
El caso concreto de esa duplicación es el KPI global del tablero de la v1, que hoy arroja una cifra casi nula porque desplaza los años. Está medido en Las dos versiones. Toda regla de cálculo nueva hay que implementarla dos veces o consolidarla en un solo lugar.

Despliegue y operación

TareaEstablev1
Publicar un cambio de vistaEditar el HTML; se ve al recargar.Editar src/, compilar y reiniciar el proceso.
Cambiar rutasEditar server.js y reiniciar.Editar el mapa de vistas y reiniciar.
Comprobar salud/polariscore/health/health y /api/version
Ver versión desplegada/api/version reporta versión y arranque.

Dependencias externas

La estable carga todas sus librerías por CDN —Firebase, Bootstrap, Chart.js, ECharts, SheetJS—, así que no funciona sin conexión aunque el servidor esté disponible. La v1 empaqueta la mayoría en su compilación y solo va a la red para Firebase y para cargar SheetJS bajo demanda.

Riesgo conocido: en la estable las versiones de librería se fijan archivo por archivo, así que pueden convivir versiones distintas del mismo SDK entre pantallas. Al tocar una vista, revisa qué versión carga antes de usar una API nueva.

Copias de seguridad

Las intervenciones grandes sobre datos dejan respaldo fechado en una carpeta de respaldos del repositorio, con la copia de los archivos y de los subárboles afectados antes del cambio. Es la convención esperada antes de cualquier migración: los cambios de horizonte de una política y las cargas masivas son irreversibles sin ella.

Relacionado: Las dos versiones · Rutas de acceso · Permisos.