Diseñando para el Fallo: El Kit de Herramientas de Producción del Desarrollador Senior de React

¡Eso es lo que quiero escuchar! Llevo un patito de goma a cada una de mis charlas porque no solo ayuda a despertar a la gente un poco. Como vieron, soy de Suiza, así que es más barato que pagar terapia allá, y también es más fácil para depurar, para los OGs que quieren depurar cosas en lugar de correr a nuestros asistentes de IA. Me encantó la última charla porque hubo una insinuación sobre que necesitamos volver un poco y reafirmar los fundamentos, así que vamos a hablar justo de eso hoy, sobre cómo diseñamos para el fallo y vamos un poco a algunos conceptos fundamentales de ingeniería para poder hacerlo, y qué mejor manera de ver cómo diseñar para el fallo que explorar algunos fallos del mundo real juntos.

Así que un poco más sobre mí. Soy ingeniero front-end senior en Small PDF. ¿Alguien aquí ha usado Small PDF antes? Bien, voy a hacer otra pregunta. ¿Alguien ha pagado por Small PDF antes? Todas las manos han bajado. Trabajo en el equipo de monetización de Small PDF, así que cuando las manos bajan, significa que no estoy haciendo algo correctamente en mi trabajo diario. Así que espero que la próxima vez que venga al React Summit podamos tener un par de manos más levantadas. Otra cosa divertida sobre trabajar en una empresa de PDF es que, después de las charlas, mucha gente viene a hacerme preguntas específicas sobre PDF. En casi dos años de trabajar en Small PDF, no he tocado la parte de PDF del producto. Así que reservo sus preguntas sobre PDFs para otros expertos en eso.

Pero alrededor de eso, he trabajado en industrias de TV conectada. Me encanta el liderazgo en ingeniería de rendimiento web. También soy embajador de RayCast, un gran fan de RayCast. ¿Alguien aquí es usuario de RayCast? Sí, veo algunas manos más levantadas. Fantástico. Co-fundé Zurich JS, y también soy un constructor de comunidad de Stripe. Ahora me gusta tomar los títulos de mis charlas y como que reformularlos en una pregunta. Así que para diseñar para el fallo, me gusta que la pregunta sea un poco más, para ser respondida sobre cómo construimos interfaces de usuario resilientes en React. Ahora, aunque estamos hablando mucho sobre cosas relacionadas con React o incluso algunas cosas de Next.js, muchos de estos principios son independientes de la pila. Así que, ya seas un desarrollador de Vue, desarrollador de Angular, puedes tomar estos patrones y aplicarlos a múltiples pilas diferentes. No estás simplemente atrapado con algo.

Para entender un poco más la resiliencia, veamos la definición de resiliencia. Y lo primero que puedes hacer es ir a Google, es como, ¿cómo implemento patrones de ingeniería de software? Y vas a ver algunas explicaciones complicadas de eso. Y me gusta volver al vocabulario en inglés y cómo entendemos mejor las palabras que usamos en ingeniería, porque también provienen de espacios no relacionados con la ingeniería. Entonces, ¿cuál es la definición de Google de resiliencia? El acto de recuperarse o rebotar de algo, ¿sabes? Y la pregunta es, ¿por qué nos importa hacer que nuestras aplicaciones de React sean resilientes? ¿Por qué queremos que se recuperen si se caen? Al final del día, tus aplicaciones, tus aplicaciones web son capas de integración. Hay tantas cosas siendo integradas antes de que algo llegue desde el local host hasta la producción. Y cada una de estas integraciones esencialmente sirve como un punto de fallo que existe en tu aplicación. Estás lidiando con todo tipo de APIs. Estás lidiando con pagos, autenticación, banderas de características, cachés de cliente, actualizaciones optimistas, y puedo nombrar muchas más. Y cada una de estas tiene diferentes formas en las que quieres aplicar resiliencia.

