Arte y Entropía: Introduciendo el Caos en tu Frontend

Mi nombre es Thibaut, y me pueden encontrar en Twitter con el nombre de héroe Pseudo. Empecemos. ¿Has oído hablar de Kintsugi? Es el antiguo arte japonés de reparar cerámica y porcelana usando laca con incrustaciones de oro. Como filosofía, Kintsugi trata la rotura y la reparación como parte de la historia de un objeto, en lugar de algo que se debe disfrazar. En los primeros días de Kintsugi, alrededor del siglo XV en Japón, los coleccionistas estaban tan enamorados del resultado que intencionalmente rompían sus propias cerámicas y las reparaban. Con el tiempo, Kintsugi ha evolucionado y se ha fusionado con el arte contemporáneo. Ejemplos incluyen el trabajo de Jan Forman, quien usa Legos para reparar paredes en el paisaje urbano, pero también el trabajo de Raquel Susman, quien usa laca dorada para reparar asfalto. De esta manera, Kintsugi puede adaptarse a un nuevo medio. ¿Un nuevo medio, por qué no la web? Porque sí, preguntémonos. ¿Es nuestra aplicación web perfecta, sin errores, en todos los navegadores y en todos los tamaños de pantalla? No. Pero ¿necesita ser perfecta? No, solo necesita ser resiliente, funcionar sin importar qué. Puede estar rota y funcional, rota y hermosa, como cerámicas reparadas con Kintsugi. Suena bien. Entonces, ¿cómo nos aseguramos de que nuestras aplicaciones sean resilientes? Bueno, vamos a usar la ingeniería del caos para lograrlo. Tal vez hayas escuchado el término antes. Inventada por Netflix en 2011, esta práctica establece paralelismos en la ciencia con la teoría del caos, que es el estudio de la evolución del desorden de la entropía en un sistema. El objetivo es observar cómo reacciona un sistema ante perturbaciones intencionales. Por ejemplo, estrellar intencionalmente un servidor, y observar cómo reacciona la infraestructura. ¿Redirigirá las solicitudes a otros servidores? ¿Reiniciará un servidor y redirigirá el tráfico? ¿Qué tan rápido? Básicamente, rompemos cosas y luego observamos. Lo bueno es que, en lugar de esperar a que las cosas exploten, a verificar que nuestra infraestructura se mantenga, lo hacemos nosotros mismos. Y así es como mejoramos, aprendiendo cómo reacciona nuestra infraestructura ante el caos. Y donde alcanza el siguiente nivel es, en Netflix, lo hacen en producción. Estrellan su infraestructura regularmente, a veces varias veces al día, para asegurarse de que todo funcione correctamente. Y esto los ha llevado a establecer procesos de restauración altamente advanced automatizados hasta el punto en que pueden reiniciar regiones enteras de la infraestructura en solo unos segundos, sin intervención humana. Estos son los beneficios de la ingeniería del caos. En primer lugar, nos ayudará a descubrir e identificar debilidades en un entorno controlado. Sabemos qué rompimos, por lo que podemos revertirlo fácilmente si las cosas se tuercen durante el experimento. También nos dará una mayor comprensión de las interdependencias de los componentes del

nuestros sistemas. Interdependencias. Por ejemplo, en una empresa anterior, teníamos un antiguo servidor heredado que generaba PDF, pero también, y todos lo habían olvidado en ese momento, búsquedas JYP para fines de seguridad. Y un día, la infraestructura en la que se encontraba este servidor se volvió no receptiva. Comenzó una reacción en cadena donde las solicitudes de inicio de sesión de los usuarios, que dependían de JYP, también se volvieron no receptivas. Y ahí fue cuando nos dimos cuenta de que no había tiempos de espera definidos en esas llamadas, lo que a su vez significa que las solicitudes de inicio de sesión de los usuarios se acumulaban indefinidamente, deduciendo así toda nuestra infraestructura. Y, desafortunadamente, así es como redescubrimos las interdependencias de nuestro sistema. El tercer beneficio de la ingeniería del caos es la confianza. ¿Preferirías esperar a que te llamen a las 7 a. m. un domingo porque tu aplicación está caída, o preferirías romperla tú mismo un martes por la tarde y ver que todo funciona bien y que puedes dormir tranquilo en el fin de semana? Y finalmente, nos obligará a implementar un protocolo de recuperación ante desastres. No esperaremos a que ocurra un accidente antes de pensar en soluciones.

