Skip to content
Brand Portal

Decisiones Tecnológicas

Decisiones de Plataforma y Stack Tecnológico

Section titled “Decisiones de Plataforma y Stack Tecnológico”

El stack técnico del Backend For Frontend (BFF) combina capacidades de integración empresarial (Enterprise Integration Patterns) con propiedades cloud-native. Esta base resuelve las necesidades de mediación SSO — detalladas en SSO y Token Handler Pattern —, proxy de tokens en tiempo real e integración con Salesforce.

Framework Principal: Quarkus 3.x (Java 21)

Section titled “Framework Principal: Quarkus 3.x (Java 21)”

En lugar de depender de monolitos heredados basados en Spring Boot, el BFF se construirá sobre Quarkus.

¿Por qué Quarkus?

Section titled “¿Por qué Quarkus?”
  • Arranque Casi Instantáneo (Native Mode): La compilación nativa mediante GraalVM permite que la API encienda en menos de 50 ms, erradicando las penalizaciones de “Cold Start”. Cualidad crítica en arquitecturas Serverless o de auto-escalado en Kubernetes.
  • Micro-Huella de Memoria: Las imágenes nativas consumen típicamente <100 MB, reduciendo drásticamente el coste operativo (OpEx) frente a máquinas virtuales Java estándar.
  • Productividad (Developer Joy): Ofrece Live Reload nativo, reduciendo la fricción y acortando los ciclos de desarrollo.
  • Ecosistema Compatible: Quarkus ofrece extensiones optimizadas de todos los estándares líderes (JAX-RS / RESTEasy, Hibernate ORM, Jackson, etc.).
  • Cloud-Native First: Extensiones dedicadas para Google Cloud y soporte nativo de MicroProfile Health e OpenTelemetry.

Transporte e Interfaz: Jakarta REST (JAX-RS)

Section titled “Transporte e Interfaz: Jakarta REST (JAX-RS)”

El punto de entrada web emplea especificaciones estándar Jakarta RESTful Web Services (JAX-RS) (ej. @Path("/bff/auth"), @POST). Quarkus implementa esta especificación a través de RESTEasy Reactive.

  • Stateless Handling: Mantiene la lógica HTTP puramente centrada en aceptar la petición limpiamente, siguiendo los principios REST.
  • Interceptores pre-matching: ContainerRequestFilter intercepta cada petición antes del matching de ruta, desencripta la sesión y materializa el Bearer Token en la cabecera Authorization — todo sin overhead adicional.
  • Clientes declarativos: @RegisterRestClient encapsula la llamada a la Salesforce API con tipado fuerte, sin boilerplate de HttpClient, directamente inyectable vía CDI.

Gestión de Estado (Sesión): Abstracción Unificada

Section titled “Gestión de Estado (Sesión): Abstracción Unificada”

Para conservar un diseño Cloud-Agnostic, pero altamente optimizado en Google Cloud:

  • El Repositorio de Sesiones (Almacén del Token) se define mediante interfaces abstractas puras de Java (Dependency Injection con CDI).
  • Para Google Cloud: Se inyecta la implementación para Cloud Firestore aprovechando las extensiones quarkus-google-cloud-firestore.
  • Para Entornos On-Premise / Internos: Se provee una implementación de reemplazo enfocándose en Bases de Datos Relacionales (PostgreSQL o MySQL) genéricas, gestionadas con Hibernate ORM + Panache. Al no requerirse un throughput crítico en el acceso de las sesiones, incrustar topologías de caché en memoria como Redis sobre-ingeniaría la arquitectura.