Quiero hablar un poco también sobre las caídas, porque cuando algo no es resiliente o algo falla, naturalmente hay una caída o algo sale mal. Y las más fáciles de notar son las caídas totales. Ahora, sé que la sala está un poco verde por aquí, pero ¿alguien tiene el color favorito rojo? ¿A alguien le gusta el color rojo? Depende del día, ¿verdad? Las caídas más fáciles de notar son las totales. Esta es una caída total. Algo salió mal muy, muy rápido. Los pagos simplemente no estaban funcionando en absoluto, y así ves alertas rojas por todas partes. Las cosas están saliendo mal. Y para darte un poco de contexto, small PDF tiene alrededor de 30 millones de usuarios por mes, ¿verdad? Y así, cuando tienes una caída total y algo sale mal muy, muy rápido, las barras rojas suben igual de rápido.

Y solo viendo Datagog por aquí, estás viendo el mismo ejemplo exacto donde las cosas están bajando, porque ya no podemos hacer pagos. De lo que quiero hablar un poco más que de esas caídas totales, esas son las fáciles de notar. Las más difíciles de notar son las caídas sutiles. Las que son casi como la muerte por mil cortes. Las que sangran lentamente con el tiempo. Y esas son más cuando hay problemas parciales que existen. Cuando una sola API está caída, pero el resto está bien. Las que pueden ser regionales, donde las cosas solo, ya sabes, en Suiza, todo funciona, pero en cuanto llego a Ámsterdam, todo falla. Luego puede haber problemas condicionales donde solo fallan los mecanismos de reintento, pero solo sucede en Safari. Luego tienes problemas impulsados por carreras, y digamos que un usuario está tratando de pagar antes de que el gateway de pago esté cargado, así que están haciendo clic en un botón de PayPal, pero no se ha cargado nada para poder comenzar a ejecutar un pago. Y solo quería tomar una instantánea de nuestro panel de errores usando track.js y small PDF.

Si miras los números por allí, en siete días, tenemos 732,000 errores. Con alrededor de 22 millones de vistas de página, un cuarto de millón de usuarios afectados, y adivina qué? Estamos un 17 por ciento abajo. Eso es una buena semana. Lo que es tan interesante a esta escala es que casi veo esto como un mar de errores, ¿verdad? Si tomas una roca y la lanzas al mar y hay todas estas olas, nunca verías las ondas, ¿verdad? Si tuvieras un estanque en su lugar, un cuerpo de agua mucho más pequeño, y lanzas una roca, como un problema ocurriendo, verías las ondas y podrías detectar que algo está pasando.

Entonces, en una cantidad tan vasta de problemas, ¿cómo sabes cuál es la cosa correcta para detectar y reaccionar, ya sea un usuario de pago que está teniendo un impacto, o un usuario gratuito, o es un flujo de pago que puede ser más importante que una descarga de PDF? Y así quiero mostrar el primer incidente de uno de esos casos de sangrado, donde tuvimos fallos de pago por código postal inválido para Canadá y Gran Bretaña, y alrededor de 4,400 usuarios estaban siendo afectados. Y lo que sucedió fue que teníamos un endpoint geo IP que estaba tratando de inferir un código postal para un usuario basado en la dirección IP, y no lo estaba obteniendo correctamente, no estaba pasando la validación esencialmente para Canadá y GB. Pero esos no son necesariamente nuestros mercados de ARR más altos, o donde tenemos más usuarios, así que comparado con todos los otros países en los que operamos, realmente no vas a ver un aumento en errores lo suficientemente significativo como para activar una alerta.

Y así esto terminó durando 35 días. Sin embargo, eso costó más de £30,000 de ingresos perdidos esencialmente. Mientras que si tuvieras una interrupción total y las cosas comenzaran a aumentar al punto que lo notaras dentro de cinco minutos, dudo que hubiera sido la misma cantidad de pérdida monetaria. Veamos otro. Pagos 3D secure fallando durante nueve meses. ¿Alguien aquí ha experimentado una interrupción de más de nueve meses? Bien, genial, tenemos un récord, ¿verdad? Esa es una cantidad de tiempo extremadamente larga para que algo esté saliendo mal al punto que tienes ingresos filtrándose de tu sistema, pero no se considera una interrupción global. Todavía puedes descargar PDFs, comprimirlos, fusionarlos, y así sucesivamente. Y así, a escala, la detección es mucho más difícil que la prevención, y por eso las medidas preventivas como la introducción de patrones de resiliencia son mucho más importantes, porque no puedes detectar todo.

