Observabilidad para Microfrontends

Hola a todos. Mi nombre es Konstantinos y soy un ingeniero de software con sede en Londres. El tema que me gustaría compartir con ustedes hoy es sobre la observabilidad para micro-frontends.

Una agenda rápida para hoy, hablaré sobre los micro-frontends y la observabilidad para entender qué son, si pueden encajar juntos y cómo pueden coexistir. ¿Deberíamos, como ingenieros frontend, preocuparnos por la observabilidad? Y finalmente, una demostración para aplicar la observabilidad a los micro-frontends. Algunos objetivos para hoy. Vamos a definir el camino hacia la observabilidad. Este será nuestro punto de partida y cómo podemos crecer a partir de ahí. Veremos algunos patrones útiles que mi equipo y yo encontramos realmente útiles durante nuestro viaje para identificar problemas en tiempo de ejecución en producción y automatizaremos cómo recibimos notificaciones y alertas para incidentes de producción. Así que empecemos. Micro-frontends. En primer lugar, si te preguntas si existen, puedo decirte que sí existen. No son un unicornio mágico, en realidad no son una herramienta, no son una tecnología, son una forma de escalar software y equipos. Nos ayudan a estructurar mejor nuestros equipos para centrarnos en un dominio comercial y ayudar a un equipo a resolver y ser dueño de un problema específico del negocio. En DAZN, donde trabajo actualmente, aplicamos micro-frontends, pero primero déjame darte una visión general. Este video te dará más contexto. DAZN es una plataforma de transmisión de deportes en vivo y a pedido, que brinda a los fanáticos del deporte el control y la flexibilidad para ver sus deportes a su manera. No necesitas un cable o una antena parabólica para verlo, por lo que la configuración es bastante rápida y sencilla. Puedes descargar la aplicación DAZN y verla en múltiples dispositivos en casa o mientras te desplazas. Estamos implementando software en múltiples plataformas como web, móvil y televisores. En DAZN, invertimos mucho en micro frontends, creando equipos frontend que se centran en un dominio comercial específico. Comencemos con los microservicios. Hace algunos años, nos dimos cuenta de que queríamos comenzar a construir equipos en torno a un problema específico del negocio. Los microservicios se introdujeron como una forma de separar el monolito backend en piezas más pequeñas de lógica y datos. Como puedes ver aquí, tenemos el servicio de descubrimiento, el servicio de autenticación, mi cuenta y el servicio de preferencias. Estos servicios se centran en un dominio específico, en un dominio comercial específico. A veces, tenemos una capa de agregación frente a ellos, como puede ser un backend para frontend o una API de GraphQL. Esto es lo que las aplicaciones frontend utilizan para consumir estos servicios si no los consumen directamente. Y en ese momento, el frontend todavía era un monolito. Y dijimos, ¿por qué no aplicar la misma arquitectura?

La cardinalidad se refiere al número de valores en un conjunto. Por lo general, representa la relación entre los datos en dos tablas diferentes al resaltar cuántas veces ocurre una entidad específica en comparación con otra. Ahora, el término alta cardinalidad significa que puede haber muchos valores posibles para un solo atributo. Un campo de alta cardinalidad puede ayudar a identificar de manera única un problema y permite reducir específicamente qué causó que algo saliera mal. Las herramientas de observabilidad están diseñadas específicamente para consultar datos de alta cardinalidad. Sin datos de alta cardinalidad, careces de observabilidad para detectar, aislar y mitigar los problemas subyacentes que afectan a tu sistema. Pero en este punto, es posible que te preguntes por qué el frontend debería preocuparse por la observabilidad. ¿No es algo de lo que los diferentes equipos deberían ser responsables? Has estado viendo la observabilidad principalmente como un tema relacionado con microservicios y sistemas distribuidos. En DAZN, tenemos una cultura de ingeniería y un lema: construirlo, enviarlo, ser dueño de él para todos nuestros sistemas. Los equipos de frontend son responsables de sus aplicaciones de principio a fin y como parte de esto, también somos responsables de observar nuestros propios sistemas. Tenemos un equipo externo de SRA al que podemos acudir cuando necesitamos ayuda y que puede brindar pautas a diferentes equipos dentro de la empresa.

