React-First Micro Frontends en Industrias Reguladas

Bienvenidos a todos a la sesión sobre micro-frontends React-first en industrias reguladas. Espero que hayan disfrutado de la conferencia hasta ahora, y espero traerles algunas nuevas ideas sobre el desarrollo de aplicaciones web front-end escalables.

Mi nombre es Florian Rappel. Soy un arquitecto de soluciones que trabaja para una empresa más pequeña llamada Smartpjot. Estamos especializados en la creación de soluciones IoT escalables. Yo, personalmente, estoy especializado en la creación de aplicaciones web distribuidas. Además de hacer trabajo de consultoría, implementación, etc., también estoy ocupado haciendo masterclasses y revisiones arquitectónicas. Y me gustaría estar en contacto con ustedes. Así que siempre que tengan la oportunidad, vengan y conectémonos en LinkedIn.

Pero suficiente sobre mí. Vamos a sumergirnos directamente en el tema. Antes de que podamos comenzar, necesito darles un pequeño curso de terminología. Estamos hablando de lo correcto. Cuando digo micro-frontends, lo que quiero decir es que los micro-frontends son la representación técnica de un subdominio de negocio. Estos micro-frontends permiten implementaciones independientes con las mismas o diferentes tecnologías. Deberían minimizar el código compartido con otros subdominios y son propiedad de equipos autónomos. Entonces, ¿qué quiero decir con todas estas palabras? Bueno, en primer lugar, queremos decir que su aplicación web ya no es desarrollada por un solo equipo. Es desarrollada por múltiples equipos, que están trabajando en diferentes fragmentos, diferentes partes del mismo frontend.

Para cortar estas partes, necesitas identificar subdominios. Eso significa no áreas técnicas, sino funcionales de tu aplicación, que, digamos, tienen un terreno común. Así que no dirías que el equipo uno solo se encarga de todos los diálogos en la aplicación y el equipo dos se encarga de todas las páginas o lo que sea. Más bien dirías, bien, entonces todo mi dominio que tengo aquí consiste en diferentes subdominios. El equipo uno, por ejemplo, hace todo con, por ejemplo, detalles de productos, y el equipo dos hace todo sobre precios de algo. Así que siempre, digamos, estarás manejando estas cosas y potencialmente darás algo como un checkout o una cesta al equipo tres. Eso significa que al final del día, estos equipos no estarán, digamos, completamente separados unos de otros. Pero desde el punto de vista del usuario final, siempre se unirán en páginas individuales.

Claro, hay páginas donde solo un equipo contribuyó, pero es muy frecuente que múltiples equipos contribuyan al contenido visto en una sola página. Ahora, podríamos hablar, por supuesto, mucho sobre microfinanzas en general. Pero en esta charla, quiero tomar un subcaso especial y ese es microfinanzas en el contexto de industrias reguladas. Entonces, ¿cuáles son estas industrias reguladas? Son un poco diferentes que, digamos, industrias no reguladas en el sentido de que hay reglas más estrictas a seguir. Como ejemplo, en aplicaciones de salud y farmacéuticas, siempre tienes que obtener la aprobación de la FDA y eso requiere que sigas un conjunto de estándares y también proporciones auditorías, por ejemplo. Por lo tanto, no puedes simplemente, digamos, publicar cuando quieras. Pero para cada, digamos, actualización que no es un arreglo crítico, siempre necesitarás pasar por rondas adicionales para obtener que todos estén de acuerdo con eso y que las autoridades correspondientes lo aprueben. Asimismo, industrias como finanzas y banca o infraestructura crítica, por ejemplo, en energía y medio ambiente, pero también alimentos y agricultura están fuertemente reguladas.