Entonces, ¿cuáles son los patrones de resiliencia típicos que podríamos emplear? El primero que quiero introducir es un circuit breaker. Y nuevamente, aunque lo estamos introduciendo aquí en un concepto de ingeniería, los circuit breakers existen en conceptos no relacionados con la ingeniería, conceptos de ingeniería de software. ¿Alguien tiene fusibles en casa con los que haya jugado alguna vez? Un fusible se rompe, rompe el circuito, salva tu casa de incendiarse o algo así, ¿verdad? Caso similar en la ingeniería de software. Previene que una aplicación ejecute repetidamente una operación que probablemente falle. Entonces, ¿cómo opera eso? Tienes tres estados que existen dentro de un circuit breaker.

Un estado cerrado, y normalmente, no sé, me toma un minuto entender esto en mi propia cabeza, porque cuando pienso en cerrado, usualmente pienso en rojo. Así que en este estado, cerrado es verde, porque el circuito está cerrado. Y tienes dos sistemas operando, conectando y moviéndose. Tienes un estado medio abierto, y luego tienes un estado abierto. Así que ya hablamos sobre el estado cerrado. Hay operación normal, las solicitudes están pasando, estás haciendo llamadas API a proveedores upstream todo está bien.

Luego, después de un fallo, vamos directamente a un estado abierto. Todo se abre, y se ha alcanzado un umbral, por ejemplo. Y una vez que se ha alcanzado ese umbral, estás bloqueando solicitudes en ese punto, porque ya sabes que algo no va a funcionar, así que ¿por qué seguir intentándolo? Y luego lo que sucede es que después de que se ha alcanzado un tiempo de espera, digamos 30 segundos o dos minutos, lo que sea, comienzas lentamente a probar una conexión nuevamente. Y si pasa, cierras el circuito nuevamente. Y si falla, lo abres de nuevo. Y la forma en que me gusta referenciar esto es imaginar que realmente has molestado a tu mejor amigo al punto que no quiere hablar contigo de nuevo, y necesita espacio y tiempo.

Eso es exactamente el circuito abriéndose. Y luego de vez en cuando, una vez que se han alejado un poco y les has dado un poco de espacio, vas a ver a tu amigo y le preguntas, ¿estás bien? ¿Estás bien? ¿Estamos bien? ¿Podemos ser amigos de nuevo? Y tienes esa conexión que vuelve a existir, ¿verdad?

Así que trata a tu API a veces como si se pudiera molestar un poco por demasiada interacción. Pero, ¿cómo se ve esto implementado en un caso como con Next.js? Podemos hacer esto muy fácilmente con los manejadores de API que tenemos allí. Entonces, lo que podríamos hacer es tomar una solicitud get muy tradicional, y lo que hacemos es crear un breaker de detalles del producto. Así que esta es solo una solicitud de obtención de detalles del producto que queremos poder hacer. Disparamos el breaker del producto, esperamos los datos, y esencialmente, si todo está bien, simplemente pasamos el estado del circuito y los datos.

Si algo ha salido mal en la declaración catch, devolveremos algún tipo de respaldo. Y profundizando un poco más en ese breaker de detalles del producto, esencialmente allí estamos definiendo dentro de la función fetch product un par de parámetros alrededor de la funcionalidad del circuit breaker en torno al tiempo de espera, el porcentaje de umbral de error, y cuándo se restablece ese tiempo de espera. Y esto es usando una biblioteca de código abierto llamada possum, así que es bastante simple integrar algo como esto. El siguiente que quiero introducir es el patrón de reintento. ¿Quién ha usado un reintento antes? Creo que es como el primero que cualquiera recoge, ¿verdad?

