Todo lo que necesitas es un contrato...

Rate this content
Bookmark

¿Cuántas veces has tenido que esperar a que tu equipo de backend termine de construir la API para poder comenzar tus tareas? ¿Y si todo lo que necesitaras para mover esa tarea a en progreso fuera el contrato de la API? ¿Y si hubiera una biblioteca que hiciera esto para las API de REST y GraphQL y, al mismo tiempo, llevara tus pruebas al siguiente nivel? Únete a mí y prepárate para mejorar tu experiencia de desarrollo mientras aprendes todas las experiencias ganadas en batalla de usar una de mis bibliotecas favoritas: Mock Service Worker.

29 min
20 Oct, 2023

AI Generated Video Summary

El orador discute los desafíos del estado del servidor y el mantenimiento de pruebas, y cómo encontraron soluciones usando React Query y Mock Service Worker. Enfatizan los beneficios de definir contratos para un desarrollo más rápido y la reducción del estrés. El orador también destaca las ventajas de usar Mock Service Worker sobre los servidores simulados y explica cómo permite una fácil personalización y anulaciones de pruebas. Mencionan el próximo lanzamiento de la V2 de MS-Double y animan al público a mantenerse actualizado.

1. Introducción y molestias como desarrollador

Short description:

En esta parte, el orador expresa gratitud hacia la audiencia y reconoce el arduo trabajo de los organizadores de la conferencia. También mencionan tres cosas que les molestan como desarrollador: código inmantenible, pruebas afectadas por la inmantenibilidad y tareas tardías en los sprints. El orador promete compartir una historia sobre cómo ellos y su equipo solucionaron estos problemas.

Bueno, permítanme aclarar la sala. No va a haber contrato testing aquí. Esta es una broma de la que estábamos hablando antes de subir al escenario. Además, me voy a mover mucho, así que estoy tratando de averiguar el lugar. Eso está bien, si no me ciega la luz.

Antes que nada, React Advance, muchas gracias por tenerme aquí. Es un placer. Caminaré por ese lugar porque aparentemente la cámara no me captará en el otro, así que intentaré no moverme mucho.

Solo quería comenzar esta charla con, me gustaría dar un aplauso alegre, porque hubo mucho trabajo duro para preparar esta conferencia para todos de Git nation, todos del equipo técnico. No sé si están al tanto, pero cuando comenzamos hoy, tuvimos algunos problemas para conectar todo, y ahora todo ya está funcionando hasta ahora, ¿puedo obtener un todos los que están trabajando en esto? Vale. Muchas gracias.

Entonces, comencemos esto porque ya pasó un minuto, y realmente hay tres cosas que me molestan como desarrollador. La primera es cuando tienes un código inmantenible. Conoces la sensación. Tu código no es realmente tan bueno a veces. Cuanto más agregas, peor se pone. Es difícil. Sí, es duro. Y luego la segunda cosa que realmente me molesta, es cuando esa inmantenibilidad encuentra una forma de meterse en tus pruebas. Ahora no es malo que tu código no sea bueno, tus pruebas tampoco son buenas. Probablemente no estás durmiendo tan bien por la noche porque sabes lo que se siente tener pruebas inestables. Y la tercera cosa que realmente me molesta, y prometo no empezar una diatriba aquí, es cuando tienes una tarea que llega tarde al sprint. Sé que algunos de ustedes se relacionan con la sensación. Imaginemos que tenemos un equipo donde dos partes están trabajando en una tarea y la primera parte toma el 98% del tiempo, y una vez que la tarea llega a ti, tienes el 2% del tiempo. Así que obviamente tu gerente de producto va a esperar que entregues eso ayer. Y este es un sentimiento del que podría empezar a hablar aquí y no pararía.

Así que continuemos, porque tengo una historia sobre cómo yo y mi equipo solucionamos estos problemas hace un par de años. Así que comencemos desde el principio sobre cómo acabamos de solucionar el primer problema. Yo y mi equipo acabamos de derrotar al monstruo del código inmantenible. Porque esto había sido algo que estaba rondando, nos amenazaba, era duro.

2. Desafíos del Estado del Servidor y Problemas de Pruebas

Short description:

El orador discute los desafíos del estado del servidor y cómo tuvieron que implementar varias funcionalidades por sí mismos. Luego descubrieron React Query, que resolvió sus problemas de estado del servidor. Sin embargo, surgió un nuevo desafío con pruebas inmantenibles y defectuosas. El orador finalmente encontró una solución y se presenta como Daniel Alfonso, un defensor del desarrollador en OLX.

¿Y cuál era la razón? Bueno, la razón era el estado del servidor. No sé si están al tanto de lo que es el estado del servidor. Normalmente es el estado que existe en algún lugar de Internet como externo a su aplicación. Y tiene un montón de desafíos. Caché, deduplicación de solicitudes, data prebúsqueda. Hay un mantenedor aquí de React Query del que puedes hablar de muchos de estos desafíos y probablemente puedes entender cuánto dolor es entender y tener que implementar esto a mano y puedo decirles que mi equipo y yo, no teníamos React Query en aquel entonces o al principio, no lo teníamos. Así que estábamos implementando todas estas cosas por nosotros mismos y cuanto más código teníamos, peor se volvía el monstruo del código inmantenible. Así que empezamos a pensar, ¿por qué estamos implementando esto nosotros mismos de nuevo? ¿Qué estamos tratando de demostrar al ir en esta dirección? Y bueno, pasaron un par de meses y fue cuando un par de, bueno, estos meses pasaron un compañero de trabajo, como el Rey Arturo en la película de la Espada y la Piedra. Creo que así se dice en inglés. Lo siento, hablante no nativo de inglés aquí. Un compañero de trabajo se acercó a la piedra y sacó una consulta de 10 pilas. Así que aparentemente, esta nueva cosa, React Query, acababa de aparecer y era la solución para nuestros problemas. Y la consulta de 10 pilas trajo armonía a nuestro código porque ahora todos los problemas e inconvenientes que teníamos con el estado del servidor se resolvieron y no tuvimos que preocuparnos por implementar eso por un tiempo.

