Historial de página
Subdirección de las Tecnologías de la Información y Comunicaciones
Área de Gobernanza y Calidad
| Table Excerpt Include | |||||||||
|---|---|---|---|---|---|---|---|---|---|
|
Versión
| Table Excerpt Include | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Tabla de Contenido
| Tabla de contenidos | ||||||
|---|---|---|---|---|---|---|
|
Cumplimiento Normativo
| Advertencia |
|---|
Las normas expuestas son de obligado cumplimiento. La STIC podrá estudiar los casos excepcionales los cuales serán gestionados a través de los responsables del proyecto correspondiente y autorizados por el Área de Gobernanza de la STIC. Asimismo cualquier aspecto no recogido en estas normas deberá regirse en primera instancia por las guías técnicas correspondientes al esquema nacional de seguridad y esquema nacional de interoperabilidad según correspondencia y en su defecto a los marcos normativos y de desarrollo software establecidos por la Junta de Andalucía, debiendo ser puesto de manifiesto ante la STIC. La STIC se reserva el derecho a la modificación de la norma sin previo aviso, tras lo cual, notificará del cambio a los actores implicados para su adopción inmediata según la planificación de cada proyecto. En el caso de que algún actor considere conveniente y/o necesario el incumplimiento de alguna de las normas y/o recomendaciones, deberá aportar previamente la correspondiente justificación fehaciente documentada de la solución alternativa propuesta, así como toda aquella documentación que le sea requerida por la STIC para proceder a su validación técnica. Contacto Arquitectura: l-arquitectura.stic@juntadeandalucia.es |
Histórico de cambios
Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución. Ordenándose de mas recientes a menos recientes, prestando especial cuidado a las cabeceras de la tablas dónde se indican las fechas de entrada en vigor y versión.
| Expandir | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
|
2. Introducción
El objetivo de este documento es documentar pormenorizadamente las responsabilidades, mecanismos y detalles para integrar un host con un MicroFrontend.
2.1 Definiciones
- HOST: Aplicación contenedora, que hospeda y que requiere de la funcionalidad de otro contexto.
- MICROFRONTEND: Encapsulación lógica de negocio, que contiene una funcionalidad concreta en su dominio y que está diseñada para incorporarse en un host.
- FRAGMENT: un componente del microfrontend que representa una parte específica de una aplicación que tiene una funcionalidad concreta y es capaz de operar de forma independiente. Son una forma de dividir una aplicación en partes más pequeñas y manejables que se pueden desarrollar y mantener de forma independiente.
- CAPABILITY: es una funcionalidad específica que un fragmento puede proporcionar a otras partes de la aplicación. Se refiere a una interfaz o un contrato que un fragmento puede ofrecer para ser utilizado por otros fragmentos o microfrontends. Permiten la interoperabilidad entre diferentes partes de la aplicación al definir claramente qué funcionalidades están disponibles y cómo se pueden acceder
Un host es la aplicación contenedora, que tiene la necesidad de incluir una funcionalidad provista desde otro contexto funcional a través de un microfrontend.
| Ancla | ||||
|---|---|---|---|---|
|
🤖 Tecnología
En esta sección se listarán las pautas a seguir para la creación de un microfrontend.
Las pautas se encuentran enmarcadas en los siguientes contextos:
Ancla Tecnología_diseño Tecnología_diseño
| Tecnología_diseño | |
| Tecnología_diseño |
🎨 Diseño
Estas pautas tratan de la fase de diseño del microfrontend
🎨 Diseño | ||||||||
|---|---|---|---|---|---|---|---|---|
👮 Pauta | 📖 Descripción | 🕵️ Verificación | ||||||
TEC-DIS-P1 | Los diseños deben estar alineados las pautas definidas por el sistema de diseño | Flujo de validación del diseño | ||||||
TEC-DIS-P2 | Se debe entregar el mapa de componentes del microfrontal | Revisión de la tabla | ||||||
| TEC-DIS-P3 | Se debe entregar un wireframe con el diseño a alto nivel y las consideraciones a nivel de UX | Revisión del diseño | ||||||
| TEC-DIS-P4 | Se deben entregar los HiFi con los diseños finales a implementar | Revisión del HiFi | ||||||
| TEC-DIS-P5 | Los diseños deben cubrir las necesidades funcionales acordadas en los casos de uso asignados al microfrontend | Revisión de los Casos de Uso | ||||||
TEC-DIS-excepción
| En caso de necesitar realizar un diseño que esté desalineado con estas pautas deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS | N/A | ||||||
Ancla Tecnología_Desarrollo Tecnología_Desarrollo
| Tecnología_Desarrollo | |
| Tecnología_Desarrollo |
👨💻 Desarrollo
Estas pautas tratan los requisitos tecnológicos para el desarrollo del microfrontend👨💻 Desarrollo | ||
|---|---|---|
👮 Pauta | 📖 Descripción | 🕵️ Verificación |
TEC-DES-P1 | Deben ser codificados con Typescript | Revisión de dependencias y Revisión de código |
TEC-DES-P2 | Deben estar basados en el estándar de Web Component | Revisión de código |
| TEC-DES-P3 | Para el desarrollo de los Web Component, se debe usar la librería de envoltura Lit | Revisión de dependencias y Revisión de código |
| TEC-DES-P4 | Se debe desarrollar haciendo uso de las herramientas provistas por el SAS, para el desarrollo de microfrontends | |
3. Instalación
Se deberá consultar la documentación del microfrontend para conocer las posibilidades de instalación que ofrecen.
| Advertencia |
|---|
Los bundelizados con librerías externas aumentan la garantía de que no haya conflictos entre librerías pero hace una gestión ineficiente del uso de dependencias haciendo que el peso del entregable aumente y que el código bundelizado de esa librería se descargue tantas veces como el numero de bundles donde se encuentre. En caso de que el host quiera proporcionar las librerías externas (bundlelización sin librerías externas, importmaps) el host deberá consultar y garantizar la compatibilidad con la versión establecida por el microfrontend |
3.1 Run Time
La instalación se hace al ejecutar el host
- Embebida: la documentación del microfrontend especificará la url de integración por entorno. Este tipo de instalación será siempre con integración Aislada
- Script
- full: con librerías externas
- kernel: sin librerías externas
import mapsEstado colour Green title RECOMENDADA
| Revisión de dependencias y Revisión de código |
TEC-DES- |
3.2 Build Time
La instalación se hace durante la construcción del host
- A través de un gestor de paquetes (npm, yarn, pnpm etc...).
excepción
| En caso de necesitar realizar un desarrollo que esté desalineado con estas pautas deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS | N/A |
Ancla Tecnología_testing Tecnología_testing
| Tecnología_testing | |
| Tecnología_testing |
🧪 Testing
Estas pautas tratan los requisitos tecnológicos para el testeo del microfrontend
🧪 Testing | ||||||||
|---|---|---|---|---|---|---|---|---|
👮 Pauta | 📖 Descripción | 🕵️ Verificación | ||||||
TEC-TST-P1 | El framework para definir los test es @openwc/testing que se basa en chai y mocha. | Revisión de dependencias y Revisión de código | ||||||
TEC-TST-P2 | El runner es Web Test Runner | Revisión de dependencias y Revisión de código | ||||||
| TEC-TST-P3 | El framework para mock es Sinon | Revisión de dependencias y Revisión de código | ||||||
| TEC-TST-P4 | La herramienta de browser headless es PlayWright | Revisión de dependencias y Revisión de código | ||||||
TEC-TST-excepción
| En caso de necesitar realizar un testeo que esté desalineado con estas pautas deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS | N/A | ||||||
Ancla Desarrollo Desarrollo
| Desarrollo | |
| Desarrollo |
👨💻 Desarrollo
En esta sección se listarán las pautas a seguir para el desarrollo de un microfrontend en el ámbito
| Ancla | ||||
|---|---|---|---|---|
|
🌐 General
🌐 General | ||||||||
|---|---|---|---|---|---|---|---|---|
👮 Pauta | 📖 Descripción | 🕵️ Verificación | ||||||
DES-P1 | El microfrontend debe extender de SticMicrofrontendView. Esta clase se puede obtener de @sas/wc-stic-microfrontend | Revisión de dependencias y Revisión de código | ||||||
DES-P2 | NO debe instanciar ningún theming, delegando dicha responsabilidad al contenedor del microfrontend (Host o un contenedor para el stand-alone) | Revisión de dependencias y Revisión de código | ||||||
DES-P3 | NO debe disponer de un layout general, delegando dicha responsabilidad al contenedor del microfrontend (Host o un contenedor para el stand-alone)
| Revisión del diseño y Revisión de código | ||||||
DES-P4 | El microfrontend debe exponer todas las propiedades que considere relevantes para ejecutar los casos de uso de los que es responsable. En caso de estar compuesto por otro componente que tenga propiedades relevantes para la ejecución de los casos de uso deberá hacer prop drilling y ser el responsable de exponer dichas propiedades |
| ||||||
DES-P5 | Debe seguir las pautas de routing |
| ||||||
DES-P6 | Debe seguir las pautas de comunicación |
| ||||||
| DES-P7 | Debe seguir las pautas de configuración |
| ||||||
| DES-P8 | Debe seguir las pautas de seguridad |
| ||||||
DES-excepción
| En caso de necesitar enrutamiento externo (URL) deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS | N/A | ||||||
| Ancla | ||||
|---|---|---|---|---|
|
💻 Stand-Alone
💻 Stand-Alone | ||
|---|---|---|
👮 Pauta | 📖 Descripción | 🕵️ Verificación |
DES-SA-P1 | El contenedor será un componente en CMS independiente y su propio repositorio de código | Revisión de dependencias y Revisión de código |
DES-SA-P2 | Se deberán de desarrollar un componente de tipo aplicación (sas-cli). | |
4. Integración
Se deberá consultar la documentación del microfrontend para conocer las posibilidades de integración que ofrecen. Estas pueden ser de dos tipos:
- Aislada (Isolated): Esta opción tiene la ventaja de que ofrece un contexto tecnológico que evita conflictos tanto de librerías como de estilos. Tiene la desventaja de que, al construir un contexto de ejecución propio e independiente, debe obtener las librerías para su propio contexto, impidiendo la posibilidad de compartir módulos entre microfrontends, o entre el host y el microfrontend.
-
Directa : Siempre que sea posible y se ofrezca la posibilidad esta es la opción más eficiente y la recomendada por parte de las STIC. Permite una gestión más eficiente de los recursos.Estado colour Green title RECOMENDADA
A nivel de uso, el objetivo es que para el host no exista diferencia a la hora de usar una integración aislada de una no aislada. Los contratos y la interacción deben ser exactamente la misma.
Revisión de dependencias y Revisión de código |
DES-SA- |
El host es el responsable de determinar la correcta estrategia de carga del microfrontend:
- Inicial: se carga los módulos requeridos para la ejecución del microfrontend al inicio de la aplicación
- Layload: se cargan los módulos requeridos para la ejecución del microfrontend en el momento de ejecución que el host considere oportuno para mantener una optima experiencia de usuario
El host es el responsable de determinar la correcta estrategia de carga del microfrontend:
- Inicial: se carga los módulos requeridos para la ejecución del microfrontend al inicio de la aplicación
- Layload: se cargan los módulos requeridos para la ejecución del microfrontend en el momento de ejecución que el host considere oportuno para mantener una optima experiencia de usuario
5. Theming
Se deberá consultar la documentación del microfrontend para conocer las posibilidades de theming y personalización de estilos que se ofrecen:
- Aislado: El host y el theming no comparten estilos y cada uno conservará los suyos al integrarse. Si se quieren compartir, el host debe extender o estar desarrollado con el theming de la stic @sas/wc-stic-theme
Directa: El host le comparte su theming (@sas/wc-stic-theme ) y el microfrontend lo carga y se adapta tanto al theming base del host como a las características definidas por el usuario en la configuración de la interfaz del host (densidad, contrastes, accesibilidad etc)Estado colour Green title RECOMENDADA
6. Comunicación
La comunicación con el microfrontend deberá ser siempre la estándar. Se deberá consultar la documentación de la api definida del microfrontend para conocer las posibilidades de comunicación.
6.1 Información
- Host -> Microfrontend: lo host hará uso de las propiedades del microfrontend siempre que quiera realizar un cambio en el estado del mismo.
- Microfrontend → Host: el microfrontend hará uso de los eventos para notificar al host cualquier cambio de estado interno o acción que se haya realizado internamente que el negocio del microfrontend considere interesante compartir con el host
P3 | Es el responsable de instanciar el theming del microfrontend cuando este se ejecute en modo stand-alone |
| ||||||
DES-SA-P4 | Es el responsable de instanciar el layout general del microfrontend cuando este se ejecute en modo stand-alone
| Revisión del diseño y Revisión de código | ||||||
DES-SA-P5 | El contenedor hará uso de la versión kernel del microfrontend (ENT-RT-P4), quedando como responsable de la importación correcta de las dependencias (script o importmaps) |
| ||||||
DES-SA-P6 | Debe exponer un mecanismo de configuración que indique si se ejecuta de forma embebida o stand-alone.
|
| ||||||
DES-SA-P7 | NO es el responsable de exponer propiedades ni emitir eventos |
| ||||||
| DES-SA-P8 | El microfrontend NO tendrá ningún acoplamiento o conocimiento de la existencia de este componente de encapsulación, para él es una integración con un host |
| ||||||
DES-excepción
| En caso de necesitar enrutamiento externo (URL) deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS | N/A |
Ancla Entrega Entrega
| Entrega | |
| Entrega |
🚚 Entrega
| Ancla | ||||
|---|---|---|---|---|
|
🏗️ BuildTime
🏗️ BuildTime | ||||||||
|---|---|---|---|---|---|---|---|---|
👮 Pauta | 📖 Descripción | 🕵️ Verificación | ||||||
ENT-BT-P1 | Se debe entregar, a través del alm del SAS, un paquete npm en el repositorio de artefactos sin incluir el contenedor (Build-time) | Revisión de dependencias y Revisión de código | ||||||
ENT-BT-P2 | No debe estar ni bundelizado ni minificado. |
| ||||||
ENT-BT-P3 | Debe proporcionar la configuración configuración interna (CNF-01,CNF-02) para que el Host que lo integre establezca la configuración |
| ||||||
ENT-BT-excepción
| En caso de necesitar enrutamiento externo (URL) deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS | N/A | ||||||
| Ancla | ||||
|---|---|---|---|---|
|
🏃♀️ RunTime
🏃♀️ RunTime | ||||||||
|---|---|---|---|---|---|---|---|---|
👮 Pauta | 📖 Descripción | 🕵️ Verificación | ||||||
ENT-RT-P1 | Debe existir el paquete npm | Revisión de dependencias y Revisión de código | ||||||
ENT-RT-P2 | Se debe solicitar un despliegue en el CDN (DEV, PRE, PRO) |
| ||||||
ENT-RT-P3 | En estas versiones serán minificadas, bundelizadas y con la configuración interna (CNF-01,CNF-02) |
| ||||||
ENT-RT-P4 | Versión kernel: Esta versión NO incluyen dependencias externas al componente dentro del bundlelizado, esto implica que esta versión no funciona de forma independiente, si no que necesita que quien integra cargue (como script o importmap) todas las dependencia necesarias. |
| ||||||
ENT-RT-P5 | Versión full: Esta versión SI incluyen dependencias externas al componente dentro del bundlelizado, esto implica que esta versión funciona de forma independiente. Dependiendo de donde y como se integre (de forma aislada o directa) pueden surgir conflictos tecnológicos y/o algunos problemas de rendimiento debido a la carga multiplicada de la misma librería por los n componentes que cargue. |
| ||||||
ENT-RT-P6 | A parte de los script, por entorno se debe proporcionar un listado de los importmaps necesarios para ejecutar la versión kernel del component |
| ||||||
ENT-RT-excepción
| En caso de necesitar enrutamiento externo (URL) deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS | N/A | ||||||
| Ancla | ||||
|---|---|---|---|---|
|
💻 Stand-Alone
💻 Stand-Alone | ||||||||
|---|---|---|---|---|---|---|---|---|
👮 Pauta | 📖 Descripción | 🕵️ Verificación | ||||||
ENT-SA-P1 | Debe entregarse el componente de tipo aplicación que permite desplegar en modo stand-alone (DES-P4) | Revisión de dependencias y Revisión de código | ||||||
ENT-SA-P2 | En caso de desplegarse en contenedores:
|
| ||||||
ENT-SA-P3 | En caso de desplegarse en baremental:
|
| ||||||
ENT-SA-excepción
| En caso de necesitar enrutamiento externo (URL) deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS | N/A | ||||||
| Ancla | ||||
|---|---|---|---|---|
|
🔗Integración
| 🌐 General |
|---|
6.2. Routing
Se deberá consultar la documentación del microfrontend para conocer las posibilidades de enrutado que se ofrecen. El enrutado del microfrontend será siempre interno virtual, es decir, que no se hará a través de la url del navegador, permitiendo así navegar de forma independiente y a través de múltiples microfrontends dentro de la misma ruta externa del host. El microfrontend ofrecerá en su documentación:
- El listado de rutas y parámetros en caso de ser necesario
- Una propiedad a través de la cual el host le puede comunicar al microfrontend a que ruta necesita navegar.
6.3. Seguridad
Se deberá consultar la documentación del microfrontend para conocer las posibilidades de seguridad concreta que se ofrecen.
- El host deberá proveer un jwt al microfrontend a través de la propiedad correspondiente.
- El jwt deberá estar firmado
- El jwt deberá tener el scope adecuado del microfrontend asignado LUIS MARTINEZ FONTIVEROS como ves este punto?
- El host deberá exponer y compartir una url con el jks que ofrezca la clave publica de firmado para poder validarlo
- En caso de que el microfrontend requiera una claim con MACO se deberá consultar la normativa al respecto
6.4. Configuración
- Externa: Se deberá consultar la documentación del microfrontend para conocer las posibilidades de configuración externa concreta que se ofrecen. Dicha configuración se compartirá, como indica el estándar de comunicación, a través de la propiedad que esté definida en la api para dicho propósito.
Configuración
CCNF
El host debe ser compatible con tecnología web-componente y lit Se visualiza en el navegador CCNF-02 El host NO es responsable de la configuración interna del microfrontend Test de integración CCNF-03 El host podrá configurar el microfrontend a través de las propiedades definidas en la documentación par tal objetivo Test de integración CCNF-04 El host NO transmitirá información sensible a través de las propiedades del microfrontend sin que estén debidamente codificada o cifrada por un servidor. Test de integración CCNF-05 En caso de que haya algún error en la información de configuración transmitida se notificará el error a través del evento definido para ello Test de integración
| 👮 PAUTA | 📖 Descripción | 🕵️ VERIFICACIÓN |
|---|---|---|
| INT-01 |
6.5. Estado Compartido
Se entiende por estado compartido, cualquier información de estado del host relevante para el microfrontend, o cualquier información de estado del microfrontend relevante para el host.Se debe determinar el tipo de integración:
| Revisión de la documentación | |||||||
| INT-02 | Se debe determinar el modo integración:
| Revisión de la documentación | ||||||
INT-excepción
| En caso de necesitar enrutamiento externo (URL) deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS | N/A |
Ancla Comunicación Comunicación
| Comunicación | |
| Comunicación |
✉️ Comunicación
| 🌐 General | ||
|---|---|---|
| 👮 PAUTA | ||
| 📖 Descripción | 🕵️ VERIFICACIÓN |
|---|
| COM-01 | El |
| microfrontend recibirá información a través de propiedades | Test unitarios |
| COM |
| -02 | El microfrontend |
Cualquier comunicación sobre el estado que el host necesite notificar al microfrontend será , como indica el estándar de comunicación, a través de propiedades expuestas por el propio microfrontend
7. Versionado
El versionado de los microfrontend se llevará a cabo respetando el estándar de Semantic Version.
| enviará información a través de eventos | Test unitarios | |||||||
COM-excepción
| En caso de necesitar enrutamiento externo (URL) deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS | N/A |
Ancla Routing Routing
| Routing | |
| Routing |
🗺️ Routing
| 🌐 General |
|---|
| 👮 PAUTA | 📖 Descripción | 🕵️ VERIFICACIÓN |
|---|
ROU- |
El host tendrá asegurada la retrocompatibilidad de los desarrollos realizados para un microfrontend dentro de una misma mayor.
En una integración en runtime, el host recibirá las actualizaciones dentro de una misma mayor de manera automática
P1 | Se hará uso de la librería @sas/lib-stic-route que se puede descargar del repositorio de artefactos | Revisión de código |
ROU-P2 | La navegación será siempre interna, no se hará a través de la url | Test unitario |
| ROU-P3 | El microfrontend debe proporcionar una constante con una lista de los paths disponibles | Test unitario |
| ROU-P4 | El microfrontend debe proporcionar un método métodos para construir los paths con variables | Test unitario |
| ROU-P5 | El microfrontend debe proporcionar en la documentación los paths disponibles juntos con sus variables | Revisión de documentación |
| ROU-P6 | La cargas de las páginas asociadas a la navegación deben implementarse con importación dinámica de módulos | Revisión de código |
ROU-excepción ALERTA | En caso de necesitar enrutamiento externo (URL) deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS | N/A |
Ancla Seguridad Seguridad
| Seguridad | |
| Seguridad |
🔒 Seguridad
| 🌐 General | ||
|---|---|---|
| 👮 PAUTA | 📖 Descripción | 🕵️ VERIFICACIÓN |
| SEG-P1 | En caso identificarse como un microfrontend seguro, el microfrontend es el encargado de gestionar su propia seguridad, proporcionando los recursos y la documentación adecuada para su garantía | Revisión del Diseño, Revisión de código y Revisión de documentación |
| SEG-P2 | EL microfrontend seguro debe exponer una propiedad que reciba un jwt con el OpenID del usuario | Revisión del Diseño |
| SEG-P3 | El microfrontend tiene que tener la capacidad de a partir del OpenID del usuario proporcionado por el host obtener un token jwt con la información de seguridad relevante para su contexto | Revisión del Diseño y Revisión de documentación |
| SEG-P4 | El microfrontend seguro será el encargado de gestionar el ciclo de vida del token (generación, refresh, revocación) | Test de integración |
| SEG-P5 | El microfrontend seguro deberá estar conectado con un IDP (propio, LoginSAS) que haga la gestión en back del token. | Test unitario y Test de integración |
SEG-excepción ALERTA | En caso de necesitar que alguna dependencia no sea cargada desde el CDN del SAS y quiera ser bundlelizada deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS | N/A |
Ancla Configuración Configuración
| Configuración | |
| Configuración |
⚙️ Configuración
| 🌐 General | ||
|---|---|---|
| 👮 PAUTA | 📖 Descripción | 🕵️ VERIFICACIÓN |
| CNF-01 | El microfrontend es el responsable de proveer al configuración interna para cada uno de los entornos (DEV, PRE, PRO) (ENT-RT-P3, ENT-BT-P3, ENT-SA-P2, ENT-SA-P3) | Se visualiza en el navegador |
| CNF-02 | La configuración se distribuirá de manera estática:
| |
| CNF-03 | El microfrontend debe exponer la configuración externa a través de propiedades. | Test de integración |
CNF-excepción ALERTA | En caso de necesitar que alguna dependencia no sea cargada desde el CDN del SAS y quiera ser bundlelizada deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS | N/A |
Ancla Versionado Versionado
| Versionado | |
| Versionado |
📦 Versionado
El versionado de los microfrontend se llevará a cabo respetando el estándar de Semantic Version.
| 🌐 General |
|---|
8. Conflictos
Se identifican 4 tipos de conflictos que pueden surgir a la hora de llevar a cabo una integración con microfrontend:
- Librerías externas
- Misma librería diferentes versiones incompatibles dentro del mismo contexto de carga de módulos (no aislado)
- Variables Globales
- Que dos librerías (externas o internas) hagan uso de una variable global con el mismo nombre
- Para aplicaciones basadas en la nueva arquitectura de referencia (WC) no está permitido el uso de variables globales al contexto
- Para aplicaciones legacy y que no estén sujetos a la normativa de la nueva arquitectura de referencia, se debe limitar el uso de variables globales a las ya existentes sin poder añadir nuevas variables, e intentando en la medida de lo posible ir eliminando la existencia de las mismas, dando prioridad aquellas que al realizar una integración estén generando conflicto
- Estilos
- Todos los microfrontend estarán desarrollando haciendo uso de la nueva arquitectura de referencia, es decir, estarán desarrollados con Web Component. Esto implica que la propia tecnología ofrece un contexto aislado sobre los estilos evitando así que de forma general el host pueda entrar en conflicto con los estilos del microfrontend.
- El único escenario donde pudiera haber un conflicto de estilos sería si el host hace uso de variables css y estas tienen el mismo nombre que el proporcionado en el componente de la stic (stic-theme) y definidas en el Sistema de diseño . No está permitido el uso de dichas variables css fuera del componente del stic-theme
- Registro de componentes (CustomElements): El registro de un mismo componente (mismo tag html) puede generar un conflicto y por tanto un error en la consola relacionado con el CustomRegistry.
Librerías externas
CLE
01
Revisión del manual del package.json CLE-02 Test unitarios y Test de integración Variables Globales 👮 PAUTA 📖 Descripción 🕵️ VERIFICACIÓN CVG-01 Revisión del manual del package.json CVG-02 Test unitarios y Test de integración Estilos 👮 PAUTA 📖 Descripción 🕵️ VERIFICACIÓN CE-01 Revisión del manual de los ficheros CSS o consola del desarrollador del navegador CE-02 Test unitarios y Test de integración CE-03 Revisión de código Registro de componentes: Build Time 👮 PAUTA 📖 Descripción 🕵️ VERIFICACIÓN CRCBT-01 Revisión del manual del package.json CRCBT-02 Test de integración CRCBT-03 Test de integración
| 👮 PAUTA | 📖 Descripción | 🕵️ VERIFICACIÓN |
|---|---|---|
CV- |
P1 |
El host debe evaluar los posibles conflictos con las librerías externas documentadas en el api del microfrontend
El host debe decidir si puede alinear la versión de la librería conflictiva identificada. En caso de no ser posible debe aislar el uso del microfrontend.
El host no debe crear ni hacer uso de variable globales.
El host debe evaluar si algún conflicto no puede ser resuelto desde el host. En caso de no ser posible debe aislar el uso del microfrontend.
El host debe evaluar los posibles conflictos de variables CSS con el theme de la stic(@sas/wc-stic-theme). microfrontend
El host debe renombrar las variables css conflictivas y añadiéndole el contexto del host. En caso de no ser posible debe aislar el uso del microfrontend.
El host, salvo autorización expresa del departamento de arquitectura a través de un ticket Jira de decisión técnica en el proyecto Host, no podrá redefinir el valor de dichas variables
El host debe garantizar la unicidad de las versiones de los componentes compartidos con el microfrontend utilizado.
El host deberá bundelizar el proyecto al completo para garantizar la unicidad de los componentes.
En caso de recurrir a opciones como el peerdependency y/o el override para determinar las versiones a utilizar, el host asumirá la responsabilidad de un posible funcionamiento inesperado por parte del microfrontend
Cada microfrontend debe versionar de forma independiente y como consecuencia:
| Revisión de código y Revisión de CMS | |
CV-P2 | El control de versiones estará regido por las pautas marcadas por Semantic Version. Mayor.Minor.Patch | Test de regresión |
| CV-P3 | Patch: Indica correcciones sobre la funcionalidad de la versión | Revisión de Changelog |
| CV-P4 | Minor: Indica nuevas funcionalidades que son retrocompatibles, es decir, no existen eliminaciones o actualizaciones en el contrato de integración (api del componente). Los añadidos en el contrato que mantengan la retrocompatibilidad están permitidos. | Revisión de Changelog |
| CV-P5 | Mayor: Indica nuevas funcionalidades que no son retrocompatibles (breaking changes). Existe eliminación o actualización de elementos del contrato de integración (api del componente) | Revisión de Changelog |
| CV-P6 | Cualquier elemento que se desee eliminar deberá ser marcado como deprecado en la versión mayor actual e indicar la alternativa a utilizar que mantiene la funcionalidad y a partir de que mayor está versión será eliminada | Test de regresión |
CV-excepción ALERTA | En caso de necesitar que alguna dependencia no sea cargada desde el CDN del SAS y quiera ser bundleizada deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS | N/A |
Ancla Theming Theming
| Theming | |
| Theming |
🖌️ Tema y Estilos Compartidos
🌐 General | ||||||||
|---|---|---|---|---|---|---|---|---|
👮 Pauta | 📖 Descripción | 🕵️ Verificación | ||||||
TEC-P1 | El microfrontend deberá ser desarrollado estilísticamente en base a las pautas definidas en el sistema de diseño | Revisión del Diseño | ||||||
TEC-P2 | El microfrontend deberá ser desarrollado haciendo uso del catálogo de componentes de la STIC, que estarán acordes a lo definido en el sistema de diseño | Revisión de dependencias y Revisión de código | ||||||
TEC-P3 | El microfrontend deberá ser desarrollado haciendo uso de las variables expuestas por el componente del stic-theme | Revisión de código | ||||||
TEC-P4 | El microfrontend NO deberá instanciar el componente de theming | Test unitario | ||||||
TEC-excepción
| En caso de necesitar un framework de desarrollo diferente al normativizado deberá ser justificada y previamente validada por la oficina de arquitectura creando un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) en el proyecto y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS | N/A | ||||||
Ancla Documentación Documentación
| Documentación | |
| Documentación |
El host debe verificar que los componentes se encuentran en la misma mayor, que aseguran retrocompatibilidad, que los que usa el microfrontend
La bundlelización del host debe obviar las dependencias externas y estas deben ser proporcionadas a través de los importmaps
El host debe mergear los importmaps suyos con los definidos por el microfrontend
📚
Documentación
Deberá dejar cumplimentada la plantilla de integración con cada uno de los microfrontend
Normativas de la arquitectura de referencia tecnológica para el desarrollo frontal de software
| Table Excerpt Include | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Guías de desarrollo frontal
| Table Excerpt Include | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Terminología
| Concepto | Definición |
|---|---|
| Microfrontend | Encapsulación lógica de negocio, que contiene una funcionalidad concreta en su dominio y que está diseñada para incorporarse en un host. |
| Isolated-Microfrontend | Microfrontend que dispone de un contexto de ejecución aislado |
Referencias
Vista general
Herramientas de contenido
- Impreso por Atlassian Confluence 8.7.2