Una solicitud falla. Esta es la reacción de la aplicación. Lanza todos los reintentos ahora. Y digamos que tu API tiene un límite de tasa global al que estás contactando, y tienes una interrupción como esta donde el límite de cotización de la API de Recurly se ha agotado. Y entonces lo que sucedió en este caso es que consultamos un endpoint para nuestro servicio de pago demasiadas veces, pero como era un límite global y comenzamos a reintentar demasiadas veces en fallos, una vez que alcanzamos el límite, cualquier otra cosa como crear suscripciones también falló aunque estábamos alcanzando el límite para una solicitud que no estaba relacionada con ello. Así que puedes tener un impacto realmente grande en tu plataforma si reintentas demasiado, y por lo tanto no todos los errores son o deberían ser errores reintentables, y debemos refinar cuándo y cómo ejecutamos estos reintentos.

Más allá de eso, tienes retroceso exponencial que va más allá de los simples reintentos, veamos, tienes tres reintentos predeterminados como tienes en TAN stack query, tienes reintento uno, dos, tres, se ejecutan inmediatamente, de lo contrario con un retroceso exponencial, tienes la primera solicitud, luego esperas tal vez un segundo. Luego tienes la segunda donde esperas dos segundos, luego tres segundos, estás dando un poco de espacio para respirar. Pero esto en sí mismo también puede ser problemático porque si tienes múltiples clientes haciendo esto al mismo tiempo, lo que puede suceder es que cuando una API vuelve a estar en línea, puedes entonces tener múltiples clientes golpeando de nuevo al punto donde vuelve a caer, y aquí es donde introduces algo llamado jitters. Jitters en reintentos es esencialmente más allá de ese tiempo de retroceso exponencial, esencialmente añades algo de aleatoriedad a cada solicitud para asegurarte de que múltiples clientes no estén activando solicitudes exactamente al mismo tiempo. Hay algo de aleatoriedad.

Si eres un poco ingeniero de backend, puedes pensar en esto como saltear una contraseña hash para añadir esa aleatoriedad adicional, lo mismo que estamos haciendo con una solicitud, y esto evita este problema de la estampida. Y estoy bastante seguro de que la mayoría de ustedes conocerán un problema de estampida muy famoso, que es el incidente de Cloudflare del 12 de septiembre, que estaba relacionado con nuestro maravilloso use effect que tenía un encantador array de dependencias que se volvió un poco rebelde y comenzó a activar demasiadas solicitudes y seguía derribando la plataforma, y realmente recomiendo leer este postmortem. Cloudflare tiene postmortems increíbles. Pero si alguna vez te preocupa si algo es un problema de estampida o no, siempre puedes confiar en que David K. Piano será el que esté tuiteando al respecto y tal vez culpando a use effect nuevamente. Avanzando, quiero introducir otro llamado el patrón de tiempo de espera, y para este quiero mostrar un poco de una demostración. Primero, vamos a mirar un panel financiero aquí, y lo que voy a hacer es simular algo de latencia en una respuesta de API donde estamos haciendo una solicitud en el servidor para poder obtener datos, para poder tenerlos en el HTML inicial y enviarlos al cliente.

