Lecciones aprendidas al solucionar un problema con el carrito de compras

Voy a hablar hoy sobre las lecciones aprendidas de solucionar un problema con el carrito de compras. Así que, la mayoría de nosotros hemos utilizado carritos de compras. Mi nombre es Hussein. Soy un desarrollador de personal en Shopify y he estado trabajando en el desarrollo completo durante unos 10 años ahora. React durante siete. He cometido todos los errores posibles con React. Ahí está mi Twitter, si quieres seguirme. Fanático del Chelsea, desafortunadamente.

¿Por qué esta charla? Así que, hoy estamos hablando mucho sobre React. Muchos de nosotros usamos React. Codificamos en React. Pero la realidad es que siempre trabajas con un ecosistema. Siempre. Entonces, ya sea el navegador en el que estás usando React, las API web, como viste muchas de las escuchas de eventos. Tratas con clientes, si das un paso atrás. Todos tratamos con clientes en nuestro código. Y siempre tenemos un dominio comercial. Específicamente yo, ahora estoy en comercio electrónico. Entonces, todos tratamos con eso. Entonces, trabajas en un ecosistema, lo que agrega complejidad a tu aplicación, lo que a su vez agrega errores a tu aplicación. Y hoy estoy hablando de uno de esos errores que tuve. Así que, solo un breve contexto sobre este error. No fue en Shopify, fue en una startup en la que trabajé antes en 2019. Era una aplicación de mercado de restaurantes, construida en React y Redux, cientos de usuarios, millones en GMV, no tan grande, en comparación con Shopify, por supuesto. Teníamos alrededor de 50 empleados, alrededor de 10 a 15 eran desarrolladores de tecnología. Entonces, hay un camino feliz en la aplicación, que es bastante estándar en el comercio electrónico. Inicias sesión, agregas artículos a tu carrito, proporcionas información de envío, pagas, recibes ese dinero y luego recibes tus artículos. Bastante estándar, ¿verdad? Como esto es lo que hacen la mayoría de los sitios de comercio electrónico. Eso es lo que teníamos. Pero luego tuvimos un problema muy extraño aquí.

Una vez al mes o menos, como una vez al mes o menos, un cliente informaba un error específico, y decían que recibieron menos artículos de los que realmente habían pedido. ¿Qué significa eso? Entonces, la aplicación es un poco diferente ahora. Así que tuve que hacer un poco de trabajo de captura de pantalla. Aquí puedes ver, por ejemplo, cinco cajas de piña, es lo que pidieron. Entonces, un cliente, por ejemplo, diría que en realidad recibieron seis o siete cajas, no cinco. Muy extraño, muy malo. ¿Qué hacemos entonces? En la vida de una startup, hicimos lo mismo que cualquier desarrollador haría. Verificar el pedido en el backend. Asegurarnos de que los números fueran correctos. Revisamos los registros del servidor, para ver si había errores y si los números coincidían. Verificamos los correos electrónicos que enviamos al proveedor, ¿eran el número correcto? Y lo que vimos es que resulta que nuestros números en la database coinciden con todo. Así que le dijimos al cliente, estás equivocado. Nuestros data son correctos, qué lástima. ¿Entiendes a lo que me refiero? Entonces cometiste un error, básicamente. Y por eso es importante hablar sobre nuestras suposiciones cuando tenemos errores. Esto te da un poco de contexto sobre lo que estábamos pensando en ese momento.

En la industria de restaurantes en América del Norte, tenemos este concepto de faltantes. Entonces, cuando haces un pedido en Amazon, pides dos o tres artículos, vas a recibir esos artículos. Nadie te dice después de hacer el pedido, dicen, `oye, qué lástima, solo puedo conseguirte dos cosas de esas tres`. En la industria de restaurantes, es diferente. Llego con cinco cajas de piña que pediste, solo tengo cuatro. Entonces digo, `oye, cliente, solo tenía cuatro esta mañana`. Te daré un crédito. O, ya sabes, a veces el cliente ve cinco cajas y dice, `esta se ve terrible`, no la quiero, así que la devuelven en el acto. Esto es común en la industria. Los faltantes y los artículos faltantes son comunes. La otra cosa es, como, cuando hago un pedido en Amazon, pido, como, dos o tres cosas a la vez. Como, nunca pido, como, sabes, como 50 bolsas de café, aunque quiera. Pero en esta industria, ya sabes, la gente hace pedidos, como, 20 latas de tomate, 50 cabezas de lechuga, 60, lo que sea. Entonces hay muchas oportunidades para cometer errores en esos artículos. Muchas veces nuestros clientes no eran expertos en tecnología, por lo que muchas veces los errores no eran errores reales. Esto es algo a lo que estábamos acostumbrados. Y el error ni siquiera ocurría con tanta frecuencia. Era menos de una vez al mes, y no pudimos reproducirlo en absoluto. Así que para nosotros, ya sabes, esta es la mentalidad con la que abordamos el problema. Y fue muy, como, despectivo. Y esa es la gran razón por la que creo que se mantuvo ahí. Entonces, el problema es que a medida que crecíamos, comenzó a ocurrir con clientes más grandes una vez a la semana ahora. Así que tuvimos que comenzar a investigarlo muy, muy, muy seriamente. Entonces, nuevamente, el enfoque del backend que tomamos, este es el que hicimos antes. Lo intentamos de nuevo. Intentamos lo mismo. No hay nada mal. ¿Entonces qué está pasando? Pero sabemos que es un problema ahora. De acuerdo. Enfoque del frontend.