Estamos utilizando New Relic para registrar problemas de producción en tiempo de ejecución y al mirar el panel de New Relic, vemos este error que no nos dice mucho. React en producción se minimizará y evitará enviar el error completo, pero cuando visitamos el decodificador de errores de la documentación de React, la información que obtenemos es realmente valiosa, pero no nos ayuda a identificar la causa raíz del problema. Incluso los mapas de origen no ayudarán mucho a identificar el problema hasta su raíz, especialmente cuando la separación de los micro frontends puede no ser tan clara como en este caso, necesitamos encontrar formas de observarlos mejor. Esto nos lleva a nuestra demostración para esta charla y la compartiré de inmediato. Entonces, en los micro frontends, tenemos terminología sobre la aplicación principal y los módulos. Aquí, nuestra aplicación principal es Mi Cuenta y es la aplicación principal donde podemos cargar y consumir diferentes módulos. Aquí, por ejemplo, tenemos el encabezado, el pie de página y el perfil, que son módulos específicos que exponemos desde un sistema interno. En la parte derecha de la pantalla, es posible que hayas notado algunos botones. Estos son el error del componente y los errores modales y los diferentes módulos y la aplicación principal tienen estos botones. Si desencadeno este error modal desde la aplicación principal, verás que se muestra el modal con un error y una descripción específica. Podemos cerrar este modal y podemos desencadenarlo nuevamente desde el encabezado o el pie de página. El perfil es un módulo un poco más complicado, está conectado a una API de terceros. Aquí cargamos personajes de la API de RICK y MORTY para que podamos obtener algunos personajes sobre la marcha. Como aquí, puedes obtener diferentes personajes, pero ¿qué sucede cuando falla la API? Entonces, si hago clic en este botón, error al obtener personaje, obtendremos un error de esta API y mostraremos el mismo modal que antes. La forma en que se ha configurado esta aplicación, como puedes ver aquí, tenemos dos repositorios. Uno de ellos es el micro frontend host y el micro frontend module. Tenemos el micro frontend host para la aplicación principal Mi Cuenta y el micro frontend module que expone los diferentes módulos de la aplicación.

Estoy conectado a este archivo remoto enter.js, y también puedo usar una configuración similar de webpack con la versión 5 de webpack utilizando la federación de módulos. Estoy definiendo este nombre de archivo, el enter.js remoto, al que podemos conectar desde nuestra aplicación principal y exponer el índice de origen, que no es más que un archivo que exporta los módulos de encabezado, perfil, pie de página y neuromodal.

Entonces, como puedes ver, si volvemos a nuestra aplicación, es posible que hayas notado que tenemos algunos otros botones que se llaman error del componente. Aquí, si activo este botón, es posible que hayas notado que toda mi aplicación se bloquea. Si vuelvo a cargar mi aplicación e intento hacer lo mismo desde mi encabezado y hago clic en error del componente, la aplicación se bloquea nuevamente. El error del componente que provoca un error dentro del componente del módulo de encabezado afecta a toda la aplicación y hace que toda la aplicación se bloquee. ¿Y cómo podemos resolver eso? Lo que realmente podemos hacer es, además de nuestro componente de encabezado, el componente de encabezado es un simple elemento de encabezado que define un título y algunos botones, y podemos envolverlo con un límite de error y exportarlo como predeterminado. El límite de error es simplemente otro componente, y pasamos el nombre del componente en el que ocurre este error. Entonces, si abro este límite de error, puedes ver que no es más que un simple componente de React que puede derivar algún estado cuando ocurre un error y establece el estado de que hay un error. En base a esto, realmente podemos mostrar una interfaz de usuario alternativa en lugar del propio componente y notificar a nuestros usuarios. Podemos hacer lo mismo para nuestro app.js y podemos envolver el app.js con un límite de error de contenedor como aquí. De manera similar, y puedes ver que el límite de error de contenedor es un componente de React similar que deriva algún estado, define el estado y podemos mostrar una interfaz de usuario alternativa cuando ocurre un error.