Primero, vamos a mirar un panel financiero aquí, y lo que voy a hacer es simular algo de latencia en una respuesta de API donde estamos haciendo una solicitud en el servidor para poder obtener datos, para poder tenerlos en el HTML inicial y enviarlos al cliente. Lo que sucede en este caso es que porque estamos haciendo este trabajo en, digamos, get server-side props en Next.js, todo está bloqueado. No estás enviando nada al cliente hasta que las solicitudes se resuelvan, y digamos que esas solicitudes toman un tiempo súper largo, tu tiempo de renderizado más rápido solo puede ser tan rápido como tu solicitud más lenta. Y así, en algún momento, puede que quieras implementar una estrategia donde te retires de algo que está tomando demasiado tiempo, y los navegadores tienen tiempos de espera mucho más largos para tales cosas, tal vez incluso hasta 30 segundos, por lo que puede que quieras tener tus propios personalizados para esto. Así que este es un ejemplo de cómo eso puede haber sido implementado para ese panel financiero. Tienes un get server-side props, estamos haciendo un prefetch aquí con algún tipo de solicitud para estas transacciones, estamos deshidratando eso, estamos pasando en los props, y lo que podemos añadir es una capa encima que es solo una función para crear ese prefetch donde tal vez pasamos un tiempo de espera de algún tipo que usa un promise.race bajo el capó, y pasamos un tiempo de espera de 500 milisegundos o algo más, tal vez incluso un tiempo de espera de dos segundos, y luego dependiendo de si el tiempo de espera se activa primero o los resultados de la solicitud primero, entonces podemos retirarnos de eso, y luego porque no habrá caché listo en el lado del cliente cuando tenga lugar la hidratación, Tanstack query hará coincidir las claves de consulta e intentará esencialmente asegurarse de que tenemos esos datos siendo obtenidos en el lado del cliente, en lugar de intentar prepararlos en el lado del servidor. En este caso, estamos creando una gran experiencia de usuario en el mejor de los casos, pero en condiciones subóptimas, todavía estamos optimizando para la experiencia del usuario y retirándonos de esas condiciones. Otra forma de abordar esto, si tienes una versión más reciente de Next.js o estás trabajando con una pila mucho más moderna, puedes implementar streaming que te permite iniciar esa misma solicitud en el servidor y llevarla al cliente, y todo puede resolverse a su manera, y no estás bloqueando nada, esencialmente. Así que Next.js 16.3 vale la pena probar para este tipo de cosas con pre-renderizado parcial, técnicas geniales que puedes hacer para añadir resiliencia y asegurarte de que estás haciendo trabajo bloqueante con suspense.