Y dependiendo de qué tipo de aplicación crees, necesitarás enfrentar estas regulaciones y por lo tanto no puedes simplemente desarrollar lo que quieras. Necesitas mantenerte dentro de esos límites. Ahora, ¿cuáles son estos desafíos que nos esperan cuando creamos una aplicación en esas industrias? Entonces, en primer lugar, como ya se mencionó, regulaciones generales, pero también regulaciones de cumplimiento que necesitas seguir. Como ejemplo, para dispositivos médicos, se aplican las reglas de la FDA y los dispositivos médicos ya no están restringidos solo al hardware. El software también es realmente crítico. Así que, por ejemplo, FDA 21, CFR Parte 11 es un ejemplo que podría mencionarse aquí, que necesitas, digamos, adherir en tu aplicación. Asimismo, si tienes una aplicación en el sector automotriz, necesitarás seguir cosas como ISO 26262, que trata sobre la seguridad automotriz. Y en ella hay muchas, por supuesto, restricciones legales y reglas y guías que necesitas seguir y cosas que necesitas proporcionar como documentación antes de salir en vivo. Pero seguridad asegurada, no todos en el equipo necesitan conocer estas reglas.

Es solo importante que alguien lo haga. Y este alguien, por supuesto, es entonces responsable de toda la aplicación, lo cual ya es un poco de conflicto, como ya puedes escuchar, con la naturaleza independiente de estos micro-formatos. Entonces, necesitaremos ver cómo funciona eso en la práctica, pero ya puedes sentir que la independencia se perderá en el camino. Ahora, hemos escuchado el sector automotriz, igualmente en aviación. Tenemos algunas reglas a seguir. También hay algunas reglas generales que incluso las industrias no reguladas podrían entrar en conflicto con tú. Por ejemplo, las reglas de GDPR o HIPAA, siempre podrían entrar en conflicto contigo. También está el nuevo Acta de Resiliencia Cibernética de la UE, que podría ser algo que necesites seguir. Y por lo tanto, te toca y necesitas asegurarte de que todos tus equipos estén de acuerdo con eso y proporcionen fragmentos siguiendo la guía que está escrita en estos documentos. Otro, y ese es el último ejemplo en el sector, si estás creando una aplicación para la infraestructura crítica en Alemania, lo que necesitas tener es que necesitas seguir British V, y este British V también te dice qué tipo de seguridad necesitas implementar en tu aplicación y qué necesita ser proporcionado.

Muy a menudo, las pruebas de penetración son obligatorias para muchas de estas regulaciones que existen. Ahora, muchas de estas otras cosas, se cumplen con el otro desafío que enfrentaremos, que es la documentación y las auditorías. Para proporcionar la documentación necesaria para realmente ver que cumples, necesitas proporcionar documentación.

Entonces, la pregunta, por supuesto, es ¿quién escribe esta documentación? Si tienes múltiples equipos trabajando en ello, y digamos cosas que simplemente fluyen en tu aplicación naturalmente, no sabes qué está pasando allí, quién está proporcionando la documentación, cómo asegurarte de que estas cosas sigan una arquitectura general, y eres responsable de hacer que eso suceda realmente? También está, por supuesto, todo el sector de alineación con estos equipos, especialmente con respecto a la documentación regulatoria y otras necesidades, pero luego también el hecho, ¿qué puedes compartir?

Porque digamos que si ahora tienes múltiples de estos fragmentos independientes para tu front end, ¿cómo puedes asegurarte de que, digamos, una dependencia que quieres compartir esté de hecho en la versión que será compatible al final del día? ¿Y qué pasa si necesitas cambiar esta versión? ¿Qué tipo de efecto tendría en estas diferentes partes independientes? Para una aplicación monolítica, estas preguntas a menudo pueden responderse muy simplemente, ¿verdad? Simplemente lo pruebas y simplemente actualizas y eso es todo. Pero en una solución de micro front end, eso es a menudo no tan fácil porque estas cosas son independientes y así que no puedes simplemente cambiarlo en algún lugar.

¿Y qué están haciendo ahora estas piezas independientes? Realmente necesitarías probar ahora la aplicación agregada en todo detalle. Y eso se vuelve engorroso muy, muy rápidamente. Así que al final del día, lo que tenemos es una especie de lucha. Surge tensión y al final, habrá mucho, digamos, fricción y potencialmente relámpagos entre la libertad que deseamos y por qué optamos por un patrón arquitectónico como micro front ends. Y las regulaciones y la carga que vienen con este tipo de cumplimiento que necesita ser proporcionado aquí.

