Skip to content
Brand Portal

Arquitectura Frontend

Arquitectura Frontend (SPA)

Section titled “Arquitectura Frontend (SPA)”

La interfaz de usuario del Brand Portal sigue el patrón Single Page Application (SPA) con React.

Al igual que el BFF, el principal principio arquitectónico del Frontend es su Total Asepsia y Desacoplamiento.

Cliente Estático y Desacoplado

Section titled “Cliente Estático y Desacoplado”

A diferencia de las arquitecturas web tradicionales que requieren procesamiento servidor en tiempo real (SSR) para renderizar cada página (e.g. PHP, JSP, Spring MVC), el Frontend de este portal web es estrictamente Client-Side Rendering (CSR).

  1. Compilación: Durante la integración continua (CI/CD), Vite empaqueta el código fuente (JSX / TypeScript) en archivos puros de HTML, CSS y JavaScript minificado (assets estáticos vacíos de persistencia).
  2. Rol del Servidor: El servidor host no necesita motor interno (ni Node.js, ni JDK); su única responsabilidad es servir el index.html estático al navegador web y dejar de intervenir. Toda la lógica de navegación la asume el React Router en el cliente.
  3. Manejo de Datos y Tokens: Toda lógica corporativa, control CSRF, y gestión de tokens OAuth 2.0 de Salesforce la custodia unilateralmente el BFF. Véase el flujo completo en SSO y Token Handler Pattern.

Integración con el Token Handler (CORS & Credentials)

Section titled “Integración con el Token Handler (CORS & Credentials)”

Dado que es el Backend y no el navegador el que guarda los secretos criptográficos, el frontend participa del engranaje con tan solo dos responsabilidades HTTP, pero extremadamente críticas:

  1. Inyección Dinámica de Credenciales: Toda petición fetch() o llamada Axios hacia la pasarela del BFF debe poseer explícitamente el flag credentials: 'include'. Sin este comando, el navegador denegará el empacado automático de la cookie segura (HttpOnly) session_id.
  2. Negociación CORS (Cross-Origin): Dado que el SPA vivirá en app.alcampo.es y el API en api.alcampo.es, las llamadas despacharán bloqueos de seguridad nativos del navegador (Fetch Standard §CORS). El BFF debe contestar cabeceras exactas Access-Control-Allow-Origin: https://app.alcampo.es (los comodines * combinados con credenciales fallan categóricamente según especificación W3C) y responder a métodos OPTIONS (Pre-flight requests). La configuración CORS en Quarkus se gestiona vía quarkus.http.cors.*.

Espectro de Despliegue del SPA (Agnóstico)

Section titled “Espectro de Despliegue del SPA (Agnóstico)”

Dado que el “entregable” es un directorio llano (build/ o dist/) lleno de archivos insensibles, su despliegue infraestructural es altamente elástico. Estas opciones conviven con las Topologías de Despliegue del BFF:

1. Cloud-Native (CDN + Bucket)

Section titled “1. Cloud-Native (CDN + Bucket)”

Representa la estrategia más eficiente y nativa para Nube.

  • Traducción Física: Es un Serverless Hosting. Conecta directamente una ruta en un Cloud Storage Bucket con un balanceador y despachador de alta velocidad Cloud CDN en el Borde.
  • Ventaja: OpEx ridículamente bajo, dado que solo se tarifica por ancho de banda CDN puro, sin consumo de RAM ni de CPU.

2. Standard Web Server (Private Cloud)

Section titled “2. Standard Web Server (Private Cloud)”

Estrategia mandada para despliegues cerrados (CPD interno de Alcampo o Nube Privada pura).

  • Traducción Física: Un bloque location / básico de un servidor ligero estilo Nginx o Apache HTTP Server.
  • Ventaja: Control absoluto perimetral. Factor crítico: Se debe habilitar un “URL Rewrite” — try_files $uri /index.html — para que llamadas físicas inexistentes del usuario (como refrescar en subpáginas ej: /catalogo/botella) apunten siempre a la raíz central index.html, forzando así al React Router a inferir la página exacta mediante History API.