La siguiente pregunta que quiero hacer es si alguien ha oído hablar del patrón de compartimentos estancos antes. Manos arriba. Bien, un par de personas. Puedo garantizar que al menos el 50 por ciento si no el 90 por ciento de las personas aquí han usado un patrón de compartimentos estancos antes. Así que el patrón de compartimentos estancos aísla una parte de un sistema en un grupo separado, aísla una parte de él que falla, o se sobrecarga, o algo sucede que no impacta el resto del sistema. Límites de error, ¿verdad? ¿Alguien aquí ha oído hablar de límites de error? Eso es muchas más manos. Así que, patrones de compartimentos estancos, algo que es más un término más amplio de ingeniería de software, nuevamente, algo que usamos todos los días, pero es realmente bueno poder asociar estos patrones, y así, ¿quién aquí está simplemente lanzando un límite de error global en la aplicación y están contentos con eso? Veo eso muy, muy, muy comúnmente. Así que no nos sorprende cuando vemos un escenario como este donde tenemos múltiples piezas diferentes de UI y luego, boom, error de aplicación, o voy a escribir algo aquí y luego de repente escribo lo incorrecto, voy a fallar de nuevo, ¿verdad? ¿Por qué una parte de la UI está impactando una parte no relacionada de la UI? E incluso más allá de eso, si abro Sentry, y solo estaba capturando Sentry, lo que sea lo crudo que estaba recibiendo de esos errores siendo lanzados, veo error, error de tipo, error. ¿Alguien sabe qué está pasando? Le preguntaría al patito de goma, pero está un poco cansado ahora mismo. Bien. Así que, creo que eso también es un poco inaceptable no poder diagnosticar lo suficientemente rápido, así que realmente quiero que pienses en tratar de construir cuadrantes cuando se trata de límites de error, tratando de aislar lo más cerca posible de donde crees que la funcionalidad relevante debería estar delimitada, y así, mirando este límite de error de cuadrante, estamos haciendo un par de cosas aquí. La primera cosa es que en realidad vamos a definir algo llamado etiqueta de error, y veremos cómo eso es útil en un segundo. Cada vez que defines un límite de error, pasas una etiqueta de error y usas el sistema de tipos para asegurarte de que termina en error, pero no importa si solo termina en error, puedes esencialmente usar la plantilla de cadena para poder poner error de límite al final, o estás aprovechando el sistema de tipos para imponer algún nivel de etiquetado que puedes propagar a tu herramienta de reporte de errores como Sentry para hacerlo mucho más fácil de depurar cuando una pieza delimitada de tu aplicación falla. En ese componente, luego se pasa eso a esta función de reporte de error, que toma esta etiqueta de error, y luego, en eso, esencialmente estamos creando un nuevo error a partir de eso, pasando el original como causa, y luego reportamos eso a Sentry. ¿Cómo se ve cuando comenzamos a aislar las cosas un poco más cerca de donde están yendo mal? No solo tenemos ahora UIs únicas que existen solo para donde las cosas están yendo mal, como, si mi barra de navegación está rota y por alguna razón falla, ¿por qué mis widgets también deberían sufrir como resultado? Puedes entonces tener experiencias de usuario que están adaptadas a los fallos que están ocurriendo. Pero más allá de eso, porque estás pasando etiquetas de error, ahora recibes cosas como error de cuenta regresiva de temporizador error de renderizado de entrada, puedes aislar exactamente dónde en la base de código ocurrió el problema, y eso significa que porque también estás usando el sistema de tipos para garantizar que todos son identificadores únicos, lo que puedes hacer es simplemente copiar y pegar lo que sea el título de ese error en tu IDE, buscar por él, y sabes exactamente dónde ocurrió ese error en lugar de tener que recorrer un rastro de pila. Porque muchos de nosotros nos sentimos súper abrumados cuando recibimos muchos mensajes de Slack y alertas de cuántos errores ocurren en Sentry, cuántos errores ocurren que recibimos por correo electrónico. A veces simplemente silenciamos e ignoramos esos canales, y lo que es genial es que recibiremos un correo electrónico como este con un error de botón no funciona, y sé exactamente qué salió mal en mi aplicación, y puedo clasificar efectivamente en lugar de sentirme abrumado. Pero en general, ¿cómo medimos el éxito con esto? Y ahí es donde quiero hablar un poco sobre las métricas dora. ¿Alguien aquí ha oído hablar de las métricas dora antes? Un poco sobre las métricas de investigación y evaluación de DevOps, y se centran en cuatro cosas principales. Frecuencia de despliegue, con qué frecuencia despliegas código, tiempo de espera para cambios, tiempo desde el compromiso de código hasta la ejecución en producción, tiempo medio de recuperación, que es qué tan rápido se restaura un servicio después de un incidente, y tasa de fallos de cambio, el porcentaje de cambios que causan incidentes. Ahora, ¿por qué me encantan tanto estas métricas? Porque creo que a veces hemos sobre-glorificado la cobertura de pruebas unitarias a veces, o todas estas otras métricas que son mucho más fáciles de manipular, y estoy seguro de que estas métricas dora también pueden ser manipuladas, pero muchos de nosotros nos enfocamos mucho en cuántas pruebas unitarias tenemos, o cuántas nuestras IA están generando, pruebas de integración, pruebas de extremo a extremo, qué reglas de lint, cómo están nuestros perfectos archivos Cloud MD, o lo que sea que sea.

No importa. Todas estas métricas dora ayudan a contribuir a una mejor comprensión de la experiencia del usuario final, y eso es todo lo que importa. ¿Está disponible la cosa? ¿Qué tan rápido puedo arreglar algo una vez que tengo un commit para poder desplegar a producción? ¿Con qué frecuencia estoy lanzando algo donde las cosas están saliendo mal? Y eso es todo en lo que deberíamos estar pensando. Así que, hasta luego, y gracias por todo el pescado.

Solo quiero comenzar diciendo, charla increíble. Tengo una cita específica que realmente voy a usar. Cuando hablaste sobre cómo los errores, es como un océano. Podría ser un océano o un estanque. Y cuando tienes un proyecto pequeño, no muchos usuarios, cada error es como una gran onda. Puedes verlo. Pero lanzas una piedra en el océano, no ves nada porque tienes estas olas, y luego incluso olas, algunas son tsunamis, algunas son olas. Y es realmente interesante. Y creo, también, lo que mencionaste, ese ejemplo de una interrupción masiva que arreglas en cinco minutos puede estresar a todos y no costar dinero a la empresa, mientras que la pequeña interrupción que ha estado ocurriendo durante 30 días, ese ejemplo, fue realmente, realmente brillante. Así que solo quiero pausar y decir, realmente aprecié la charla.

