Manteniendo la Cordura con Micro-Frontends en Producción de React Aplicando Observabilidad

[♪ Música ♪ y aplausos ♪ Hola a todos. ¿Me escuchan bien? ¿Están emocionados de estar en el React Summit hoy conmigo? ¡Sí! ¡Woo! Así que, hola a todos. Mi nombre es Konstantinos. Vengo de Londres. Soy un ingeniero de software, donde actualmente trabajo para DAZN. Y estamos construyendo un servicio de transmisión en vivo y bajo demanda para eventos deportivos. Planeamos convertirnos en el hogar de todos los deportes, y esto sucederá en un tiempo. Pero por el momento, vamos a ver qué pasa con la observabilidad para microfrontends.

Entonces, ¿cuántos de ustedes ya han utilizado o planean utilizar microfrontends? De acuerdo. ¿Y cuántos de ustedes, ya han estado construyendo en producción utilizando microfrontends? De acuerdo. Eso es mucho mejor de lo esperado. Eso es genial. Los microfrontends se han convertido en un paradigma para los microservicios. Vienen aquí para separar los monolitos frontend y dividirlos en aplicaciones más pequeñas y separadas. Es por eso que terminamos teniendo equipos de extremo a extremo responsables de un dominio comercial específico. Y son capaces de tener una misión específica. Así es como tenemos equipos de frontend, backend y base de datos enfocados en una misión específica de un dominio comercial. Pero los equipos, como pueden ver aquí, están realmente bien definidos hasta que, si nos acercamos, en algunos de estos casos, en realidad no hay una clara separación de responsabilidades. Por ejemplo, podríamos tener un equipo A responsable del encabezado y el pie de página, pero podríamos tener un equipo B responsable de los detalles de la cuenta. Necesitamos encontrar formas de separar este tipo de módulos y mejores formas de observarlos en producción.

No sé ustedes, pero en diseño, estamos utilizando New Relic para el registro de errores en torno al tiempo. Es posible que estén utilizando una herramienta similar. Así que voy al panel de control de New Relic y generalmente veo este tipo de error. Esto es, por supuesto, porque React en producción minimiza la base de código y evita enviar el error completo. ¿Cuántos de ustedes han visto este tipo de error antes en producción? ¿Están registrando errores en torno al tiempo? ¿Cuántos de ustedes están registrando errores en torno al tiempo en producción? De acuerdo. Entonces, lo que estamos haciendo, vamos a visitar la documentación de React y vamos a ver este decodificador de errores. La información que obtenemos de allí es realmente valiosa. Pero no nos ayuda a identificar el problema hasta la raíz. Entonces, lo que vamos a hacer aquí, los mapas de origen no ayudarán porque no son conscientes de los módulos internos. Y lo que necesitamos hacer es dar un paso atrás y revisar los principios de los microfrontends.

Lo que quiero enfocar es en los micro frontends que necesitan aislar la falla y ser sistemas altamente observables. Es más fácil observar un solo sistema, pero es un poco difícil observar un sistema dividido en varios modules.

Entonces, aquí, por ejemplo, tenemos Mi Cuenta, que es la aplicación de contenedor. Y también tenemos Menú, que es un módulo específico. Footer, que es otro módulo. Y perfil, que es otro. Entonces, ¿cómo vamos a resolver este problema? Vamos a necesitar límites claros. Y la forma en que vamos a hacer eso es utilizando límites de React. Esta es una solución desde hace bastante tiempo. Entonces vamos a envolver nuestros componentes de contenedor y los componentes de módulo utilizando los límites. Y de esa manera, en realidad podemos crear un alcance alrededor de estos errores.

Otra cosa, y el primer paso hacia la observabilidad, es poder rastrear el error en producción con eventos estructurados. Lo que esto significa es que al utilizar los límites de error, podemos rastrear en el sistema de New Relic o cualquier otra herramienta que estemos utilizando. Podemos registrar el error y también podemos definir algunos metadatos sobre estos errores. Y esto se trata, por ejemplo, del nombre del módulo, la versión del módulo o cualquier otro contexto que queramos crear. Esto es lo que también haremos para el límite de error del módulo.

Y finalmente, ahora que estamos rastreando todos estos data en New Relic, podemos comenzar a consultar estos data desde las tablas de New Relic. Así es como funcionaría el lenguaje de consulta de New Relic. Y podemos consultar hasta tipos de errores muy, muy específicos y definirlo en la fuente del componente en función del contexto que definimos a partir de los metadatos del rastreo de errores anterior. Y también podemos recibir notificaciones de ellos de la forma más sencilla con un correo electrónico, o integrándonos con un sistema de soporte en línea o de guardia como PagerDuty. Así que realmente puedes hacer esto, en realidad, también con Terraform, puedes automatizar todo y es mucho, mucho más fácil.

Y sí, eso es prácticamente todo por ahora. Una introducción muy breve al viaje hacia la observabilidad para micro frontends. Muchas gracias. Si tienen alguna pregunta, estaré disponible después de esta charla. Estoy en Discord y Twitter con este nombre de usuario. Muchas gracias. Muchas gracias.