Ahora, una nueva amenaza se cernía en las sombras. Verás, esa inmantenibilidad encontró una forma de salir de nuestro código y entrar en nuestras pruebas. Ahora, no sé si recuerdan esta imagen que les mostré hace un par de minutos, pero esto es Hydra. Y ya saben lo que dicen de las Hidras. Corta una cabeza, dos más toman su lugar. Y esto es más o menos lo que empezaba a suceder con nosotros porque ahora nuestras pruebas no solo eran inmantenibles. Eran defectuosas. Eran complejas. No podía dormir por la noche porque no confiaba en lo que estaba haciendo y ahora te preguntas, ¿cuál es la relación? ¿Qué vamos a ver? Bueno, ahora, hace un par de años puedo decirles que mi equipo y yo logramos solucionar estos problemas. Y la parte divertida fue que todo lo que necesitábamos era un contrato. Así que esta es la parte donde realmente empiezo la charla.

Permítanme presentarme rápidamente. Soy Daniel Alfonso. Trabajo como defensor del desarrollador en OLX. Soy instructor de AGIT y embajador de Out-there y puedes encontrarme, voy a decir Twitter debido a la encuesta anterior en Twitter y prácticamente en cualquier red social al final Así que Daniel GC Alfonso. También algo sobre mí, recientemente publiqué un libro llamado State Management con React Query. Gracias.

3. React Query y Problemas de Pruebas

Short description:

El orador expresa su gratitud hacia la audiencia y agradece a Joshua, Mateus y Tejas por sus comentarios. Mencionan que la charla será un estudio de caso, compartiendo los problemas que enfrentaron el orador y su equipo, y cómo los solucionaron. El orador reconoce que la implementación de software no siempre tiene todas las respuestas y que puede haber preguntas sobre por qué se tomaron ciertas decisiones. Luego mencionan un problema con la inmantenibilidad en sus pruebas, específicamente pruebas unitarias e integración.

También me encantaría hablar con cada uno de ustedes sobre React Query porque verán en esta charla que es algo que realmente me encanta. Otra cosa, estoy totalmente a favor de compartir amor. Y quiero agradecer a Joshua, Mateus y Tejas porque me dieron comentarios sobre versiones anteriores de esta charla y esto me permitió mejorarla y tener la charla que tenemos hoy. Así que por favor estén atentos para esa charla. ¿Puedo recibir un aplauso para ellos? Solo allí compartiendo el amor.

Vale. Realmente rápido porque pasaron cinco minutos. Esta charla va a ser un estudio de caso. Les voy a mostrar algunas de las cosas. Ya les mostré algunos de los problemas que mi equipo y yo tuvimos y cómo los solucionamos. Obviamente, mientras estoy presentando, algunos de ustedes podrían estar pensando, oh, yo no lo habría hecho de esta manera o probablemente lo habría hecho de esta manera. Bueno, eso es lo que pasa con la implementación y la creación de software hoy en día. No siempre tienes todas las respuestas. Afortunadamente ahora teníamos algunas de ellas. Pero cuando empezamos a hacer esto, no era el mejor escenario. Entonces, si tienes la pregunta de por qué no hiciste esto o por qué no hiciste eso? Bueno, probablemente no lo pensamos. O si lo hicimos, no hay razón para entender por qué.

Así que solo para recapitular rápidamente lo que estaba mencionando. Ahora teníamos un problema con la inmantenibilidad en nuestras pruebas. Eso no estaba funcionando bien. Y cuando digo prueba, en este escenario, estoy hablando de pruebas unitarias e integración. Y eso... Ups. Vale. No voy a moverme de nuevo porque parece que fue cuando me moví. Eso era difícil. Porque no sé si están al tanto de cuáles son los desafíos en pruebas de interacciones con el estado del servidor. Pero vamos a recapitular rápidamente. Vale.

4. Obtención de Datos y Simulación

Short description:

El orador discute el proceso de descubrir el escenario de las pruebas y la necesidad de evitar ir a internet para obtener datos con el fin de prevenir pruebas inestables. Explican que comenzaron con simulaciones manuales usando Jest, pero a medida que se agregaba más código, se volvió difícil de mantener. Luego decidieron usar el adaptador de simulación de Axios para manejar la simulación de datos.

Vamos a averiguar si algo está pasando. ¿Tenemos señal allí atrás? Eso es lo que voy a hacer. Vale. Está apareciendo de nuevo. Entonces... Veamos. Vale. ¡Woo! Se ha hecho. Entonces... Normalmente lo que sucede cuando estamos haciendo interacciones y haciendo solicitudes de obtención de data, tenemos el navegador y el navegador envía una solicitud a internet y el internet responde con los data. Eso es más o menos lo que sucede normalmente. Así que ahora vamos a... Y voy a seguir hablando mientras intento averiguarlo porque esto está preparado. Ahora hay otro escenario. Así que lo que deberías estar viendo aquí es una imagen en las pruebas. Así que ahora en el escenario tenemos pruebas. Y en nuestras pruebas, no queremos que esto suceda. No queremos ir realmente a internet para obtener los data porque eso significaría que probablemente obtendríamos diferentes data cada vez. Eso significaría que tendríamos pruebas inestables. Y eso probablemente significaría, una vez más, que no dormirías bien por la noche.

Así que mi equipo y yo tuvimos que descubrir las mejores soluciones para lidiar con la simulación de data que provienen del estado del servidor. Así que empezamos con simulaciones manuales al principio. Estábamos usando Jest, Jest FN, un montón de cosas de simulación manual. Y funcionó por un tiempo. Pero cuanto más código añadíamos, peor se ponía. Porque ahora teníamos que mantener un montón de estas cosas. Y luego llegamos al otro escenario. OK, vamos a añadir el adaptador de simulación de Axios. Porque estábamos usando Axios como el cliente.

5. Desafíos con Simulaciones Manuales y Axios

Short description:

