Front-End Observability Explained

Así que, hola a todos. Mi nombre es Yash Varma. Soy ingeniero de software e investigador en informática. Normalmente hablo sobre todo lo relacionado con la observabilidad, desde el rendimiento del backend hasta las bases de datos, y esta vez, frontend. Me llamo a mí mismo un entusiasta de la telemetría abierta, porque si no estás familiarizado con lo que es la telemetría abierta, en resumen, es un proyecto bajo CNCF que tiene como objetivo crear un marco de observabilidad neutral para proveedores para logs, métricas, trazas y muchas señales que añadiremos en el futuro. Si estás interesado, ve y échale un vistazo. Más sobre esto más adelante en la charla. Cuando no estoy involucrado en tecnología, generalmente disfruto cocinando y haciendo senderismo. Este es mi lindo perro. Su nombre es Ty, y sí, soy amante de los perros. Así que, entremos en la charla.

Entonces, la charla de hoy se titula Observability Matters, esta vez para frontend. ¿Emocionados? Así que, esta será nuestra agenda para hoy. Será bastante sencillo. Primero, comenzaremos con la evolución de ZEP en las últimas décadas. Luego pasaremos a entender el qué y el porqué de la observabilidad. Luego veremos el estado actual de las herramientas de monitoreo de front-end y sus desafíos. Luego la esencia central. ¿Qué es exactamente la observabilidad de front-end y por qué es importante para nosotros? Por último, veremos la dirección de la observabilidad de front-end. Así que vamos a sumergirnos. Sumergirnos.

Entonces, es hora de historias, ¿verdad? Comencemos con una buena historia de cómo me adentré en el front-end, y cómo está relacionado con mis observabilidades de front-end. Así que, comencemos.

Veo esta historia, y su título es Beyond Assumptions, A Shift in My Perspective. Así que, era 2019. Estaba en mi universidad. Estaba explorando el vasto mundo de la tecnología por primera vez. Y como muchos de los estudiantes, dependía de publicaciones en blogs y comunidades tecnológicas que me rodeaban para saber cómo debería comenzar mi viaje tecnológico. Sin embargo, el consejo era casi el mismo en todas partes. Comienza con HTML, CSS, JavaScript, y luego aprende lo básico de React porque, ya sabes, el front-end es fácil, decían, y el back-end es donde estaba el prestigio.

Así que, ya sabes, aprendí eso. Y acepté eso en mi viaje inicial. Pronto, obtuve una oportunidad de trabajo que iba a desafiar todas mis suposiciones previas. ¿Y la mejor parte? Estaba completamente inconsciente de eso. ¿Qué había para mí en el futuro?

Así que, esta fue una pasantía en una de las startups de entrega de alimentos más grandes del país. Mi rol estaba en el equipo de front-end, y era responsable de gestionar y construir interfaces que millones de usuarios usarían a diario. Pero en mi tiempo libre, siempre intentaba involucrarme con los desarrolladores de back-end. Porque necesitaba aprender de ellos cómo trabajaban. Pensaba que el back-end era el mundo definitivo para mí en el viaje de desarrollo, así que, ¿por qué no ser parte de ello de alguna otra manera? Porque hablaban de escalabilidad, sistemas distribuidos y rendimiento. Lo ves. Cosas que estaban muy fuera de mi alcance en ese momento. Además, esta fue la primera vez que vi cómo estas personas eran capaces de gestionar y vigilar eficientemente todo su sistema.

Así que pronto, la realidad me golpeó fuerte. Justo después de unos meses en mi pasantía, me di cuenta de que el desarrollo de front-end no era tan fácil como esperaba que fuera. Cada pequeño cambio en la interfaz de usuario, cada ajuste en una función de JavaScript podría desencadenar una cascada de comentarios de los usuarios. Un simple diseño o ajuste puede llevar a una avalancha de tickets de soporte enojados. A veces, incluso los usuarios recurrían a las redes sociales para expresar su frustración cuando las cosas no funcionaban bien para ellos. Y todo eso estaba sucediendo en tiempo real, con cientos y miles de clientes haciendo pedidos, ya sabes, como todos los días. Con el tiempo, quedó claro que el front-end es el primer punto de contacto entre el producto y sus usuarios. Es donde las empresas se encuentran con sus usuarios, y es donde se forma la percepción de velocidad, fiabilidad, calidad, y lo más importante, es donde se genera el ingreso. Así que nosotros, como desarrolladores de front-end, tenemos un desafío único porque a diferencia del back-end, a diferencia de los desarrolladores de front-end, nuestros errores son visibles para todos de inmediato.