Tenemos una pregunta que llegó, que es sobre anti-patrón. Entonces, ¿cuál es el anti-patrón más común que observas que los desarrolladores intermedios usan cuando están manejando errores de producción en React? Hay dos principales, y mencioné ambos. El primero es el exceso de reintentos. Entonces, si tu ejemplo es reintentar ante cualquier error, si la respuesta no es correcta, simplemente reintentar. Eso no es lo que deberías estar haciendo. Por ejemplo, ¿por qué estás reintentando ante una respuesta 400? Puede ser que lo que estás enviando no sea válido, no tiene sentido reintentar, algo así. Así que ser capaz de profundizar, ¿cuáles son los errores que estás recibiendo de las APIs y segmentarlos en errores reintentables y no. Y no solo ir por el defecto de tres, sino tratar de detectar cuántas veces estás consultando una API y qué tan lejos estás de alcanzar un límite de tasa de API, eso también es increíblemente útil, porque solo un defecto de tres es una buena regla general, pero no debería aplicarse en todos los casos. Especialmente cuando un producto está a gran escala, quieres asegurarte de que no estás golpeando los límites de una API, o al menos negociar con quien tenga los límites de la API, como si negociamos con Recurly, tal vez puedan aumentar esos límites dependiendo de los casos de uso, así que optimizar cuándo reintentar.

El segundo es los límites de error. Ya viste un par de manos levantarse. Los límites de error son siempre ese gran try-catch global que pones en la parte superior de la aplicación, y generalmente he tenido dificultades para entender por qué no podemos aislar eso un poco más cerca de donde podrían estar ocurriendo los errores, pero si podemos hacer eso y pasar no solo las etiquetas de error a los límites de error sino cualquier punto de falla, las etiquetas de error deberían pasarse a las solicitudes fetch, cualquier cosa que puedas estar envolviendo en un try-catch, esas son solo cosas simples que puedes alejar de lo que estás haciendo actualmente como prácticas. Me encanta eso, y eso nos lleva muy bien a la siguiente pregunta, que es cómo encontramos, sé que nos diste algunos patrones, pero muchas veces las personas tienen sistemas ligeramente diferentes, e incluso encontrar errores va a depender mucho de la forma en que su sistema está construido, dónde están las fallas, qué fallas son importantes o no. ¿Cuáles son algunos enfoques de reconocimiento de patrones, deberíamos decir, para que las personas descubran qué patrones deberían estar implementando, tal vez algunos nuevos patrones, cómo pueden descubrirlos? Esa es una muy buena pregunta.

Creo que también la respuesta más común a la mayoría de las preguntas en desarrollo de software es depende, ¿verdad? Es mi primera del día. ¿Verdad? Quiero decir, hay dos partes, ¿verdad?, está descubriendo cuáles son más patrones que existen que los que acabo de mencionar, y simplemente poder buscar en Google patrones de resiliencia de software ya te llevará por un agujero de conejo en sí mismo. Hay mucho que explorar allí. Luego, la otra parte es también abrirse al diccionario de inglés, que es cómo relacionas algunos de estos patrones con la vida real, y puede que ya hayas estado implementando patrones en la vida real que son patrones de resiliencia que podrías querer ser capaz de cambiar y usar dentro de tus productos de software. Y luego la otra parte es, está bien, ahora tengo una base de código, y estoy entendiendo qué problemas tengo, ¿qué patrón aplico? ¿Aplico el reintento? ¿Aplico el retroceso exponencial? Y la mejor respuesta que puedo dar es realmente probar cosas, ¿verdad? Si estás haciendo cosas sin medir el éxito, y no solo las métricas Dora, sino en ese mismo sentido de medir, con reintentos, ¿qué tan lejos estoy de alcanzar un límite de API?, tal vez poner un umbral donde si estoy al 90% usado en términos de mi límite de tasa de API, entonces activar una advertencia y puedo reevaluar mi estrategia de reintento, ahí es donde podrías considerar, tal vez, está bien, voy a agregar algún retroceso exponencial u otras estrategias allí, pero ser capaz de medir el patrón que pones en su lugar ya es una gran manera de comenzar, y descubrir qué iteración de él es la correcta para ti.