Estábamos manteniendo simulaciones manuales y escenarios de adaptador simulado de Axios. Sin embargo, cada vez que hacíamos cambios, algo se rompía. Queríamos una solución ideal que interceptara todas las solicitudes en un solo lugar, sin ninguna configuración. Fue entonces cuando descubrimos el trabajador de servicio simulado, una biblioteca de simulación de API que utiliza trabajadores de servicio para interceptar solicitudes reales.

Así que ahora estábamos manteniendo simulaciones manuales. Y también estábamos manteniendo escenarios de adaptador simulado de Axios. Y luego puedo jurar, en cierto punto, incluso había algún tipo de magia. Alguna brujería. No tengo idea de lo que ese código todavía hace hasta el día de hoy. Solo sé algo. Cada vez que tenía que actualizar las simulaciones manuales, las simulaciones manuales romperían el adaptador simulado de Axios. Cada vez que tenía que romper, usar, actualizar el adaptador simulado de Axios, esa cosa rompería la magia. Y lo adivinaste. Cada vez que cambiábamos cosas en la magia, rompía la otra cosa. Así que este era el ambiente al escribir pruebas cada vez que teníamos que hacerlas.

Era estresante. No estaba funcionando para nosotros. Queríamos una solución ideal. Queríamos algo que funcionara mejor para nosotros. Y nos permitiera deshacernos de todas las cosas que teníamos antes. Entonces, en un escenario ideal, ¿qué tal si pudiéramos tener una solución que interceptara todas las solicitudes? ¿Un lugar local? ¿No tendríamos que hacer ninguna configuración en el entorno de testing? Y al usar un contrato que usamos para especificar la API y los data que esperábamos para ello, al usar esa cosa, podríamos probar nuestra aplicación y no preocuparnos. Y este sería el escenario ideal. Y realmente, eso es lo que tenemos. Pero no sabíamos qué solución nos convendría. Y fue entonces cuando llegamos a conocer esta cosa llamada trabajador de servicio simulado.

Entonces, el trabajador de servicio simulado, para aquellos de ustedes que no lo saben, es una biblioteca de simulación de API que utiliza trabajadores de servicio, una API de ServiceWorker, para interceptar solicitudes reales. Así que sé lo que algunos de ustedes podrían estar pensando. Pero espera, estamos hablando de testing, así que probablemente sea en un entorno antiguo. Los trabajadores de servicio solo funcionan en el navegador. ¿De qué estás hablando? Entraremos en ello un poco. Pero repasemos cómo funciona el trabajador de servicio simulado un poco antes de continuar la historia. Así que ya vimos esta cosa. Normalmente, cada vez que necesitamos algunos data, el navegador hace una solicitud, y el Internet nos devuelve los data. Ahora, con el trabajador de servicio simulado, hay algo nuevo.

6. Mock Service Worker y Establecimiento de Contratos

Short description:

Existe un ServiceWorker que intercepta las solicitudes del navegador y utiliza un contrato definido para decidir qué datos devolver. Si no se especifica ningún contrato, el navegador realiza una solicitud normal a Internet. Mock Service Worker tiene manejadores de solicitudes y resolutores de respuestas para especificar el contrato, la API y la ruta. Funciona tanto con escenarios REST como GraphQL, permitiéndote devolver datos específicos para cada ruta. Esto te permite establecer tu propio contrato con Mock Service Worker.

Hay un tercer usuario en este escenario. Así que hay un ServiceWorker justo en medio. Así que cada vez que hay una solicitud del navegador, el ServiceWorker va a interceptar esa solicitud. Va a verificar el contrato que has definido dentro de él, y utilizando ese contrato, decidirá qué data devolver. Así que, en resumen, puedes tener una forma de devolver data simulada desde allí.

Ahora, algunos de ustedes podrían estar pensando, está bien, pero ¿qué sucede en el escenario en que no tenemos un contrato especificado? Bueno, en este caso, simplemente vamos a Internet, dejamos que el navegador haga la solicitud normal que haría, y luego obtenemos los data de vuelta, devolviéndolos al navegador. Y eso es básicamente la esencia de cómo funciona el servicio de simulación.

Ahora, para entender un poco más cómo funciona esto, solo voy a mostrarles algunos fundamentos de esto. Así que el primero son los manejadores de solicitudes, y el segundo son los resolutores de respuestas. Los manejadores de solicitudes son responsables de hacer algo, que es, bueno, básicamente especificar el contrato, la API y la ruta a la que vas a acceder. Así que permíteme abrir esto aquí. Oh, no quiero dibujar. Esto pasó la última vez. Así que intentemos volver aquí. Esto es lo que sucede cuando intentas cosas nuevas en el escenario. Veamos si puedo deshacerme de él. Inténtalo de nuevo. Todavía está allí, pero ignoremoslo por un momento porque no parece que pueda quitarlo. Así que en este escenario, lo que está sucediendo es que estamos importando la API REST. Así que básicamente estamos diciendo, está bien, vamos a tener una API REST, y cada vez que obtienes una solicitud GET, juego de palabras no intencionado, supongo, a la ruta, Daniel GCFomes, vas a devolver un resolutor de respuesta. Y eso es básicamente la esencia. Así que estás definiendo básicamente qué protocolo estás usando, qué tipo de escenario vas a manejar, en qué ruta vas a acceder. Pero la parte divertida de Mock Service Worker es que también funciona con GraphQL. Así que tienes REST. Si tienes un escenario GraphQL, puedes importar GraphQL, y dices, cada vez que hay una consulta para obtener usuarios, devuelves este resolutor de respuesta. Así que todo esto que tenemos aquí, es un manejador de solicitudes. Lo que tenemos aquí es un resolutor de respuesta. Desde el escenario del resolutor de respuesta, y déjame tomar esta parte de aquí, el escenario del resolutor de respuesta lo que haces básicamente allí es especificar los data que vas a devolver cada vez que se accede a esa ruta. Así que cada vez que tenemos una solicitud GET a Neo4j CFoS, en este caso, devolviendo una respuesta, que dentro va a devolver el objeto JSON, en este caso, con el nombre John, y la edad 38. Y eso es básicamente la esencia de cómo puedes establecer tu propio contrato con Mock Service Worker.