Y la parte divertida, a veces a menudo tenemos que lidiar con los errores que son cometidos sin saberlo por los usuarios. ¿Alguna idea? Son nuestros, ya sabes, como amigos desconocidos, la extensión del navegador, si sabes, sabes.

Así que retrocedamos un momento y consideremos cómo la web ha evolucionado con el tiempo. En los primeros días, la web era bastante simple en muchos aspectos. Una página web simple involucraba contenido estructurado en HTML2, algo de estilo básico y un poco de JavaScript para la interacción. Era fácil de entender y las cosas parecían manejables. Pero esa no es la web que conocemos hoy.

La web de hoy es un mundo diferente en sí mismo. Uno que ha crecido hasta convertirse en un ecosistema complejo. Ya no solo tenemos páginas estáticas y agregamos JavaScript ocasionalmente. La web moderna se trata de construir una aplicación completa que se ejecuta en el navegador para millones de usuarios en una barra lateral completa. Junto con el código de la aplicación, a menudo tenemos que trabajar con varios frameworks y bibliotecas como React, Vue, Angular que nos ayudan a gestionar el estado y las interfaces de usuario dinámicas. A menudo dependemos de APIs, microservicios, una función serverless para proporcionar los datos de nuestro backend. ¿Y cuál es el resultado? Una interfaz de usuario más interactiva, pero tan complicada bajo el capó.

Esta evolución ha creado, creo, una paradoja porque la web se ha convertido en un lugar más hermoso un lugar más capaz y más atractivo que nunca. Pero esta belleza viene con una mayor complejidad. La web minimalista, fácil de gestionar, se ha ido y ha sido reemplazada por una arquitectura de front-end compleja que exige una vigilancia y mantenimiento constantes.

Así que esto nos lleva al corazón de la discusión de hoy, la observabilidad. Pero, ¿qué significa exactamente? Así que ya sabes, veamos cómo la teoría de control lo define. La observabilidad es algo así como la observabilidad se trata de poder entender lo que está sucediendo dentro del sistema basado en su comportamiento interno o basado en su salida. Bien, esto es lo que dice la teoría de control. Pero si no estás familiarizado, ¿qué es la teoría de control? O si es la primera vez que escribes la palabra observabilidad, no te preocupes, es completamente normal. Aquí hay una manera simple en que se lo expliqué a mis hermanos menores. Imagina que decides jugar un juego intensivo de memoria o GPU en una vieja PC o quizás intentar hacer algo más como edición de video o incluso ver un video en 8k en eso. Así que tan pronto como presionas iniciar, notarás que tu PC para un ventilador de repente gira a una velocidad muy rápida, produciendo un ruido fuerte. A veces el sistema incluso podría fallar y apagarse de manera inesperada. Así que cuando el ventilador acelera y escuchas el ruido, sabes que algo inusual está sucediendo dentro de tu PC. Este escenario ilustra perfectamente la observabilidad a algún nivel porque ya sabes, cómo puedes entender el estado interno de tu sistema como un alto uso de GPU o ya sabes, observando su salida, como el ruido del ventilador o el sobrecalentamiento, y a veces fallos del sistema. Así que podemos decir que es la capacidad de decir, dado este comportamiento, qué está sucediendo dentro. Pero aquí es donde las cosas se complican para los desarrolladores de front-end.

Al igual que el back-end, su observabilidad a menudo es una parte integrada del flujo de trabajo. Nosotros, los desarrolladores de front-end, no estamos acostumbrados a usar la palabra observabilidad en primer lugar. Para nosotros, parece algo así, y a menudo intentamos unir múltiples fuentes como soluciones para intentar lograr una apariencia de visibilidad de lo que está sucediendo en nuestro sistema. A menudo usamos herramientas como monitoreo de errores, alertas, repeticiones de sesiones, métricas, monitoreo sintético, monitoreo serial, registros y todo lo que puedas imaginar.