Bien. Muy bien. Entonces imagina que alguien hace la pregunta, ¿debería usar un límite de error? Podrías haber respondido, depende. Y entonces hablemos de ese depende. Así que esta siguiente pregunta es, ¿cómo decides cuándo usar un límite de error o manejar de una manera diferente? ¿Y cuál es tu proceso? Entonces depende de cuántos, oh, sí, genial, depende, ¿verdad? , cuántos puntos de falla existen dentro del componente que estás tratando de aislar, ¿verdad? ¿Estás haciendo múltiples solicitudes fetch, múltiples cálculos, múltiples cosas que podrían salir mal? Incluso si tienes algo que sale mal en Sentry un poco más arriba, o estás recibiendo muchos errores y que toda una página, esencialmente, está fallando o enviándote cosas, ¿puedes aislar en el seguimiento de pila si está sucediendo en algún lugar más abajo en el árbol y encontrar un término medio razonable para dónde en ese árbol de componentes podrías querer colocar un límite de error.

Y siempre puedes mover eso más abajo o más arriba en ese árbol, pero la primera parte es averiguar dónde estás alcanzando ese umbral de muchos errores siendo poblados y luego dónde podrías mover eso hacia abajo y aislar un poco más y dónde es razonable hablar con tus diseñadores de UI sobre tener una interfaz de usuario de respaldo específica para el límite de error para poder tener una mejor experiencia de usuario porque cada error puede darte una razón diferente para poder poner otra interfaz de usuario allí. Algunos errores pueden querer que optes por contactar al soporte, otros pueden ser solo botones de reintento que reinician la solicitud o reinician el proceso de transmisión de un componente, así que cada interacción es diferente. Y me encanta ese caso de que cada interacción es diferente, porque es, como dijiste, la experiencia del usuario es el objetivo final. Y no es solo atrapar errores para que puedas corregirlos, es para que un usuario sepa que somos conscientes de que algo salió mal y aquí está el camino para remediarlo también. Así que realmente, realmente disfruté eso. Me encanta este porque es bastante interesante. ¿Recomendarías tener un límite de error en la parte superior de los padres más altos para atrapar todos los errores? Creo que enseñaste esto, ¿debería estar en cada nivel de hijo y dónde lo haces? Y también cuando creas un límite de error, ¿qué detalle obtienes sobre dónde está realmente el error? Entonces, ¿deberíamos tener casi límites de error anidados? Definitivamente deberías tener límites de error anidados. No deberías deshacerte de tu límite global en favor de límites de error más específicos. Deberías mantener el global porque estás asumiendo que habrás puesto tus esencialmente o intentado atrapar declaraciones o tus límites de error en todas partes donde podría haber un error concebible. Y los humanos cometen errores al final del día.

Hay una resiliencia en la ingeniería y también hay una resiliencia humana que existe dentro de las formas en que los equipos operan para poder evitar fallos en los productos de software. Así que va mucho más allá del alcance de la ingeniería, también. Así que asegurarte de que también tienes algo a lo que recurrir, que es el peor de los casos, el límite global, y luego rastrear eso a través de tu sistema de seguimiento de errores y luego poder elegir dónde aislar más después. Terminas salvándote a ti mismo en lugar de asumir que pusiste todo en el lugar correcto. Muy bien, Faris. Creo que es hora de almorzar. Muy bien. Muchas gracias. Realmente lo aprecio. Sé que todavía hay algunos de nosotros aquí. ¿Podemos darle a Faris un gran aplauso?