7. Configuración de Mock Service Worker y Manejo de Solicitudes

Short description:

En las pruebas, Mock Service Worker te permite configurar un service worker o un servidor para devolver datos basados en contratos definidos. Al configurar un worker con un manejador de solicitudes, puedes interceptar solicitudes GET y devolver datos específicos. Si una ruta no está definida, el service worker permitirá que la solicitud pase a Internet. Este enfoque ayudó al orador a eliminar el código insostenible al eliminar todos los mocks innecesarios.

Ahora volvemos a la parte donde dije, está bien, esto funciona en la prueba. Porque mientras los Service Workers se ejecutan en el navegador, Mock Service Worker también tiene un paquete de interceptación de nodos que te permite ejecutar en entornos de nodos. Y así es como funciona esto en las pruebas.

Entonces, si configuras un worker, puedes usar una API de configuración de worker para decir, está bien, quiero configurar este service worker que va a usar este contrato que definí, y cuando el navegador lo detecte, va a devolver los data. En otro escenario, puedes decir, ahora en otro entorno, quiero configurar un servidor, y este va a escuchar para mi prueba. Entonces, cuando mi prueba dispara una solicitud, esa cosa va a devolver los data. Entonces, desde un ejemplo que tenemos aquí, estamos configurando un worker, por lo que estamos configurando un service worker con el manejador de solicitudes que acabamos de ver. Cada vez que hay una solicitud GET a Daniel J. C. Afons, va a devolver el primer nombre Daniel, apellido Afons. Y luego lo que hacemos, iniciamos el worker. Y esto es prácticamente toda la configuración que necesitas hacer en el navegador para que funcione el mock service worker.

Bueno, eso fue divertido. Vale. Entonces, volvamos a presentar un escenario una vez más. Hay una solicitud GET a Daniel J. C. Afons. El service worker va a interceptarlo. Entonces, lo que va a hacer es preguntarse, ¿tengo un manejador de solicitudes definido? Y si es así, va a devolver los data. Y esto es prácticamente lo que vimos anteriormente. En el escenario en que intenta llegar a una ruta que no tenemos definida, como random, todavía se preguntará, oh, no tengo algo. Entonces, vamos a Internet, dejamos pasar la solicitud y la enviamos de vuelta. Y esto es prácticamente lo que nos ayudó a salvar nuestras pruebas. Porque ahora solo había tres pasos que teníamos que seguir para deshacernos de toda esa insostenibilidad que teníamos. El primero es eliminar todos los MOCs. Eliminar todos los MOCs manuales, todos los adaptadores de mock de acceso. Eliminar toda esa magia, todo eso. Fue la mejor parte. Me encanta eliminar código.

8. Mock Service Worker y Tareas Tardías en el Sprint

Short description:

Esas pobres solicitudes son increíbles. Observamos los contratos de las APIs que estábamos utilizando, definimos manejadores de solicitudes e iniciamos nuestro servidor antes de las pruebas. Nuestras pruebas unitarias e integradas ya no eran inestables porque había una única fuente de verdad para los datos. En otro escenario, cuando las tareas llegaban tarde durante el sprint, el mock service worker solucionó el problema. Este software salvó a nuestro equipo de señalar con el dedo y luchar por entregar más rápido. Proporcionó una solución cuando otros procesos fallaron.

Esas pobres solicitudes son increíbles. Simplemente vas allí, como, oh, se ha eliminado tanto código. Es tan bueno.

Luego miramos los contratos, los contratos de las APIs que estábamos utilizando, así que simplemente fuimos allí, definimos todos los manejadores de solicitudes para nuestra API e iniciamos nuestro servidor antes de nuestras pruebas. Y así de simple, nuestras pruebas unitarias e integradas estaban funcionando. No eran inestables porque ahora solo había una única fuente de verdad para los data que estábamos obteniendo, y esto fue prácticamente yo y mi equipo después porque ahora podíamos descansar un poco y relajarnos porque ahora podíamos dormir por la noche. Así que teníamos que confiar en las pruebas que estábamos construyendo.

Ahora, recuerda, había un tercer escenario, que es la tarea que llega tarde durante el sprint, y el mock service worker también solucionó eso curiosamente, así que repasemos lo que estaba pasando en mi equipo. Normalmente, teníamos sprints de dos semanas, y mi equipo estaba compuesto por desarrolladores backend y por desarrolladores frontend, y lo que solía suceder cuando intentábamos construir una nueva implementar las respectivas pantallas para eso era que el backend se tomaba todo este tiempo trabajando en una tarea. Y no estoy criticando aquí. Construir una API es difícil. Hay tantas cosas que tienes que construir. No podían acelerarlo lo suficiente. Pero esto también significaba que durante el tiempo que estaban haciendo esto, teníamos que hacer algo más. Estábamos construyendo algunas tareas más pequeñas no relacionadas, algunas tareas más pequeñas, y algunas tareas más pequeñas hasta que solo quedaba esta pequeña cosa aquí. Y si recuerdas mi introducción, este era el tiempo que nos quedaba para salvar el sprint. Así que era ese 2%. Y esto, como dije, causó la lucha. Estábamos señalando con el dedo. Estábamos como, necesitamos entregar esto más rápido. El PM está encima de nosotros. Queremos enviar esto más rápido a los usuarios. Lo entiendo. Queremos hacer nuestro trabajo como desarrolladores. Es nuestro principal objetivo. Pero cuando tienes un ambiente como este, es un poco estresante. Y ahora podemos empezar a hablar de estas funciones de equipos y procesos ágiles y lo que sea. Probablemente podríamos haberlo hecho mejor. Pero este fue un escenario en el que este software solucionó nuestro problema. ¿Por qué? Alguien dijo, hey, mira.

9. Beneficios de Definir un Contrato

Short description:

Si definimos un contrato con el equipo, podemos trabajar en tareas simultáneamente con el equipo de backend. Esto nos permite enviar más rápido y reducir el estrés. Solo necesitamos seguir tres pasos: definir el contrato, crear manejadores de solicitudes y resolventes, y iniciar el service worker.