Volviendo a nuestra aplicación ahora, si actualizo la aplicación, puedes ver que ahora, cuando activo un error del componente desde el módulo de encabezado, esto ya no afecta a la aplicación principal Mi Cuenta. Mostramos una interfaz de usuario alternativa, nos notifica sobre un error en el módulo de microfrontend del encabezado y podemos restablecerlo, podemos activar nuevamente el error del componente sin que la aplicación se bloquee. Podemos hacer lo mismo en la aplicación principal Mi Cuenta. Pero en este caso, toda la aplicación se bloqueará porque esto afecta a toda la aplicación, a los módulos que renderizamos dentro de esta aplicación principal. Ahora que hemos definido estos límites de error, ¿cómo podemos usarlos? En realidad, cuando capturamos estos errores en este componente, podemos rastrear algunos errores. Estamos utilizando la API de New Relic del objeto window. Cargamos New Relic en nuestro archivo index.html y podemos definir y rastrear algunos errores que ocurren dentro de este componente. Entonces, cuando envolvemos el componente de encabezado con este límite de error modular, cuando ocurre un error dentro de este componente de encabezado, podemos capturar este error dentro de este componente. De esa manera, estamos utilizando la API de New Relic que se llama noticeError para informar el error que es causado por el componente de encabezado y pasar alguna configuración, algunos metadatos, que van a ser el nombre del módulo y la versión del módulo, como puedes ver aquí en la parte inferior que cargamos desde nuestro paquete. Y alguna información adicional como el tipo de error, que es límite de error. Alguna fuente del componente, que es un nombre de prop que pasamos desde el componente que envolvemos con este límite. Y también el ID de usuario, que es el ID de usuario para nuestro usuario en esta sesión. Podemos hacer lo mismo en el límite de error de contenedor. Como puedes ver aquí, en realidad estamos informando el mismo error, no el mismo error, pero el error que ocurre en la aplicación principal. Y podemos definir otro límite y los errores que ocurren dentro de la aplicación principal. ¿Qué más podemos rastrear? Como notamos anteriormente, usamos el perfil para obtener algunos personajes de la API de Rekordmort. Pero ¿qué sucede cuando hay un problema con esta API? Necesitaremos, y es una práctica muy buena, rastrear este tipo de errores.

Y de manera similar, vamos a utilizar la API de New Relic Notice Error para reportar este error y pasar algunos metadatos sobre la configuración del error, el nombre del módulo, la versión del módulo, el ID de usuario para nuestro usuario en esta sesión y su tipo, que ahora es un tipo diferente de error. Es un error de sincronización. Y la fuente del componente, que es el componente de perfil.

De manera similar, podemos hacer lo mismo en el modelo de error, pero su modelo es un poco diferente. Está relacionado con los errores, pero no es un error en sí mismo. Por lo tanto, no queremos rastrear esta acción que mostrará su modelo como un error. Es por eso que podemos usar una API diferente de Relic y agregar una acción de página, definiendo nuestro propio nombre de acción, nuestro nombre de acción específico que podemos definir y pasar algunos metadatos que son similares a los errores de los que hablamos antes, como el nombre del módulo y la versión del módulo, la fuente del componente y el ID de usuario.

Y es posible que te preguntes cómo podemos usar realmente estos datos. Si vamos al panel de New Relic, New Relic ofrece NRQL, que es un lenguaje de consulta específico para New Relic. Esto parece MySQL, y realmente puedes usarlo para consultar algunos datos de New Relic. Aquí podemos seleccionar algunos datos, todos los datos de la tabla de errores de JavaScript, que es la tabla donde están disponibles todos los errores de nuestra aplicación que hemos rastreado anteriormente, y podemos definir el nombre de la aplicación que es Microfrontend Apps y el nombre del módulo, Microfrontend Host, y descubrir los errores que están relacionados con este criterio específico. Podemos ser mucho más específicos e incluso definir el tipo de error, puede ser límite de error y la fuente del componente que es el pie de página. Y de manera similar, también podemos hacer lo mismo con la acción de página como puedes ver aquí con la consulta NRQL y definir el nombre de la aplicación como Microfrontend Apps y el nombre de la acción como error model display para nuestros modelos de error y el nombre del módulo que queremos rastrear es el módulo de Microfrontend. También podemos contar el número de errores y podemos obtener la cantidad de errores que están ocurriendo o la cantidad de acciones que podemos ver aquí, pero ¿cómo podemos automatizar aún más este proceso ya que no queremos ir al panel de New Relic y verificar todo el tiempo estas consultas.