Entonces, ¿qué podemos hacer aquí? Como ya se mencionó, lo que queríamos hacer es pasar de un enfoque centralizado donde tenemos, digamos, una aplicación monolítica, todo es hecho por un solo equipo. Tal vez algunas de las personas saben todo lo que está pasando allí a un enfoque distribuido donde todas las responsabilidades y todo está completamente distribuido y no una sola persona sabe todo. Ahí es donde queremos ir. Pero nuevamente, la fricción nos matará. Simplemente no es factible llegar allí. Así que necesitamos tomar un enfoque híbrido.

Y una forma potencial que podría tomarse aquí es la siguiente. Tienes un equipo central. Usualmente es el equipo del app shell, pero podría ser mucho más grande que eso. Simplemente llamémoslo un equipo central. Y este equipo, dará algunos límites, límites arquitectónicos. Idealmente, estas cosas, no pueden romperse. Así que si quieres ser parte de la aplicación completa, necesitas seguir estos límites arquitectónicos. No hay una manera. Así que técnicamente, no podrías violarlos, al menos no fácilmente. En la práctica, sin embargo, a menudo hay una manera de sortearlos. Y sí, todavía habrá algunas revisiones, etc. requeridas. Pero no obstante, el objetivo debería ser ir por lo más estricto posible para que ni siquiera sea posible salir de allí.

el objetivo debería ser ir por lo más estricto posible para que ni siquiera sea posible salir de allí. Y la manera más fácil de hacer eso es, por supuesto, tener todo lo que está sucediendo en tu microfront-end sandbox, ¿verdad? Porque entonces puedes definir completamente el entorno y ni siquiera pueden salir.

Pero nuevamente, necesitas ser práctico. También quieres mantener el rendimiento. Así que potencialmente no irás por un sandbox completo.

Pero de nuevo, todo depende. Ahora, lo que está distribuido, por ejemplo, el proceso de desarrollo, equipo individual para un individuo, por supuesto, subdominio, y despliegue. Ahora, el despliegue, podemos discutir mucho, porque nuevamente, al final del día, necesitaremos unirnos. Pero este despliegue no significa que lo que ahora está desplegado también esté en la aplicación completa.

Así que solo porque un equipo desplegó la versión dos no significa que necesitemos tomar la versión dos o este micrófono en absoluto, podemos simplemente quedarnos con la versión uno. Y la otra es la orquestación, lo que significa lo que se provisiona para el usuario final. Podemos tener feature flags y demás. Ahora, esto es genial. Hasta ahora, esto va bien. Pero tal vez hay mucho ahora en el plato para el equipo centralizado, lo que significa que necesitamos quitar un poco de presión aquí.

Podemos hacer eso, por ejemplo, diciendo, oye, la documentación y la prevalidación deberían seguir estando en manos de los equipos individuales. Así que documentan qué cambios hicieron porque conocen su microfront-end mejor. Y también se aseguran de que ya siga todos los límites que se han dado, no solo desde la perspectiva arquitectónica, sino tal vez también desde la perspectiva regulatoria. Así que eso significa que el trabajo del equipo central es realmente comunicar estos límites que deben cumplirse para proporcionar herramientas, por ejemplo, que puedan autoevaluarse.

Al final del día, es realmente importante que obtengamos algo que sea tan bueno, tan completamente validado como sea posible. Porque el paso final es que un equipo central hace pruebas y aprobación. Eso es todo, entonces. Correcto. Así que cumplimos con todas las regulaciones y tenemos nuestra aplicación en funcionamiento, lo que significa que ahora tenemos una aplicación de producción, tenemos una aplicación no de producción. Y ahora aquí viene la diferencia en donde realmente podemos aprovechar que estamos usando microfront-ends. La aplicación no de producción, que va, por supuesto, a un entorno no de producción. Pero eso aquí no solo se indica como una base de datos por nada. La esencia básica aquí es que solo traemos ahora los microfront-ends que han sido designados para uso no de producción, que podría ser la última versión de cada microfront-end, solo porque podemos.

de producción, que podría ser la última versión de cada microfront-end, solo porque podemos. Sin embargo, en producción, realmente tenemos un conjunto cuidadosamente preseleccionado de microfront-ends. Así que aquí realmente nos aseguramos de que solo las versiones que queríamos que estuvieran allí estén allí. Entonces, ¿cómo se ve ahora toda esta cadena? Tenemos nuestros equipos.