Mock service worker se ejecuta en el navegador, ¿verdad? Así es. Genial. Entonces, ¿qué pasa si definimos un contrato mientras estamos comenzando el sprint? Y alguien dijo, está bien. Pero, ¿por qué? ¿Cuál es la razón de eso? Porque escúchame. Si definimos un contrato con todo el equipo juntos, podemos entrar en mock service worker y definir los resolventes de solicitudes. Podríamos especificar el contrato. Sí. Y luego podemos iniciar esto en el navegador. Sí. Te estoy siguiendo. Y entonces prácticamente vamos a tener una API que está simulada para data. Mientras la API aún no está lista. Entonces, esto significa que mientras el backend aún está trabajando en la tarea, podemos trabajar en la tarea al mismo tiempo porque ahora hemos definido el contrato y luego trabajamos contra la API simulada. Una vez que terminamos, eso ya está en desarrollo o en ambiente de QA, lo encendemos contra la API correcta y la probamos. Y funcionó, solucionó ese problema porque ahora estábamos emparejando trabajo, estábamos enviando más rápido y ya no estábamos estresados. Luego tuvimos tiempo para seguir trabajando en las tareas más pequeñas, pero ahora no estábamos estresados al final del sprint para entregar cosas para ayer. Hizo todo mucho mejor para nosotros. Y una vez más, solo tuvimos tres pasos para salvar nuestro sprint. Definir el contrato al principio. En segundo lugar, crear todos los manejadores de solicitudes y resolventes de respuesta. Y finalmente, iniciar el service worker. Estos tres pasos que funcionaron en el testing también funcionaron en el escenario ahora para solucionar esta disfunción que yo y mi equipo teníamos. Nos dejó a todos celebrando al final porque se sintió bien.

10. Ingeniería de Código Abierto y Hazlo Tú Mismo

Short description:

Los ingenieros liderados por organizaciones entregan cosas asombrosas para nuestros usuarios. Antes de agregar al modo de sobreingeniería de Hazlo Tú Mismo, considera que alguien más puede haber publicado ya un paquete de código abierto para resolver tu problema. Estas herramientas me ahorraron tiempo y preocupaciones, y confío en ellas en cada proyecto que construyo.

Ahora no teníamos que discutir al final de cada sprint. Al llegar al final de mi charla, quiero compartir algo de amor. Artem, el creador de mock service worker, tiene esta gran serie de publicaciones en su blog sobre mock service worker. Donde va desde toda la concepción de lo que llevó a su creación, todos los desafíos, y recientemente anunció un curso sobre eso. Estoy súper emocionado de ver cómo se está desarrollando esa cosa. Solo compartiendo algo de amor, sigan a Artem porque mock service worker es genial.

En los últimos dos minutos de mi charla, solo quiero llevar algo a casa desde aquí y recordarte algo, que es, los ingenieros liderados por organizaciones entregan cosas asombrosas para nuestros usuarios. Nuestros usuarios quieren estas cosas para ayer. Las quieren rápido y las quieren funcionando. Siento que muy a menudo, y mi equipo y yo sufrimos mucho por eso, estábamos quedándonos atrapados en este ciclo de complejidad. Nos estábamos quedando atrapados en lo que se llama ingeniería de soluciones versus resolución de problemas. Nos estábamos quedando atrapados en el Hazlo Tú Mismo, la sobreingeniería. Estábamos atrapados en todas estas pruebas porque dijimos, oh, vamos a implementar todas estas cosas por nosotros mismos. Lo que no nos dimos cuenta allí es que estábamos perdiendo tiempo. Estábamos perdiendo tiempo que podríamos estar entregando cosas más rápido a nuestros usuarios. Si estamos perdiendo tiempo, estamos desperdiciando el dinero de nuestra empresa. Entonces, lo que estoy predicando aquí y me gustaría que pensaras es, antes de que te sumes al modo de sobreingeniería de Hazlo Tú Mismo, piensa en algo. Probablemente alguien más en el mundo ya tuvo el mismo problema que tú, y probablemente ya se adelantaron y publicaron un paquete de código abierto. Y probablemente ese paquete está mantenido, está probado, es seguro, y tiene incluso más escenarios que las cosas que consideras hoy en día. Así que por favor considera eso. Porque tenemos tantos grandes proyectos de código abierto, tenemos tantos mantenedores de código abierto aquí con nosotros hoy. Así que echa un vistazo a esos proyectos antes de entrar en el modo Hazlo Tú Mismo. Entonces, si hubiera conocido 10 stack query antes, probablemente, como dije, habría ahorrado mucho más dinero a mi empresa y a mi equipo. Si hubiera conocido mock service worker antes, habría ahorrado incluso más dinero. Habría ahorrado horas de sueño, que, si te sientes como yo y tienes muchos insomnios, empeora cuando tus pruebas no están funcionando. Así que sí, estas herramientas salvaron un poco la forma en que estaba construyendo software. Y son mis favoritas. Prácticamente en cada proyecto que construyo hoy en día, las instalo, porque, bueno, me ahorraron mucho tiempo, me ahorraron muchas preocupaciones. Y realmente confío en todo lo que necesito. Y eso fue un dato curioso en todas estas cosas.

QnA

Cambios de Contrato y Entrega de Sprint

Short description:

El dato curioso que solucionó todos los problemas que mi equipo y yo teníamos al final, fue que todo lo que necesitábamos era un contrato. Vamos a saltar a la audiencia. Veamos qué tienen que decir las personas. ¿Qué pasa si el contrato cambia durante el sprint? Esto me pasó la semana pasada. Por lo general, los cambios de contrato que ocurren no van a ser tantos, esperemos, a menos que vayan y reescriban todo. Pero habrá algunos escenarios en los que tengas algunos cambios de contrato más pequeños. Y cuando hay cambios de contrato más pequeños, probablemente sea más fácil volver atrás, verificar ese escenario específico que para todo el contrato. Y al final del día, todavía tienes que repasar el trabajo que hiciste, pero no va a ser todo al final del sprint y tener que entregar todo al mismo tiempo. Así que el pedazo con el que vas a tener que trabajar va a ser un poco menos en comparación con todo lo que pasaste antes. Nueve de cada diez veces, el contrato no cambiará.