Lo que podemos hacer es confiar en Terraform. En la zona en la que estamos realmente invertidos en Terraform y como puedes ver aquí, Terraform nos ayuda a definir alguna infraestructura con un archivo de configuración YAML y podemos definir un proveedor de New Relic dentro de Terraform y definir una política de alerta de New Relic que está conectada a un canal de alerta específico de New Relic que va a ser el correo electrónico del equipo donde el equipo será notificado cuando se active una alerta y lo más importante, podemos definir algunas condiciones de alerta de New Relic que no es más que las consultas NRQL que hemos visto antes en nuestro panel. De esa manera, podemos seleccionar el número de errores que están ocurriendo desde la tabla de errores de JavaScript y definir que el nombre de la aplicación es Microfronted apps y el nombre del módulo es Microfronted module. De esa manera, cuando tengamos más de dos errores que están ocurriendo durante los próximos 60 segundos, recibiremos una notificación y obtendremos una condición de alerta. Podemos definir otra condición de alerta de manera similar para la acción de página como puedes ver aquí con la consulta NRQL y definir el nombre de la aplicación como Microfronted apps y el nombre de la acción como error model displayed para nuestros modelos de error y el nombre del módulo que queremos rastrear es el módulo de Microfronted y nuevamente, si tenemos más de dos modelos de error durante los próximos 60 segundos, recibiremos una notificación.

Entonces, si volvemos a nuestra aplicación e intentamos desencadenar algunos errores y crear algo de tráfico en New Relic. Después de un tiempo, podremos ver alguna notificación, por lo que recibiremos un correo electrónico de New Relic de que se ha generado un incidente sobre este problema específico y obtendremos algunos enlaces al panel de New Relic para verificar más detalles y también la consulta que ha activado este incidente. También puedes conectar New Relic a tu propio sistema de soporte como por ejemplo PagerDuty, lo cual es realmente útil si tienes equipos de soporte o algo así. Y sí, eso es todo. Algunas conclusiones. Ese es mi nombre de usuario de Twitter, así que no dudes en contactarme si tienes alguna pregunta o si quieres compartir algún comentario y muchas gracias. Echemos un vistazo a los resultados.

Entonces, bueno, tenemos un claro ganador, más de una hora. Ya pensé, sí, encontrar un problema generalmente, sí, sí, quiero decir, lleva más de una hora, era bastante esperado para ser honesto. No esperaría poder encontrar un problema en menos de una hora. Quiero decir, puedo ver que hay algunas respuestas. Quiero decir, cero minutos. Quiero decir, por supuesto, eso ni siquiera es posible. Explicar, no sé si eres como un superhéroe o algo así. Pero sí, sí, sí, definitivamente. Y sí, de lo contrario, creo que en la mayoría de los casos, se necesita más de una hora para depurar este tipo de problemas. Pero sí, definitivamente puede ayudarnos durante eso. Así que definitivamente puede ayudar a minimizar el tiempo que nos lleva darse cuenta y comprender cuál es el problema de producción, el problema en tiempo de ejecución. Y lo más importante, comprender cómo se comportan nuestros clientes y cuál es la experiencia que realmente están obteniendo. Sí, sí, sí, estoy de acuerdo.

