Historial de página
Subdirección de las Tecnologías de la Información y Comunicaciones
Área de Gobernanza y Calidad
Versión
| Table Excerpt Include | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| Info | ||
|---|---|---|
| ||
Modificar el name de la versión para que enlace a la versión correspondiente del documento (definida en el TOC) |
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 | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||
|
1. Introducción
Un microfrontend es:
- Un componente visual que está desarrollada, implementada y gestionada de forma independiente.
- Permiten dividir una aplicación web en varias partes más pequeñas, cada una de las cuales puede tener su propio ciclo de vida, stack tecnológico, y equipo de desarrollo.
- Es responsable de una funcionalidad o una sección específica de la interfaz de usuario y se integra con otras partes de la aplicación para formar una experiencia de usuario cohesiva.
- La comunicación será la estándar para los componentes web
1.1. Ámbito de aplicación.
|
|---|
Se recomienda su aplicación:
- Sistemas comerciales que permitan una arquitectura tecnológica flexible y alineada con este modelo de referencia.
- Desarrollos locales con previsión de escalar a sistemas corporativos.
- Cualquier desarrollo para implementar nuevos procesos sobre los sistemas de información existentes.
Se recomienda analizar en detalle con la unidad de Arquitectura de la STIC y particularizarla para los siguientes casos:
- Sistemas analíticos o que gestionen grandes volúmenes de datos (**).
1.2. Ciclo de vida de la arquitectura de referencia
Los cambios normativos dentro de la arquitectura de referencia seguirán el siguiente ciclo de vida:
- Pre-release: Periodo durante el cual la normativa se hace publica aunque no es necesario adherirse inmediatamente. En este periodo aún puede sufrir pequeñas correcciones.
- Adopción : Periodo durante el cual la normativa inicia un periodo de tiempo flexible para su aplicación de forma obligatoria al ámbito en el cual está destinado.
- Activa: Periodo durante el cual es obligatorio su cumplimiento para el ámbito en el cual está destinado.
- Retiro: Periodo durante el cual dejará de aplicarse en el ámbito al cual está destinado en sustitución de nuevas versiones o normas.
| Info |
|---|
(*) Cualquier propuesta que difiera de esta arquitectura deberá ser aprobada por el Área de Gobernanza de la STIC, previa solicitud y justificación en su caso.(**) En proceso de elaboración de una arquitectura de referencia para sistemas analíticos y big data. |
Arquitectura
Tecnología
Enrutamiento (Interno y Dinámico)🎨 Diseño |
|---|
👮 Pauta | 📖 Descripción | 🕵️ Verificación |
|---|---|---|
DIS-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
| Los diseños deben seguir las pautas determinadas por el sistema de diseño | Flujo de validación del diseño | |
DIS-P2 | Se debe entregar el mapa de componentes del microfrontal | Revisión de la tabla |
| 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 |
| DIS-P4 | Se deben entregar los HiFi con los diseños finales a implementar | Revisión del HiFi |
| 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 |
DIS |
ENR-P2
La navegación será siempre interna
Test unitario
-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 |
👨💻 Desarrollo | ||
|---|---|---|
👮 Pauta | 📖 Descripción | 🕵️ Verificación |
DES-P1 |
La comunicación entre el host y un MFE deberá ser la estándar en el desarrollo de componentes, propiedades hacia abajo, eventos hacia arriba. Para más detalle consultar nota aclaratoria
| Deben ser codificados con Typescript | Revisión de dependencias y Revisión de código |
DES-P2 |
Deben estar basados en el estándar de Web Component | Revisión de |
código |
| 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 |
| DES- |
| P4 | Se debe desarrollar haciendo uso de las herramientas provistas por el SAS, para el desarrollo de microfrontends | Revisión de dependencias y Revisión de código | ||||||||
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 |
🧪 Testing | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
👮 Pauta | 📖 Descripción | 🕵️ Verificación | ||||||||
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 | ||||||||
TST-P2 | El runner es Web Test Runner | Revisión de dependencias y Revisión de código | ||||||||
| TST-P3 | El framework para mock es Sinon | Revisión de dependencias y Revisión de código | ||||||||
| TST-P4 | La herramienta de browser headless es Puppeteer | Revisión de dependencias y Revisión de código | ||||||||
ENR-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 | ||||||||
Enrutamiento (Interno y Dinámico)
| title | Nota Aclaratoria |
|---|
selected property that can be initialized to a given value by the owner of the element, but that is updated by the component itself when the user selects an item. In these instances, the component should dispatch an event to indicate to the component's owner that the selected property changed. See Dispatching events for more details.Integración-Directa (Host-Fragment)
👮 Pauta
📖 Descripción
🕵️ Verificación
COM-AIS-P1
La comunicación entre el host y un MFE deberá ser la estándar en el desarrollo de componentes, propiedades hacia abajo, eventos hacia arriba. Para más detalle consultar nota aclaratoria
COM-AIS-P2
Deberá estar documentada la api de integración con el MFE (propiedades y eventos)
ED-excepción
🌐 General | |||||||||
|---|---|---|---|---|---|---|---|---|---|
👮 Pauta | 📖 Descripción | 🕵️ Verificación | |||||||
ENR-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 | |||||||
ENR-P2 | La navegación será siempre interna | Test unitario | |||||||
| ENR-P3 | El microfrontend debe proporcionar una constante con una lista de los paths disponibles | Test unitario | |||||||
| ENR-P4 | El microfrontend debe proporcionar un método métodos para construir los paths con variables | Test unitario | |||||||
| ENR-P5 | El microfrontend debe proporcionar en la documentación los paths disponibles juntos con sus variables | Revisión de documentación | |||||||
| ENR-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 | |||||||
ENR-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 |
Comunicación (Host-
IsolatedFragmentFragment)
👮 Pauta | 📖 Descripción | 🕵️ Verificación |
|---|---|---|
COM |
-P1 | La comunicación entre el host y un MFE deberá ser la estándar en el desarrollo de componentes, propiedades hacia abajo, eventos hacia arriba. Para más detalle consultar nota aclaratoria |
Revisión de código |
COM- |
P2 | Deberá estar documentada la api de integración con el MFE (propiedades y eventos) |
Revisión de documentación |
| COM |
| -P3 | La comunicación entre dos MFE |
| , deberá ser orquestado por el Host |
| Revisión de código |
COM |
-excepción
| En caso de necesitar otro mecanismo de comunicación como buses de eventos compartidos, cookies o IndexedDB 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 |
N/A |
| Info | ||
|---|---|---|
| ||
the component shouldn't change its own public properties, except in response to user input. For example, a menu component might have a public selected property that can be initialized to a given value by the owner of the element, but that is updated by the component itself when the user selects an item. In these instances, the component should dispatch an event to indicate to the component's owner that the selected property changed. See Dispatching events for more details. |
Gestión de Estado Compartido
👮 Pauta | 📖 Descripción | 🕵️ Verificación |
|---|---|---|
CV-P1 | El control de versiones estará regido por las pautas marcadas por Semantic Version. Mayor.Minor.Patch |
|
CV-P2 | Patch: Indica correcciones sobre la funcionalidad de la versión |
|
| CV-P3 | 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. | |
| CV-P4 | 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) | CV-P5 | 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 | CV-P6 | Todas las dependencias del MFE deben ser cargadas desde el CDN del SAS. | CV-P7 | Todas las dependencias deben ser definidas en un script de importmap | CV-P8 | El script de importmap deberá ser inyectado en el index.html del MFE en la fase de construcción, con la combinación necesaria de los importmap.json publicados en el CDN |
| Estado | ||
| colour | Yellow | |
| title | 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 |
Control de Versiones
👮 Pauta
📖 Descripción
🕵️ Verificación
CV-P1
El control de versiones estará regido por las pautas marcadas por Semantic Version. Mayor.Minor.Patch
CV-P2
Patch: Indica correcciones sobre la funcionalidad de la versión
GEC-P1 | No existe estado compartido entre el host y el microfrontend | Revisión de código | ||||||||
GEC-P2 | Cualquier necesidad para compartir información entre el host y el microfrontend deberá ser a través de las pautas de comunicación definidas | Revisión de código | ||||||||
| GEC-P3 | El host no debe compartir información que esté fuera del contexto de negocio del microfrontend | Revisión de documentación | ||||||||
GEC-excepción
| 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 |
Control de Versiones
👮 Pauta | 📖 Descripción | 🕵️ Verificación | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
CV-P1 | El control de versiones estará regido por las pautas marcadas por Semantic Version. Mayor.Minor.Patch | Test de regresión | ||||||||
CV-P2 | Patch: Indica correcciones sobre la funcionalidad de la versión | Revisión de Changelog | ||||||||
| CV-P3 | 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-P4 | 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-P5 | 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-P6 | Todas las dependencias del MFE deben ser cargadas desde el CDN del SAS. | Revisión de código y test de integración | ||||||||
| CV-P7 | Todas las dependencias deben ser definidas en un script de importmap | Revisión de código y test de integración | ||||||||
| CV-P8 | El script de importmap deberá ser inyectado en el index.html del host en la fase de construcción, obtenido de la documentación del microfronted | Revisión de código | ||||||||
CV-excepción
| 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 |
Seguridad
👮 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 | La información de seguridad se deberá transmitir a través de jwt | Revisión del Diseño | ||||||||
| SEG-P3 | El Jwt debe ser firmado en la creación y debe exponer la clave pública para que cualquier elemento pueda validarlo | Revisión del Diseño y Revisión de documentación | ||||||||
| SEG-P4 | El host NO tiene la responsabilidad de proporcionar los roles y permisos del usuario, sólo el OpenID | Test de integración | ||||||||
| SEG-P5 | 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 | Test unitario y Test de integración | ||||||||
SEG-excepción
| 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 |
Tema y Estilos Compartidos
👮 Pauta | 📖 Descripción | 🕵️ Verificación |
|---|---|---|
TEC-P1 | El MFE 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 MFE 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 MFE deberá ser desarrollado haciendo uso de las variables expuestas por el componente del stic-theme | Revisión de código |
TEC-P4 | El MFE NO deberá instanciar el componente de theming | Test unitario |
TEC-P5 | El host es el responsable de instanciar el theming del que se nutrirá el MFE | Test de integración |
TEC |
ED-excepción
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
Seguridad
👮 Pauta
📖 Descripción
🕵️ Verificación
CV-P1
El control de versiones estará regido por las pautas marcadas por Semantic Version. Mayor.Minor.Patch
CV-P2
Patch: Indica correcciones sobre la funcionalidad de la versión
-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 |
Compatibilidad con Múltiples Frameworks
👮 Pauta | 📖 Descripción | 🕵️ Verificación |
|---|
CMF-P1 | El |
host-legacy, siempre que no esté en fase de migración tecnológica, mantendrá la tecnología con la que esté desarrollado en ese momento | Revisión de código |
CMF |
-P2 | El |
host nuevo deberá ser desarrollado |
exclusivamente en Lit | Revisión de código |
CMF |
-P3 |
Los MFE |
TEC-P4
TEC-P5
deberán ser realizados exclusivamente en Lit | Revisión de código | ||||||
CMF-P4 | Todas las dependencias del MFE deben ser cargadas desde el CDN del SAS. | Revisión de código | |||||
CMF-P5 | Todas las dependencias deben ser definidas en un script de importmap | Revisión de código | |||||
CMF-P6 | El script de importmap deberá ser inyectado en el index.html del host en la fase de construcción, obtenido de la documentación del microfronted | Revisión de código y Revisión de la documentación | |||||
CMF-excepción
|
| En caso de necesitar una especialización de los estilos no contemplada en el sistema de diseño y/o en el theme de la STIC, 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 |
Tolerancia a Fallos
| 👮 Pauta | 📖 Descripción | 🕵️ Verificación | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CMFTF-P1 | El host-legacy no tiene restricciones de tecnología |
| ||||||||||||||||
CMF-P2 | El host nuevo deberá ser desarrollado exclusivamente en Lit |
| ||||||||||||||||
| microfrontend notificará al host de cualquier error ocurrido a través de un evento de error | Test unitario | |||||||||||||||||
| TF-P2 | El microfrontend debe tener un fallback definido para cualquier excepción o error ocurrido en el microfrontend, es decir, no debe haber unhandled exception | Test unitario | ||||||||||||||||
| TF-P3 | En caso de error el microfrontend no se puede quedar intestable, es decir, debe seguir dando respuesta a las interacciones. | Test unitario | ||||||||||||||||
| TF-P4 | El evento debe tener información de negocio asociado al error, evitando detalles técnicos e información sensible (Contraseñas, LOPDGDD etc.. ) | Revisión de la documentación | ||||||||||||||||
| TF-P5 | El error debe registrarse en la consola de error, con información técnica que ayude a su detección y resolución. NUNCA se debe enviar información sensible (Contraseñas, LOPDGDD etc.. ) | Revisión de código | ||||||||||||||||
TF | CMF-P3 | Los MFE deberán ser realizados exclusivamente en Lit | CMF-P4 | Todas las dependencias del MFE deben ser cargadas desde el CDN del SAS. | CMF-P5 | Todas las dependencias deben ser definidas en un script de importmap | CMF-P4 | El script de importmap deberá ser inyectado en el index.html del MFE en la fase de construcción, con la combinación necesaria de los importmap.json publicados en el CDN | ED-excepción
| En caso de necesitar una especialización de los estilos no contemplada en el sistema de diseño y/o en el theme de la STIC, 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 |
Tolerancia a Fallos
| 👮 Pauta | 📖 Descripción | 🕵️ VerificaciónN/A |
|---|
Estado del documento
| Concepto a Desarrollar | Estado | POC | |||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tecnología |
|
| |||||||||||||||||||||||||||||
Enrutamiento (Interno, Dinámico) |
|
| |||||||||||||||||||||||||||||
Comunicación (Host- MFE / MFE-MFE) |
|
| |||||||||||||||||||||||||||||
Gestión de Estado Compartido |
|
| Pendiente
| ||||||||||||||||||||||||||||
Control de Versiones |
|
| |||||||||||||||||||||||||||||
Seguridad |
|
| Gestión de Recursos |
|
| ||||||||||||||||||||||||||
Tema y Estilos Compartidos |
|
| |||||||||||||||||||||||||||||
Tolerancia a Fallos |
|
| Monitorización y Registro |
| |||||||||||||||||||||||||||
| Estado |
|
| |||||||||||||||||||||||||||||
Compatibilidad con Múltiples Frameworks |
| Blue
| Progreso
|
|
Vista general
Herramientas de contenido
- Impreso por Atlassian Confluence 8.7.2