El dato curioso que solucionó todos los problemas que mi equipo y yo teníamos al final, fue que todo lo que necesitábamos era un contrato.

Entonces, muchas gracias, React Advanced. Estaré ahora para la sesión de preguntas y respuestas, ¿verdad? Tenía preparado un chiste. Tenías un chiste. Sí, y se me olvidó completamente. Se me olvidó completamente. Así que probablemente incluso si lo encuentro, ya no es gracioso. Pero gran charla. Gracias por compartir.

Vamos a saltar a la audiencia. Veamos qué tienen que decir las personas. Sí. Lo siento, también los estoy mirando allí. Así que hay algunos chistes allí, pero puedo leerlos aquí, pero recibí un mensaje de nuestras esposas. Oh, ¿todo está bien? Bien. Solo bromeaba. Solo bromeaba.

¿Qué pasa si el contrato cambia durante el sprint? Esto me pasó la semana pasada. Pregunta de Anónimo. Gracias, Anónimo. Esta es probablemente la pregunta más respondida cada vez que doy esta charla. Y es gracioso, porque eso también me pasó a mí. Pero diría que por lo general los cambios de contrato que ocurren no van a ser tantos, esperemos, a menos que vayan y reescriban todo. Pero habrá algunos escenarios en los que tengas algunos cambios de contrato más pequeños. Y cuando hay cambios de contrato más pequeños, probablemente sea más fácil volver atrás, verificar ese escenario específico que para todo el contrato. Y al final del día, todavía tienes que repasar el trabajo que hiciste, pero no va a ser todo al final del sprint y tener que entregar todo al mismo tiempo. Así que el pedazo con el que vas a tener que trabajar va a ser un poco menos comparado con todo lo que pasaste antes. No sé si eso responde a la pregunta, espero que sí, pero esa es más o menos la pregunta más común que recibo cada vez que hago esta presentación. Sí. Nueve de cada diez veces, el contrato no cambiará.

Personalización de Escenarios y Mantenimiento de Contratos

Short description:

Puedes definir todo el contrato y personalizar escenarios específicos para pruebas específicas con el trabajador de servicio simulado. Elimina la necesidad de una configuración compleja como los servidores simulados y te permite anular fácilmente los resolutores de respuesta para pruebas específicas. En cuanto al mantenimiento del contrato, puedes agregar o eliminar la mayor parte de él y hacer pequeños cambios manualmente. La importación desde Swagger aún no está soportada, pero sería una valiosa adición.

Entonces ahorrarás tiempo y esa una de cada 10 veces, bueno... Sí, gran resumen. Sí, ese es el resumen. Sí.

Otra pregunta de nuestro activo cuestionador, anónimo, ¿cómo cambias la respuesta simulada por prueba para que puedas probar diferentes escenarios en una especificación de prueba? Sí. Esa es una de las partes que tuve que recortar porque usualmente al final de esta charla tengo una pequeña demostración, pero bueno, tenemos 20 minutos. Básicamente puedes definir todo el contrato, tiene respuestas, es solicitud respuesta, resolutores y respuesta. Olvidé cómo hablar, lo siento. Como Sara estaba diciendo hace un par de minutos, el inglés no es mi lengua materna no mi inglés nativo, lo siento, mi cerebro acaba de ir a responder a esto. Básicamente puedes definir todo el contrato, pero luego para cada prueba específica puedes seguir adelante, puedes obtener acceso a la instancia del servidor que estás utilizando, o en este caso al, sí, a la instancia del servidor y puedes decir, vale, para esta prueba específica, quiero que uses este resolutor de respuesta. Y puedes decir sólo para esta prueba específica, lo anulas. Y luego todo después de eso, se restablece al valor por defecto. Así que básicamente puedes personalizar escenarios específicos para pruebas específicas, lo que lo hace un poco más simple que, por ejemplo, configurar cosas como un servidor simulado, si has tenido experiencias de configurar servidores simulados, eso es un gran dolor, especialmente en escenarios como este, porque entonces tienes que seguir adelante y decir, oh, vale, para este escenario específico, cuando recibo este parámetro, quiero que lances un error. Con el trabajador de servicio simulado, no necesitas simplemente importar el servidor que estás utilizando para escuchar todo y decir, vale, para esta prueba específica, estoy haciendo esto y simplemente funciona de inmediato. No es mucha la configuración que necesitas hacer para eso. Genial. Gracias.

Siguiente pregunta de Anónimo, ¿cómo mantienes el contrato? ¿El trabajador de servicio simulado importa Swagger, por ejemplo? Oh, esa es una gran pregunta. He estado tratando de ver si eso existe por un tiempo. Creo que aún no existe. Así que hay una oportunidad, si alguno de ustedes quiere probarlo. He estado queriendo hacerlo, pero aún no he tenido tiempo. Así que usualmente lo que he estado haciendo es, el contrato que tenía en mi equipo, usualmente cuando construyes APIs, o añades la mayor parte de él, o puedes eliminar. Pero es fácil de eliminar. Es sólo ir allí y borrar. Y cuando hay pequeños cambios, puedes ir allí en un escenario específico y simplemente ajustarlo manualmente. Obviamente sería ideal si tuviéramos algo que pudiera mejorar importar desde Swagger, como este ejemplo aquí. Sería realmente bueno, pero hasta donde sé, aún no existe. Puedo preguntar a Artem, y trataré de volver a esto en Twitter o en LinkedIn, pero sería realmente, realmente bueno. Genial.

Ventajas de Usar el Trabajador de Servicio Simulado (MSW)

Short description:

El orador discute las ventajas de usar el Trabajador de Servicio Simulado (MSW) en lugar de un servidor simulado. Destacan que MSW requiere menos configuración y mantenimiento, y permite una fácil personalización de escenarios. También responden a una pregunta sobre cómo evitar la re-implementación del backend en MSW, explicando que las respuestas dinámicas pueden ser anuladas para pruebas específicas, evitando la necesidad de configuraciones complejas.