Entonces, vamos a abordar las preguntas de la audiencia. La primera es de Mikluho. Y es una pregunta larga. ¿Cómo lidias con errores que forman parte de los paquetes MPM? Por ejemplo, si tienes un error en producción que es capturado por Sentry y afecta solo a los usuarios de Windows, pero no puedo replicarlo. Espero que sea un problema para los propietarios del paquete MPM. Pero mencionaron para más detalles que ellos tampoco pudieron replicarlo. Sí, esa es una pregunta muy buena. Porque generalmente cuando estás usando un paquete MPM, este se importaría en tu sistema de archivos, en tu código base. Entonces, en ese caso, se activará una traza de pila en tu aplicación. Entonces, cuando realmente vayas a debug el registro de errores, descubrirás la traza de pila. Y sí, esto va a ser realmente difícil de descubrir, especialmente si proviene desde la raíz misma de tu sistema. Por ejemplo, si está en el sistema de compilación, Webpack, Rollup o cualquier otra de estas herramientas, será bastante difícil descubrir cuál podría ser el problema. Pero sí, de lo contrario, puedes crear algunas... Si realmente tienes curiosidad o sospechas de la biblioteca específica, lo que puedes hacer es envolver esta biblioteca con un bloque try-catch de alguna manera. Así podrás capturar este error y registrarlo en tu servicio. Como por ejemplo, en Sentry o New Relic o cualquier otra herramienta que estés utilizando. Entonces, sí, en este caso, definitivamente es difícil. Así que debes ir un poco con la comprensión o con tu intuición, digamos, con tu intuición. Pero sí, esto va a ser esto va a ser realmente difícil. Sí. Sí, es un problema difícil de resolver. Encontrar errores es difícil, pero incluso si provienen de paquetes externos, la replicación, por supuesto, es un gran problema. Así que entiendo tu frustración. Sí.

Esto no es una pregunta, sino un comentario de Ante. Sí, y están hablando de ti. Por supuesto, lo hiciste genial con esta sesión. Muy buen trabajo e información útil. Y luego uno, dos, tres, cuatro, cinco, seis, emojis de aplausos, así que puedes llevarte eso a casa. Entonces, la siguiente pregunta es de Iskkk.

De acuerdo. ¿Hay otras herramientas que recomiendes para capturar errores desde el cliente aparte de Sentry o New Relic, como alguna herramienta de código abierto que esté disponible? Sí, he oído hablar de, creo que se llama OpenTelemetry. No lo he utilizado, para ser honesto, pero es algo así como una herramienta que he estado buscando probar en algunos de mis proyectos secundarios o en mi proyecto personal. Sí, porque OpenTelemetry es de código abierto, pero incluso herramientas como New Relic y Sentry, ofrecen algunas versiones freemium. Por ejemplo, puedes usarlas hasta cierto número de usuarios. No conozco los planes específicos, pero puedes usarlas de forma gratuita, especialmente lo que he visto con New Relic es realmente poderoso porque puedes utilizar el lenguaje de consulta que ofrece. Así que todos los errores que estás rastreando en la aplicación puedes consultarlos en los datos multidimensionales y puedes descubrir y limitar los errores que provienen del entorno de producción en tiempo de ejecución y especificar de dónde podrían estar viniendo o, por ejemplo, cuáles son los problemas con usuarios específicos que podrían estar afectados o cualquier otra cosa. Eso es realmente poderoso, sí.

Gracias. Otro cumplido para ti de que fue una sesión realmente genial. Así que podemos hacer un muro completo con cumplidos por cosas constantes. Realmente feliz de que a la gente le haya gustado la charla.

Y luego la siguiente pregunta. No tenemos mucho tiempo. Así que pregunta rápida, una demo genial y aprendí mucho. ¿Puedo implementar el mismo enfoque con otros frameworks de JavaScript como Angular o Vue? Oh sí, definitivamente. Quiero decir, si revisas los errores asíncronos realmente se pueden aplicar en cualquier lenguaje siempre y cuando sea JavaScript puedes capturar estos errores. O por ejemplo, los modelos de error también se pueden activar. Puedes activar estos errores o realmente estas acciones junto con tu interfaz de usuario. La parte más difícil serían los límites de error. Es el lenguaje. Es el framework. Como por ejemplo, Angular, React, Vue.js tienen su propia forma de implementar los límites. Pero lo más importante es que puedes implementar este tipo de límites en todos estos frameworks.

De acuerdo. Bueno, es bueno saberlo. Bueno, como mencioné, eso es todo el tiempo que tenemos para preguntas y respuestas. Pero estarás en tu sala de conferencias. Así que si las personas quieren hacer más preguntas, pueden hacerlo allí, ¿verdad? Sí, sí. Los espero allí. Muchas gracias por tenerme aquí. Ha sido un placer. Y nos vemos la próxima semana en nuestra próxima reunión. Gracias, chicos. Adiós. Adiós.