Así que ya sabes, esto está bien. Pero donde cada herramienta da una parte de una imagen pero nunca la historia completa, tienes que ver. Por ejemplo, cuando un usuario informa un error, es realmente un proceso directo. El equipo de atención al cliente a menudo escalará el problema diciendo algo como, esta función no está funcionando para este grupo de usuarios. Pero recuerda, reconocer el problema no siempre es fácil. Así que pedimos una captura de pantalla o registro de consola y más detalles tratando de recrear el problema en nuestro propio entorno. A veces es un proceso tedioso lleno de idas y venidas que puede frustrar rápidamente incluso al desarrollador más apasionado, si tienen que hacerlo regularmente.

Así que si lo comparas con el mundo del back-end, es como comparar un rompecabezas fragmentado con una imagen completa. Algunos ingenieros tienen acceso a los registros detallados, datos recopilados, trazas distribuidas, métricas, registros, alertas de eventos, lo que sea, y todos ellos se unen en un solo flujo. Pueden rastrear cierto comportamiento del usuario cada vez que se activa una alerta, identificando dónde la solicitud se ralentizó o incluso falló. Eventualmente tienen un conjunto completo de herramientas para verlo todo, lo que facilita diagnosticar y solucionarlos. Pero para los desarrolladores de front-end, parece que, mirando a los de back-end, parece mirar un paraíso desde una cerca. El lado del back-end parece tener, ya sabes, como todo, un proceso optimizado, métricas claras, la capacidad de profundizar en los más mínimos detalles. Pero para nosotros, es como ensamblar un coche mientras conduces por la autopista. Y aquí es donde creo que nosotros, los desarrolladores de front-end, nos hemos quedado atrás en obtener una visibilidad de extremo a extremo en nuestro sistema en cierto sentido. Pero el césped parece más verde del otro lado, diría yo.

Pasando al siguiente punto, ¿qué herramientas usaríamos como desarrolladores de front-end? Hablemos de las dos cosas más comunes. La primera es el synthetic monitoring. Es como un experimento de control. Puedes configurar pruebas que simulan la interacción del usuario, haciendo clic en botones, cargando páginas y así sucesivamente. Pero aquí está el verdadero truco. Esto es, por definición, sintético y generalmente funciona alrededor de los conocidos conocidos. No puede replicar la realidad desordenada del comportamiento regional del usuario. Los bots no pueden imitar la imprevisibilidad de los usuarios de cómo usan sus propios navegadores, tienen malas conexiones de red o interactúan con su aplicación de cientos de maneras diferentes.

Creo que cuando se trata de entender la palabra producción, nosotros los desarrolladores de front-end entendemos producción como el dispositivo del usuario. Hay millones, así que lidiamos con millones de producciones, creo. Así que adelante. Esto nos lleva a la siguiente herramienta, el real user monitoring. Rastrea la interacción real del usuario en tu sitio, dándote una ventana a lo que los usuarios reales están experimentando. Recoge datos sobre el tiempo de carga de la página, el rendimiento de la red, el tipo de dispositivo y más. Te ayuda a entender, por ejemplo, si los usuarios en una región específica están experimentando tiempos de carga de página lentos o si un dispositivo particular está causando el error.

Sin embargo, debemos entender que RUM generalmente no está exento de desafíos. Primero, el RUM nos da una visión muy general, pero a menudo no nos proporciona el contexto más profundo que se necesita para entender la causa raíz del problema. A menudo luchamos entre la carga de RUM, los agregadores de registros, las herramientas de seguimiento de edición y solo para obtener una pieza de, solo para obtener, solo para juntar lo que está pasando. Agregar contexto específico del usuario puede volverse rápidamente un proceso que consume tiempo y también puede aumentar el costo. La segunda razón son los agentes de RUM. Estos a veces pueden causar conflictos con los scripts en tu propio sitio. Irónicamente, estos agentes pueden convertirse en una fuente de problemas por sí mismos, especialmente cuando no se llevan bien con servicios de terceros o scripts de usuario personalizados. En algunos casos, incluso se convierten en una razón para la próxima queja del usuario. Por último, tenemos una herramienta, las herramientas de RUM a menudo luchan cuando las horas de sesión duran demasiado. Como cuando un usuario deja una pestaña abierta durante horas, los datos se vuelven más difíciles de gestionar e interpretar. Lo que lleva a una brecha en la comprensión de lo que el usuario realmente está experimentando. Es excelente para dar una visión general, pero menos efectivo cuando necesitas profundizar más en un viaje específico del usuario. Entonces, la pregunta no es si tenemos una buena herramienta. El verdadero desafío es sobre la narración. Nuestras herramientas de monitoreo actuales hacen un buen trabajo al decirnos qué está pasando, pero a menudo no logran explicar por qué está pasando, por qué un usuario específico experimenta un tiempo de inactividad lento, y por qué algunos de los usuarios no lo hacen.