Correcto. Estaré pendiente de tu Twitter entonces. La siguiente persona está utilizando una API simulada basada en express, y quiere saber si hay alguna ventaja en usar o cambiar a MSW, Ordenador de Servidor Simulado. Estaba en camino aquí. Estaba charlando con algunos de los otros oradores y estaba diciendo, eliminé una diapositiva sobre por qué no usé un servidor simulado en su lugar? Y alguien va a preguntarlo. Así que aquí está la pregunta, y tengo las respuestas preparadas para ti. Así que primero hay como cinco pasos para esta pregunta. Primero, los servidores simulados necesitan configuraciones. Tuviste que hacer un montón de configuraciones del servidor simulado, mantenerlo, configurarlo para que se ejecute en pipelines o donde sea y todas esas cosas. Por ejemplo, hay otra cosa que es usualmente, si una de las pruebas falla y rompe el servidor simulado, todas las otras pruebas fallarán después, así que hay un montón de desventajas que podrías nombrar para estas cosas. Para mí, lo que realmente me gusta de usar el trabajador de servicio simulado en lugar de esto es primero, no tienes mucha configuración. Una vez que tienes el contrato, no tienes tanto mantenimiento y no tienes que preocuparte por todos los otros escenarios. Como mencioné, por ejemplo, la última pregunta que tuvimos para simplemente anular un escenario para una prueba específica. Di el ejemplo de si estamos usando un servidor simulado, tendríamos que ir allí y configurar sólo un escenario específico. Así que siempre que haya este parámetro específico, vas a lanzar un error con el trabajador de servicio simulado. Simplemente importas lo que sea que añadas y dices para aquí, lanza un error. Así que en su mayoría, no tienes que configurar cosas separadas a un lado. Puedes incluir esto en tu propia solución porque el trabajador de servicio simulado está alrededor de tus propios proyectos y la otra mejor parte, no necesitas cambiar configuraciones en tus pruebas para apuntar al servidor simulado cada vez que estás ejecutando la prueba, simplemente inicias el servidor en, eso es prácticamente todo con el trabajador de servicio simulado. Genial. Gracias. La siguiente pregunta es de Jack. ¿Cómo evitas simplemente re implementar el backend en tu trabajador de servicio simulado por ejemplo para probar las respuestas dinámicas basadas en los parámetros? Esa es también una gran pregunta. Um, para este escenario.

Mocks Dinámicos y Anulaciones de Pruebas

Short description:

La mayoría de las veces, es una simple respuesta simulada o transformación. Si necesitas respuestas dinámicas, puedes anularlas para pruebas específicas. Esto evita la necesidad de simulacros dinámicos en el contrato y simplifica los manejadores de solicitudes.

Entonces, permíteme prevenir solo, está bien. Entonces, para este escenario, la mayoría de las veces no he tenido esta experiencia. No lo he hecho, la mayoría de las veces es solo un simple simulacro de cáncer, um, solo algo de Jason o lo que sea, o algunas transformaciones de salida sobre las cosas que teníamos. Si necesitas estas respuestas dinámicas, entonces para cada prueba específica, puedes simplemente anularla en esa prueba específica. Entonces, si estás haciendo un caso de prueba en ese escritorio, puedes simplemente decir, está bien, aquí quiero que devuelvas esto en lugar de devolver eso. Y de esta manera, evitas tener que programar, tener simulacros dinámicos en tu contrato, en lugar de tener todo configurado por separado. Así que en su mayoría simplemente pasas la responsabilidad de la prueba que estás haciendo para darte la respuesta que necesitas en lugar de agregar todas las demás cosas en los manejadores de solicitudes.

Servidor Simulado y Esquema GraphQL

Short description:

El orador reconoce que no tiene mucha experiencia utilizando servidores simulados con GraphQL. Sugiere revisar la documentación y contactar a Artem en Twitter para preguntas específicas. Mencionan el próximo lanzamiento de la V2 de MS-Double y animan a la audiencia a mantenerse actualizada.

Muy bien. Gracias, Jack. Y gracias Daniel. Primero, la siguiente pregunta es, ¿los simulacros son comprobados estáticamente contra el esquema GraphQL? Esa es una gran pregunta. No sé la respuesta a esta, para ser honesto, no he tenido mucha experiencia utilizando estos con GraphQL. Hice algunas demostraciones, pero principalmente los entornos en los que he estado trabajando son basados en rest Te sugeriría que revises la documentation porque es realmente, realmente buena. Y ahora están a punto de lanzar la V2 de MS-Double. Algunas cosas podrían cambiar. Así que sí, mi sugerencia aquí es revisar la documentation y si tienes una pregunta específica esta pregunta específica, puedes simplemente ir a Twitter y etiquetar a Artem y probablemente te dará la retroalimentación, ¿verdad? Como necesites. Así que él es la fuente de verdad para esto. Quizás Lenz todavía está aquí. No lo sé. Quizás él sabe. Ya se fue. Nos dejó. Pero lo averiguaremos. También intentaré preguntar y trataré de volver a la persona que hizo esta pregunta, anónima, intentaré encontrar a esta persona. Buena suerte. Mantenme al día. Vale.

Definiendo Servidores Simulados con Manipuladores Variables

Short description:

El orador aborda una pregunta sobre la definición de diferentes servidores simulados con manipuladores variables para solicitudes basadas en diferentes estados de una aplicación. Explican que se pueden lograr escenarios dinámicos definiendo rutas en MSW y especificando diferentes parámetros para cada escenario. El orador reconoce que no entendió completamente la pregunta, pero anima a la persona a buscar una aclaración adicional. La sesión de preguntas y respuestas concluye, y Daniel agradece a la audiencia por tenerlo.