La cuestión es que en todos los recursos que existen sobre el tema de la ingeniería del caos, libros, documentación, todo se trata de la infraestructura. Así que me dije a mí mismo, ¿por qué no aplicarlo al frontend esta vez, porque no importa cuán resistente sea tu infraestructura, cuántos balanceadores de carga tengas, cuántas redundancias tengas, si tu frontend está roto, a los usuarios no les importa. Toda su experiencia en tu aplicación será negativa. Entonces, como dije, no hay recursos sobre el tema de la ingeniería del caos aplicada al frontend, ni tampoco hay herramientas todo en uno o cajas de herramientas para hacerlo. Entonces, lo que viene a continuación en esta charla es experimental. Veamos hasta dónde podemos llevar este tema. Comencemos con lo básico de la ingeniería del caos. Se aplica en cuatro pasos. Primero, definiremos el estado nominal de nuestro sistema. Por ejemplo, el usuario puede iniciar sesión, el usuario puede ver la última temporada de The Witcher. Segundo, haremos una hipótesis. Asumiremos la continuidad del estado nominal durante el experimento. El usuario todavía puede iniciar sesión, el usuario todavía puede ver la última temporada de The Witcher, y usaremos dos grupos para eso, grupo de control y grupo de prueba. Y tercero, crearemos intencionalmente una perturbación que reproduzca un evento real, por ejemplo, un fallo del servidor. Y finalmente, compararemos los estados de los dos grupos y trataremos de refutar la hipótesis planteada anteriormente. ¿Nuestros usuarios todavía pueden iniciar sesión y ver la última temporada de The Witcher? Si no pueden, entonces acabamos de identificar una falla en la resiliencia de nuestro sistema. Nuestro objetivo es aplicar este experimento de ingeniería del caos al frontend. Para los pasos uno, dos y cuatro, no es muy diferente de la ingeniería del caos clásica. Así que vamos a analizar el paso tres y cómo podemos crear interrupciones en el frontend. Hay algunas áreas de perturbaciones que podemos ver. La primera es las solicitudes HTTP. Puede ser en forma de una red 3G lenta, Wi-Fi inestable, CDN no receptiva, etc.

La perturbación del mundo real se puede resumir en respuestas HTTP realmente lentas o simplemente ninguna respuesta en absoluto. Un ejemplo de una aplicación que maneja esto muy bien es GitHub. Todo el CSS y JavaScript se aloja en un CDN en GitHub.githubassets.com. Podemos simular lo que sucede si el CDN falla en Chrome bloqueando todas las solicitudes de red a ese dominio. Y esto es cómo se ve. Aquí estoy en el repositorio de React y estoy buscando en las diferentes carpetas y archivos para encontrar lo que estoy buscando. Y sí, aquí puedo encontrar el archivo que quiero y todo el código asociado. Y podemos ver dos cosas. En primer lugar, no es bonito. Pero en segundo lugar, funciona. Podemos navegar por el repositorio y ver el código. Y este es un buen ejemplo de resiliencia. Incluso sin CSS, sin CSS externo y sin JavaScript, GitHub funciona. Y así es como podríamos inducir intencionalmente perturbaciones en nuestra aplicación. Podemos hacer proxy, xhre y fetch. Esto se puede hacer en unas pocas líneas de código. Por ejemplo, agregamos una posibilidad de uno entre dos de agregar un retraso aleatorio y una posibilidad de uno entre cien de fallar completamente las solicitudes. Lo agregamos a la aplicación y con eso veremos rápidamente si nuestra aplicación maneja bien los retrasos o los errores. Otra área de perturbación que podemos hacer es la localización. Esto puede ser complicado de manejar debido a los idiomas de derecha a izquierda, fuentes latinas, espaciado, etc. En la perturbación del mundo real, así como en los idiomas de derecha a izquierda, también están los idiomas verbosos. Tomemos un ejemplo. Acabo de desarrollar un bonito botón. Ha sido aprobado por el diseñador. Vamos a enviarlo a producción. Pero espera. Esto es lo que realmente verán los usuarios rumanos. Le di a mi botón un ancho fijo y ahora está roto. Pero el problema es que no hablo rumano.