Revisamos nuestros registros del frontend. En ese momento estábamos utilizando Sentry. Aún así, no encontramos nada. Continuamos reproduciéndolo en diferentes navegadores y dispositivos móviles. Equipo de control de calidad. Aún no pudimos encontrar nada.

Finalmente, revisamos un software de grabación llamado Fullstory. Así que si alguno de ustedes está familiarizado con Fullstory, es una especie de herramienta de análisis que permite grabar las sesiones de usuario. Muy buena aplicación. LogRocket es otro ejemplo que me encanta para los desarrolladores de frontend, en particular. Con esta grabación, pude ver el error ocurriendo en producción. Vi a un cliente tener, como, seis artículos en su carrito de compras, y luego de repente solo había cinco. Lo vi con mis propios ojos, ahora no se puede negar. Pero aún no pudimos reproducirlo. Y si no puedes reproducirlo, ¿cómo lo solucionas?

Ahora tenemos que reproducirlo. Entonces, ¿cómo podría haber ocurrido esto? Este es un ejemplo. Como el carrito de compras, se ve mucho con los botones de más y menos. Lo que sucedió fue que un cliente estaba haciendo clic en más más más más más más. Y cada vez que enviamos la solicitud al servidor y, ya sabes, estábamos debounceando y cosas así. Pero cada vez que presionaban el botón, enviaban una solicitud al servidor. De alguna manera, esta solicitud para cambiar la cantidad simplemente no llegaba al servidor. ¿Verdad? De alguna manera no lo hacía. Así que cuando llegabas a la página de pago, no lo veías. En ese momento, tuve una sospecha porque estaba trabajando mucho con restaurantes en persona. Una cosa que noté es que muchas veces los restaurantes, la persona misma, ponía su pedido en su cocina. Y en la cocina, la conexión Wi-Fi suele ser bastante mala. Así que pensé, tal vez la solicitud no llega porque la conexión Wi-Fi es mala. ¿Sabes? Esta podría ser la razón. Así que hice algo que quizás te resulte familiar.

Haz un throttling, una conexión lenta 3G. Pensé, vamos a intentarlo. Quiero decir, hemos intentado de todo. ¿Y sabes qué? Ese era el problema. ¿Verdad? Así que ahora pudimos reproducirlo. Entonces, ¿cómo lo solucionamos? Bueno, sabíamos que no llegaba a tiempo a la página de pago, por eso sucedía. Así que ves las diferentes cantidades. Entonces, lo que terminamos haciendo, y esto es un ejemplo aquí, es utilizar lo que el cliente ve al momento de pagar, o al momento del carrito de compras, como la fuente de verdad, no el servidor. Lo que ve el cliente. Porque eso es lo único que importaba. Así que si hay una discrepancia entre el carrito de compras y el pago, ¿verdad? Como si hay seis en el carrito de compras y luego cinco en el pago. No nos importa lo que diga el servidor. Es lo que el cliente vio. Así que lo cambiamos de vuelta. Y eso es lo que hicimos. Porque estas son dos páginas diferentes. De esa manera, la versión que ve el cliente es siempre lo que obtienen. Y nunca volvimos a tener ese problema.

Para resumir, las lecciones aprendidas. La fuente de verdad no es el servidor. No siempre es el servidor. A veces sí lo es. Comienza asumiendo que el error es culpa tuya. Hay un dicho que se llama `select no está roto`, lo que básicamente significa, como, sabes, la database en sí no está rota. Tú rompiste algo. Tú causaste el problema. Acércate a ello desde esa mentalidad. Las grabaciones de pantalla son muy útiles para los desarrolladores de frontend. Si puedes hacerlo, asegúrate de bloquear cualquier información personal. Muchos lo hacen automáticamente, pero a veces, dependiendo de tu industria, puede ser más estricto.

Y no pruebes tu aplicación en las mejores condiciones. Lo hacemos mucho como desarrolladores. Estás como, en mi, ya sabes, Macbook, 64 gigas de RAM y la mejor conexión a Internet del mundo. Era perfecto. Entonces, ¿cuál es el problema, verdad? Entonces, ¿por qué importa esto?

Suposiciones incorrectas pueden y te costarán dinero. Personalmente, le costé a la empresa unos miles de dólares. No es gran cosa, ¿verdad? Ahora, en Shopify, nuestra escala es muy masiva. $3.5 millones de dólares en ventas por minuto en el Viernes Negro. Así que no puedo hacer eso. Pero si lo hago en Shopify, es una responsabilidad financiera mucho mayor. Así que tomo estas lecciones como una forma de no repetirlas en Shopify. Y transmito este conocimiento a otros desarrolladores para asegurarme de que abordemos los errores con una mentalidad similar a la que tuvimos después de resolverlo.

Eso es todo en mi charla. Muchas gracias, y espero que hayas aprendido algo.