← Volver a proyectos

Portal institucional para sindicato del Poder Legislativo de Yucatán

Sitio web oficial de SITUPLEY: Angular 21 con SSR, consumo de APIs REST, organigrama interactivo y sección de noticias dinámica.

📅 2026 – Presente 🏢 SITUPLEY – Sindicato de Trabajadores Unidos del Poder Legislativo del Estado de Yucatán
Angular TypeScript Tailwind CSS SCSS Express.js pnpm

Contexto / Problema

El Sindicato de Trabajadores Unidos del Poder Legislativo del Estado de Yucatán (SITUPLEY) necesitaba una presencia digital oficial que comunicara al público y a sus afiliados tres cosas fundamentales: quiénes son, qué hacen, y cómo está organizada la institución. Sin un sitio web, la información circulaba de manera fragmentada y no existía un canal oficial donde los trabajadores pudieran consultar noticias sindicales, convenios vigentes o la estructura directiva.

El reto adicional era la actualización del contenido. En instituciones de este tipo, es común que el sitio quede desactualizado porque actualizar requiere intervención del desarrollador. La solución debía permitir que el propio sindicato publicara noticias, actualizara datos institucionales y administrara convenios sin tocar una sola línea de código.

La arquitectura resultante fue un frontend desacoplado que consume APIs de un panel administrativo independiente en admin.situpley.org, desarrollado en paralelo. Esto le da al sindicato autonomía total sobre su contenido.

Decisiones técnicas

Angular 21 fue la elección para el frontend por su ecosistema maduro para aplicaciones institucionales y porque la versión 21 introdujo standalone components de forma completa — ya no hay NgModules, lo que simplifica considerablemente la estructura del proyecto. Los Angular Signals, también consolidados en esta versión, ofrecen un modelo de reactividad más intuitivo que RxJS puro para datos de interfaz que no requieren streams complejos.

La decisión más importante del proyecto fue implementar SSR (Server-Side Rendering) con Express.js. Para un sitio público de una institución gubernamental, el SEO no es opcional: cuando alguien busca “SITUPLEY Yucatán” en Google, el sitio tiene que aparecer. Sin SSR, Angular renderiza el HTML en el navegador del usuario — Google puede procesarlo, pero con retrasos y menor fiabilidad para el contenido dinámico cargado desde APIs. Con SSR, el servidor entrega HTML ya renderizado: Google lo indexa igual que una página estática.

Tailwind CSS + SCSS en combinación: Tailwind para el 90% del layout y espaciado, SCSS para los casos donde se necesita mayor control — animaciones, estados de hover complejos, y los estilos del header que cambia de comportamiento al hacer scroll. pnpm como gestor de paquetes redujo el tiempo de instalación y el espacio en disco comparado con npm, lo que se nota en los tiempos de CI/CD.

Implementación destacada

Sistema de caché en memoria y fallback de API

Cada servicio que consume una API implementa un patrón de caché en dos niveles. Primero, un BehaviorSubject guarda el último valor obtenido. Segundo, un flag booleano evita que se hagan dos llamadas simultáneas si el componente se carga dos veces antes de que llegue la respuesta. Si la API falla completamente, el servicio devuelve datos de fallback definidos en el código — una decisión que garantiza que el sitio siempre muestre contenido aunque el backend administrativo esté temporalmente caído.

Este patrón fue especialmente importante durante el desarrollo: trabajar contra una API que a veces no estaba disponible hubiera bloqueado el avance. Con el fallback, el frontend podía desarrollarse y probarse de forma independiente.

SSR y detección de plataforma

El mayor desafío técnico de Angular con SSR es que el mismo código se ejecuta dos veces: una vez en el servidor (Node.js) y una vez en el navegador. Cualquier código que acceda a window, document o localStorage lanza un error en el servidor porque esos objetos no existen en Node.js.

La solución es isPlatformBrowser(), un token de Angular que detecta el entorno de ejecución. El header con auto-hide en scroll, por ejemplo, registra el listener del evento scroll únicamente cuando está en el navegador. Este patrón requiere disciplina — cada vez que se escribe código que depende del navegador, hay que envolverlo — pero es la única forma de tener SSR estable en Angular.

Organigrama del sindicato

La página de organigrama muestra la estructura jerárquica completa del sindicato: comités, niveles y miembros con sus suplentes. La fuente de datos es un archivo JSON estático en /assets/organigrama.json en lugar de una llamada a la API. La razón: la estructura del sindicato cambia raramente (cada ciclo de gestión), y cargarla desde un archivo local hace que la página sea instantánea y funcione incluso offline. Cuando cambia la estructura, se actualiza el archivo JSON y se hace un nuevo deploy — una operación simple.

Resultado / impacto

El sitio está en producción en situpley.org con renderizado del lado del servidor activo. Los buscadores indexan correctamente el contenido dinámico de noticias y la información institucional. El equipo del sindicato puede publicar comunicados y noticias a través del panel administrativo sin depender del desarrollador, lo que resuelve el problema de desactualización que afecta a la mayoría de sitios institucionales similares en la región.

Desafíos no planeados

Durante las pruebas de SSR, el header animado generaba errores de hidratación: el estado del scroll en el servidor era 0, pero al llegar al navegador el estado inicial podía ser diferente si el usuario ya había scrolleado. La solución fue marcar el header como renderMode: 'client' para ese componente específico, evitando que Angular intente hidratar su estado desde el servidor — un escape hatch válido para componentes cuyo estado inicial depende completamente del viewport del usuario.

Aprendizajes

Angular 21 con standalone components y Signals es significativamente más limpio que versiones anteriores basadas en NgModules. La eliminación del boilerplate de módulos reduce el código de configuración inicial en aproximadamente un 40% y hace que la estructura de carpetas sea más intuitiva para desarrolladores que llegan al proyecto por primera vez.

El aprendizaje más valioso del proyecto fue entender que en aplicaciones con SSR y APIs externas, la estrategia de caché y fallback no es un detalle de optimización — es parte del diseño desde el día uno. Un sitio que depende de una API externa sin fallback no es confiable en producción, independientemente de qué tan estable sea el backend.