Oh, anónimo es otro. ¿Puedes definir diferentes servidores simulados con manipuladores variables para solicitudes en ejemplo, basado en diferentes estados de una aplicación. Vale. Entonces diferentes simulacros con variables. Vale. Entonces quieres manipuladores específicos dependiendo del escenario. ¿Es eso, estoy tratando de entender esta pregunta. Entonces define diferentes servidores simulados con varios manipuladores para solicitudes. Vale. Entonces estoy asumiendo, y eso, estoy asumiendo si la persona que preguntó aquí está aquí y podría aclarar, me encantaría, pero estoy asumiendo que quieres una vez más, escenarios dinámicos, dependiendo de lo que tienes en tu aplicación. Entonces, una vez más, generalmente cuando estás haciendo una solicitud, tu solicitud va a ir a una ruta y esa ruta está definida con MS double. Así que imagina que tienes un escenario que quieres, vas a la API A y esa API va a recibir el parámetro B. Entonces este es un escenario, pero también sabes que tendrás otro contrato especifica que cuando va a la API A con el parámetro C, algo es diferente. Puedes simplemente en tu solicitud y especificar esa ruta específica y probablemente, va a haber diferentes estados también va a ser diferentes rutas también. O puedes ir de la otra manera y simplemente definir eso en tu prueba. Bueno, no entendí tanto esta pregunta, así que di una respuesta un poco vaga respuestas, pero si la persona que te preguntó esto está aquí, por favor ponte en contacto conmigo, o si también estás en línea, ponte en contacto conmigo y lo intentaremos averiguar juntos.

Muy bien. Bueno, eso es todo el tiempo que tenemos para preguntas y respuestas. Entonces Daniel, muchas gracias por unirte a nosotros hoy. Gracias por tenerme. Ahora te toca el fin de semana. Disfruta. Disfruta de Londres.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

JSNation 2023JSNation 2023
29 min
Modern Web Debugging
Few developers enjoy debugging, and debugging can be complex for modern web apps because of the multiple frameworks, languages, and libraries used. But, developer tools have come a long way in making the process easier. In this talk, Jecelyn will dig into the modern state of debugging, improvements in DevTools, and how you can use them to reliably debug your apps.
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
React Day Berlin 2022React Day Berlin 2022
29 min
Get rid of your API schemas with tRPC
Do you know we can replace API schemas with a lightweight and type-safe library? With tRPC you can easily replace GraphQL or REST with inferred shapes without schemas or code generation. In this talk we will understand the benefit of tRPC and how apply it in a NextJs application. If you want reduce your project complexity you can't miss this talk.
DevOps.js Conf 2022DevOps.js Conf 2022
31 min
pnpm – a Fast, Disk Space Efficient Package Manager for JavaScript
You will learn about one of the most popular package managers for JavaScript and its advantages over npm and Yarn.A brief history of JavaScript package managersThe isolated node_modules structure created pnpmWhat makes pnpm so fastWhat makes pnpm disk space efficientMonorepo supportManaging Node.js versions with pnpm
GraphQL Galaxy 2022GraphQL Galaxy 2022
16 min
Step aside resolvers: a new approach to GraphQL execution
Though GraphQL is declarative, resolvers operate field-by-field, layer-by-layer, often resulting in unnecessary work for your business logic even when using techniques such as DataLoader. In this talk, Benjie will introduce his vision for a new general-purpose GraphQL execution strategy whose holistic approach could lead to significant efficiency and scalability gains for all GraphQL APIs.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
GraphQL Galaxy 2021GraphQL Galaxy 2021
48 min
Building GraphQL APIs on top of Ethereum with The Graph
WorkshopFree
The Graph is an indexing protocol for querying networks like Ethereum, IPFS, and other blockchains. Anyone can build and publish open APIs, called subgraphs, making data easily accessible.

In this workshop you’ll learn how to build a subgraph that indexes NFT blockchain data from the Foundation smart contract. We’ll deploy the API, and learn how to perform queries to retrieve data using various types of data access patterns, implementing filters and sorting.

By the end of the workshop, you should understand how to build and deploy performant APIs to The Graph to index data from any smart contract deployed to Ethereum.
React Summit 2022React Summit 2022
147 min
Hands-on with AG Grid's React Data Grid
WorkshopFree
Get started with AG Grid React Data Grid with a hands-on tutorial from the core team that will take you through the steps of creating your first grid, including how to configure the grid with simple properties and custom components. AG Grid community edition is completely free to use in commercial applications, so you'll learn a powerful tool that you can immediately add to your projects. You'll also discover how to load data into the grid and different ways to add custom rendering to the grid. By the end of the workshop, you will have created an AG Grid React Data Grid and customized with functional React components.- Getting started and installing AG Grid- Configuring sorting, filtering, pagination- Loading data into the grid- The grid API- Using hooks and functional components with AG Grid- Capabilities of the free community edition of AG Grid- Customizing the grid with React Components
Node Congress 2022Node Congress 2022
98 min
Database Workflows & API Development with Prisma
WorkshopFree
Prisma is an open-source ORM for Node.js and TypeScript. In this workshop, you’ll learn the fundamental Prisma workflows to model data, perform database migrations and query the database to read and write data. You’ll also learn how Prisma fits into your application stack, building a REST API and a GraphQL API from scratch using SQLite as the database.
Table of contents:
- Setting up Prisma, data modeling & migrations- Exploring Prisma Client to query the database- Building REST API routes with Express- Building a GraphQL API with Apollo Server
React Advanced Conference 2022React Advanced Conference 2022
206 min
Best Practices and Patterns for Managing API Requests and States
Workshop
With the rise of frameworks, such as React, Vue or Angular, the way websites are built changed over the years. Modern applications can be very dynamic and perform multiple API requests to populate a website with fresh content or submit new data to a server. However, this paradigm shift introduced new problems developers need to deal with. When an API request is pending, succeeds, or fails, a user should be presented with meaningful feedback. Other problems can comprise API data caching or syncing the client state with the server. All of these problems require solutions that need to be coded, but these can quickly get out of hand and result in a codebase that is hard to extend and maintain. In this workshop, we will cover how to handle API requests, API states and request cancellation by implementing an API Layer and combining it with React-Query.
Prerequisites: To make the most out of this workshop, you should be familiar with React and Hooks, such as useState, useEffect, etc. If you would like to code along, make sure you have Git, a code editor, Node, and npm installed on your machine.