Entonces, esta brecha en la comprensión significa que necesitamos mucho tiempo en la búsqueda, pasamos mucho tiempo buscando la causa real del problema, en lugar de resolver el problema rápidamente. Diría que aquí es donde realmente brilla la observabilidad del front-end, porque se basa en el principio de que el contexto lo es todo. Y, usando este contexto no solo para monitorear, sino para entender cómo es el rendimiento de tu aplicación para diferentes usuarios y en diferentes situaciones.

Así que, con un buen contexto, podemos decir que podemos conectar fácilmente los puntos para obtener una vista clara de nuestro front-end y justo a tiempo. Por ejemplo, podemos decir que ahora podemos monitorear los web vitals, pero no analizarlos, sino profundizar más en la información. Como este, este es un ejemplo donde podemos ver los core web vitals, también el FCP, NCP, y diferentes cosas. Y también podemos profundizar más en esos datos hasta una sesión de usuario específica. Esto es algo de aprendizaje que podemos profundizar más en sesiones y eventos para identificar cuándo el usuario encuentra un error, qué tipo de error es, y si es una mala respuesta o un problema de carga de contenido o un problema específico del código del front-end. Y señalar qué parte del código lo causó. Este nivel de detalle nos ayuda a entender todo el recorrido del usuario.

Ahora tenemos datos de sesión específicos como la observabilidad del front-end desbloquea muchos de esos conocimientos, incluyendo la correlación exacta con la actividad del front-end y los trazos del back-end. Sin embargo, en este ejemplo, podemos ver que con la observabilidad del front-end, podemos profundizar más en un usuario específico, ver cómo es el recorrido y qué recorrido ha seguido el usuario, las solicitudes GET, las publicaciones IRR, cuántas solicitudes ha habido. Y también podemos ver los errores, si tienen un tiempo de inactividad más lento en algunos casos, como qué está causando este error. Así que también podemos ver esos datos específicos de la sesión. Y también podemos ver datos de correlación de trazos de extremo a extremo desde un front-end a un back-end. Así que la observabilidad del front-end desbloquea muchos de esos conocimientos, incluyendo la capacidad de correlacionar las actividades del front-end con nuestros trazos del back-end. Esto permite a los desarrolladores de back-end ver cómo sus cambios pueden impactar a los usuarios reales en el front-end. Esta característica es increíblemente valiosa para mejorar la experiencia del desarrollador también, no solo para el front-end o el back-end, sino para todo el equipo de ingeniería. Con este enfoque, ahora podemos entender mejor, identificar, depurar y acceder al impacto del problema en nuestras aplicaciones. Ahora tenemos eso. Esto es lo que la observabilidad del front-end pretende lograr. Un mundo donde pasamos de la depuración reactiva a la optimización proactiva.

Entonces ahora, ¿por qué estoy aquí hoy hablando de observabilidad? Es porque es hora de que demos el siguiente paso como desarrolladores de front-end. La web ha cambiado y nuestro rol ha cambiado con ella. Ya no podemos confiar siempre en la forma tradicional de monitorear y depurar. Si hay algunos puntos clave de esta charla, definitivamente serían sobre, como, es hora de repensar la observabilidad, no solo como un conjunto de herramientas, sino como una mentalidad. Porque no se trata solo de tener mejores herramientas. Se trata de adoptar la observabilidad como una cultura dentro de una organización. Se trata de romper los silos entre el front-end, el back-end, o todo el equipo de ingeniería para entender nuestro producto, nuestros usuarios, de una manera más efectiva. Así que cuando los desarrolladores de front-end entienden lo que está sucediendo en el back-end y viceversa, podemos entender mejor toda la experiencia del usuario, cómo se comporta el usuario, qué quiere el usuario. Así que, como, la observabilidad se convierte en una responsabilidad compartida que hace que todo nuestro sistema sea más resiliente. Así que ya sabes, eso es todo. Así que gracias por unirte a mi sesión hoy. Espero que lo hayas disfrutado y aprendido algo de eso. Y si realmente estás emocionado por la observabilidad del front-end, pronto, ya sabes, haré más contenido sobre eso. Así que hasta entonces, gracias por unirte a mí. Nos vemos pronto.