Digamos que aquí tenemos tres microfront-ends, tal vez provenientes de tres equipos diferentes, y simplemente publican cuando están listos o cuando tienen una nueva versión, algo, publican en un servicio de descubrimiento de microfront-ends. Ahora, usualmente podrías tener tu aplicación extrayendo los microfront-ends directamente del servicio de descubrimiento. Este es un gran patrón y funciona muy bien, pero no en industrias reguladas, ¿verdad? Porque aquí necesitamos ser cuidadosos. Entonces, lo que podemos hacer es que cada vez que se publica algo, lo colocamos directamente en un entorno no de producción, tal vez no todos, pero un entorno de desarrollo, digamos, y está disponible. Genial.

Sin embargo, para la aplicación de producción o tal vez otros entornos que están más cerca de ella, tenemos un paso de preaprobación. Así que nos aseguramos de seleccionar solo aquellos que realmente parecen cumplirlo. Y luego, al final del día, todo el conjunto, lo que seleccionamos para este entorno de producción junto con nuestra aplicación de producción, eso se regula, se aprueba, y esta composición fija es entonces lo que se envía a los usuarios finales después de que obtenemos todas las auditorías y todo listo. Así que bastante bien. Todavía tenemos un poco de un enfoque monolítico porque no simplemente, digamos, vamos a producción. Ese no es el camino aquí. Pero nuevamente, necesitamos mantenernos dentro de los límites regulatorios.

¿Qué significa eso para el micrófono individual que acaba de ser publicado aquí? Ya lo dibujo no en aislamiento porque tenemos nuestro código, por supuesto, que escribimos usando React. Y hay buenas ventajas de usar React porque no tenemos que preocuparnos tanto por la versión de tiempo de ejecución. En realidad, podemos decir que no importa si comenzamos con 18. Alguien podría actualizar a React 19. Mientras no tengamos una dependencia directa de, por ejemplo, React DOM, eso funciona bastante bien. Y esta es una gran ventaja de React, que mientras no estemos usando algo obsoleto, podríamos simplemente actualizarlo. Y nunca ha habido, hasta donde yo sé, un caso donde algo no funcionó tan bien. Así que eso es realmente bueno. Así que podemos hacerlo y seguir tal enfoque.

Y luego tenemos tres tipos de dependencias. Primer tipo, dependencia que, bueno, es ya sea bastante pequeña, bastante especializada, o se sacude del árbol muy bien. Y, nuevamente, tiene solo un uso limitado y solo puede verse, por ejemplo, en este micrófono. Y un ejemplo, podría ser lodash. No queremos enviar todo lodash a todos, pero tal vez solo las funciones seleccionadas que se han utilizado en la fase de código. Ahora, si hacemos eso, como podemos ver aquí, el micrófono en React simplemente lo agrupa y estamos bien porque ahora pueden verificar que lo que tienen está funcionando y enviarlo. Ahora, hay dos tipos de otras dependencias, las dependencias compartidas. Tenemos una compartida centralmente y React en sí es un buen caso porque, nuevamente, siempre deberíamos usar eso. No deberíamos seleccionar nuestra propia versión, tal vez. Y el app shell, que es el área donde estos generalmente se comparten centralmente, ese debería siempre, digamos, traer más o menos la última versión, al menos alguna versión reciente.