Hablo francés y lo suficiente en inglés para dar esta charla. Entonces, ¿cómo podemos romper intencionalmente nuestra aplicación en la localización y aún así tener una buena experiencia de desarrollo? Bueno, podemos usar lo que se llama localización pseudo. Este método reemplaza el texto con una versión alterada con más letras y caracteres, pero aún legible para un humano. Y para hacer eso, podemos usar el paquete de localización pseudo de TrickVGilfason que puede realizarlo automáticamente en la aplicación. Aquí hay un ejemplo de cómo se vería en el sitio web de React. Y como podemos ver, el texto es más largo que el original con acentos y otros glifos. Y sin embargo, la interfaz lo maneja bastante bien. Los botones no se desbordan y el menú ocupa el espacio necesario para mostrarse. Otra área de perturbaciones son los temporizadores. Todos asumimos que un segundo es igual a un segundo, ¿verdad? Y sin embargo, eso no es exactamente cierto en Browserlandia. En algunos casos, los navegadores pueden optar por limitar los temporizadores para reducir el uso de CPU y batería. Y esto significa que si tu aplicación espera que se llame a un temporizador después de un tiempo específico, este temporizador puede retrasarse hasta un minuto, lo que puede romper tu función. Puedes reproducir intencionalmente esta perturbación mediante la proxy de set timeout y set interval para agregar intencionalmente retraso a los temporizadores. Si tu aplicación no maneja esto, notarás rápidamente el problema. Entonces, aquí en este código, hay una posibilidad entre dos de agregar 500 milisegundos o restar 500 milisegundos. Y la cuarta área es el historial. A menudo vemos el recorrido del usuario como un camino lineal e unidireccional en la aplicación. Pero a menudo olvidamos que es bastante frecuente que los usuarios retrocedan y avancen en el historial para realizar acciones. Y también puede suceder por accidente. Y no hay nada tan frustrante como perder tus datos en un formulario grande cuando eso sucede. Nuevamente, podemos crear manualmente esta perturbación con un par de líneas de código. Aquí, cada minuto, hay una posibilidad entre 100 de retroceder o avanzar aleatoriamente en el historial de navegación. Entonces, esas son las cuatro áreas de perturbación. Pero puede haber incluso más. ¿Por qué no simular doble clic para cada clic de nuestros usuarios? ¿Por qué no convertir nuestra aplicación en blanco y negro con una sola línea de CSS para verificar problemas de accesibilidad? O volvámonos locos. ¿Por qué no forzar los viewports de dispositivos móviles y tabletas, incluso en el escritorio, para asegurarnos de que nuestras aplicaciones también funcionen allí? Entonces, sí. A estas alturas, debes estar mirándome así. Lo que hemos visto parece interesante, pero es posible que estés perdido en cómo hacerlo realmente en tus aplicaciones web. La buena noticia es que mentí. Antes en esta charla, dije que no había herramientas todo en uno para la ingeniería del caos en el frontend.

Pero eso no es cierto. Porque quiero que experimentes con la ingeniería del caos, creé kits de herramientas de ingeniería del caos en el frontend, que es una extensión del navegador y una biblioteca NPM que incluye todas las áreas de perturbación mencionadas anteriormente. Podrás simular doble clic y muchos más experimentos con un solo clic. Y ahora, así es como te veo. Estás listo para volver a tus empresas y romperlo todo. Pero antes de dejarte, quiero pedirte que escuches las palabras de Tessia De Vries. La magia es organizar el caos. Y aunque quedan océanos de misterio, hemos deducido que esto requiere dos cosas. Equilibrio y control. Sin ellos, el caos te matará. Y como dice Tessia De Vries muy bien, la magia es organizar el caos. Esto requiere dos cosas, equilibrio y control. En primer lugar, control. No olvides que la ingeniería del caos es un método de experimentación. Necesitamos establecer límites para este experimento en un sistema dado y durante un tiempo determinado, respetando los cuatro pasos: estado nominal, hipótesis, perturbación, comparación. Y finalmente, equilibrio. El caos debe estar lo suficientemente presente como para probar la resistencia del sistema, pero no demasiado presente como para molestar a los usuarios. Y aquí llegamos a lo que creo que es un límite de la ingeniería del caos aplicada al frontend. En los experimentos de ingeniería del caos realizados por Netflix en producción, las interrupciones son casi invisibles para los usuarios porque todo ocurre en el backend. Pero en el frontend, el usuario inevitablemente se verá afectado por las interrupciones que mencioné anteriormente. Entonces, creo que es imposible implementarlo en producción. En el mejor de los casos, se podría aplicar a entornos de prueba y puesta en escena. Pero dado que la ingeniería del caos aplicada al frontend nunca se ha hecho antes, ¿por qué no ser un precursor y ver qué se puede hacer con ella? Apliquemos la filosofía del Kintsugi. Tratemos la ruptura y la regrabación como parte de la historia de nuestra aplicación en lugar de algo que se debe disfrazar. Esto es el final de la presentación. Gracias por escuchar.