Y luego tenemos otras dependencias que son compartidas distribuidas, lo que significa que no proviene del app shell, sino que proviene de un micro-frontend y que luego solo se carga si no hay una versión compatible disponible aún. Entonces, significa que si tienes dos micro-frontends y ambos vienen con tons stack query, en este caso, y ambos usan, digamos, más o menos una versión reciente, entonces solo lo cargamos una vez. Sin embargo, si realmente quieres para algún caso tener una versión más antigua, digamos la versión 3 de tons stack query y el otro va con 5, entonces, bueno, cargarás tu propia versión en este caso. Así que siempre traerás esos, pero no los validarás. Nuevamente, el contexto de validación aquí en púrpura solo, digamos, consiste en tu código con las dependencias agrupadas. Todo lo demás lo harás centralmente. Así que las dependencias compartidas centralmente y todas las cosas que no son compartidas distribuidas se validarán en el contexto central porque solo entonces sabrás también qué versión está realmente cargada cuando tienes el conjunto seleccionado de micro-frontends. Así que no hagas trabajo que no sea necesario hacer. Por supuesto, si ya sabes que la versión que usas tiene una vulnerabilidad y no pasaría regulaciones o algunas pruebas de cumplimiento, entonces no la selecciones. Tan simple como eso. La última cosa que quiero mencionar aquí antes de que veamos una pequeña demostración es lo siguiente.

Si ahora tienes tres micro-frontends y quieres tomar componentes de un micro-frontend, tal vez otro de otro, podrías pensar en un enfoque como este. Llamas a una función como load component, cualquiera que sea esto, o load fragment, cualquiera que sea tu framework de micro-frontend favorito te dé. Luego tienes algo como red page aquí. Entonces, el nombre del micro-frontend luego tal vez el nombre del componente. Esto es muy estándar, por ejemplo, para module federation. Podrías hacer lo mismo aquí con el micrófono TL, TL dialogue, cargas eso. En mi opinión, eso es problemático en múltiples casos. Así que no hagas eso. Eso no tiene nada que ver con module federation porque incluso allí podrías revertir ese flujo. El problema principal es que si esa versión del micro-frontend rojo donde, no sé, page fue elegido como el identificador no está allí porque usas una versión más antigua o tal vez la interfaz cambió o lo que sea, eso no funcionará. Así que este enfoque fuertemente acoplado donde directamente tomas un componente de un micro-frontend nunca es una buena idea.

En su lugar, opta por un enfoque basado en un registro donde dices, bueno, tu app shell central tiene algún tipo de registro y cuando los micro-frontends llegan, simplemente registran sus fragmentos que son necesarios. Por ejemplo, podría registrar una página definida por su ruta y luego el componente. Del mismo modo, podría registrar algún otro componente aquí llamado register extension como Pyrel, el framework Pyrel lo hace, darle un nombre y luego el componente. Ahora, lo que puedes hacer con eso es que en tu componente, en tu otro micro-frontend donde quieres usar eso, simplemente tienes un tipo especial de componente que quieres usar, podría ser también un componente web. Aquí, uso un componente de React llamado extension slot y esta cosa se comunica con el registro del app shell. Ahora, encuentra todos los componentes registrados para open dialogue y los renderizará en esta ubicación. De esta manera, obtienes el componente allí, pero es suelto, lo que significa que si no registraste nada, nada aparecerá. Así que genial, nada se romperá y también este registro del app shell podría hacer una validación y mantener ciertas interfaces o contratos para ser establecidos.

Así que bastante bien. Finalmente, quiero mostrarte cómo funciona en la práctica en una aplicación estándar, que es como un clon de Netflix aquí. Digamos que tienes tu discovery service, podrías incluso hacer cosas como establecer un feature flag, que es lo mismo que deshabilitarlo, pero solo selectivamente para algunos clientes. Así que aquí, simplemente lo agregamos para Pro y eso significa que en Firefox, de repente el botón surprise me desaparece, pero también el contenido desaparece. Todo desaparece consistentemente porque trabajas con ello consistentemente. Y esa es la idea básica, ¿verdad? Si tienes tu microformance escalado de una manera donde pueden simplemente trabajar sin problemas y de manera suelta juntos, entonces siempre puedes hacer esta composición. Eso es todo de mi parte. Siempre ponte en contacto, revisa nuestro discovery service si quieres echar un vistazo a eso. Siempre podemos, por supuesto, también reservar una sesión de arquitectura gratuita. Ponte en contacto conmigo en LinkedIn si quieres discutir microformance en general, o por supuesto, si realmente estás interesado en el discovery service, esa es la pieza que falta para tu arquitectura, escanea el código QR, échale un vistazo, obtén una demostración de ello. Pero de lo contrario, diviértete codificando y siempre sigue los pasos correctos para mantenerte en cumplimiento.