Rendimiento y Monitoreo de GraphQL

Hola a todos. Mi nombre es Ankita Masand. Soy una Arquitecta Asociada en Treebo. Trabajo en el producto SaaS de Treebo llamado Hotel Superhero. Hotel Superhero es un sistema de gestión de propiedades de hotel basado en la nube utilizado por varias cadenas hoteleras en todo el mundo. Proporciona una serie de funciones para crear, gestionar reservas, generar facturas, varios informes, configurar precios de habitaciones en un hotel. Hemos estado utilizando ampliamente GraphQL para esta aplicación.

Hoy hablaré sobre el rendimiento y monitoreo de GraphQL. Como lista de temas que veremos en esta charla, las implicaciones de rendimiento de usar GraphQL en el stack, el diseño de esquemas GraphQL, el agrupamiento y la caché a nivel de solicitud utilizando Data Loaders, la carga perezosa de algunos campos y la transmisión de respuestas en una consulta GraphQL utilizando las nuevas directivas diff y stream, la caché en GraphQL, y finalmente, el monitoreo de consultas GraphQL utilizando New Relic. Empecemos.

Entenderemos las implicaciones de usar GraphQL utilizando un caso de uso simple de un sistema de gestión de propiedades de hotel. Lo que ves en la pantalla es una representación del Big Bank Hotel. Tiene tres tipos de habitaciones, tipo de habitación 1, 2 y 3. 1A, 1B, 1C son las habitaciones para el tipo de habitación 1 y las reservas como las casillas en blanco indican reservas para habitaciones específicas. La reserva 1 y la reserva 2 son para la habitación 1A. La casilla más grande indica que la reserva se extiende durante más días.

¿Qué se necesita para renderizar esta interfaz de usuario utilizando un cliente frontend? Esta es una vista que un hotelero ve en una pantalla para comprender y gestionar las reservas de su hotel. Veamos las llamadas HTTP que tendrías que hacer desde el cliente frontend para renderizar esta interfaz de usuario y mostrar la lista de reservas en este hotel. Primero haremos llamadas paralelas para obtener datos del hotel como el nombre y la ubicación. Luego haremos una llamada para obtener los tipos de habitaciones, las habitaciones, las reservas. Y una vez que obtengamos una lista de reservas de los servicios de terceros, haremos llamadas para obtener las facturas. Porque cada reserva está asociada con una factura y también hay algunos archivos adjuntos en una reserva que tenemos que mostrar en esa interfaz de usuario. Así que por cada reserva obtendremos su factura correspondiente y los archivos adjuntos. Cada reserva se realiza para un usuario específico. Luego llamaremos a la API del usuario para obtener más detalles sobre ese usuario y también sus preferencias. Esto parece bien. Y no hay demasiadas llamadas. Así que esto es algo a lo que estamos acostumbrados. Estas son las llamadas a la API solo cuando hay tres reservas en un hotel. Si has observado con atención, estábamos obteniendo la API de facturas tres veces, lo que significa que hay tres reservas en un hotel.

Un hotel no puede permitirse un sistema de gestión de propiedades para gestionar tres reservas. ¿Qué sucedería si hay cientos de reservas en un hotel? Así que tendríamos que hacer 100 llamadas a la API para obtener facturas, archivos adjuntos. Habría demasiados viajes de ida y vuelta desde el cliente del frontend al servidor. ¿Cómo resolvemos estos problemas?

Estábamos en la etapa inicial de construcción de esta aplicación y parecía bien experimentar con GraphQL y ver cómo resultaba. GraphQL proporcionaría la respuesta en una sola llamada a la API, no hay múltiples viajes de ida y vuelta al servidor. Es declarativo por naturaleza y el cliente especifica los datos que necesita y, por lo tanto, se reduce considerablemente el tamaño de la respuesta. No hay código repetido para diferentes aplicaciones de frontend. Y lo más importante de todo, tiene un sistema de tipos sólido. La presentación fue muy bien y el equipo de frontend tuvo la oportunidad de experimentar con GraphQL y agregarlo al stack.

Veamos la consulta de GraphQL que estamos utilizando para obtener colectivamente la respuesta de todas las llamadas a la API. Si observas, hay una consulta Hotel por ID. Dentro de HotelporID, estamos obteniendo tipos de habitaciones. Para cada tipo de habitación, estamos obteniendo habitaciones. También estamos obteniendo reservas en la misma consulta. Y dentro de las reservas, estamos obteniendo facturas. Factura para cada reserva, archivos adjuntos, clientes. Y para cada cliente, estamos obteniendo sus preferencias. Veamos cómo se resolvería cada una de estas consultas en el servidor de GraphQL. Para resolver la consulta HotelporID, hacemos una llamada al servicio de aguas abajo para obtener los detalles de un hotel. Para resolver los tipos de habitaciones, hacemos una llamada para obtener los tipos de habitaciones de un servicio de aguas abajo. Y para cada tipo de habitación, obtenemos habitaciones. Esta es la llamada que hacemos para obtener las reservas. Y para cada reserva, hacemos una llamada para obtener su factura correspondiente, archivos adjuntos, clientes, y para cada cliente, hacemos una llamada para obtener sus preferencias.

Esto es genial porque no tenemos que escribir código en el lado del frontend para gestionar cuándo disparar API específicas. Como Bill depende de la reserva. Una vez que obtengamos la respuesta de las reservas, solo entonces podemos disparar las API de Bill. Tampoco tenemos que ejecutar mapas en el frontend para mapear tipos de habitaciones a habitaciones, habitaciones a reservas, reservas a Bill. GraphQL hace todo eso. Entonces, ¿cuáles son las implicaciones de rendimiento al usar GraphQL? Después de todo el trabajo duro, sentimos que el rendimiento de la aplicación no mejoró mucho para reservas más grandes. Reservas que se extienden durante más días que tienen más clientes.

O para hoteles que tienen más tipos de habitaciones y más habitaciones. Entonces veamos una lista de llamadas a la API que estamos haciendo a los servicios de terceros. Consideremos un ejemplo de 25 reservas. Por ejemplo, en esa consulta, estamos obteniendo 25 reservas. Haremos una llamada para obtener los detalles de un hotel, una llamada para obtener los tipos de habitaciones. Digamos que devuelve seis tipos de habitaciones. Ahora, para cada tipo de habitación, obtendremos su habitación correspondiente. Por lo tanto, haremos seis llamadas a la API de habitaciones, una llamada para obtener las reservas. Esta API devuelve 25 reservas. Por eso haremos 25 llamadas para obtener las facturas y 25 llamadas para obtener los archivos adjuntos, que son para cada reserva. En total, hay 100 usuarios en todas estas reservas. Una reserva puede tener varios usuarios. Por lo tanto, haremos 100 llamadas para obtener los detalles del usuario, 100 llamadas para obtener sus preferencias. En total, hay 259 llamadas que tenemos que hacer para obtener 225 reservas y mostrarlo en la interfaz de usuario.

Sí, tenemos que hacer 259 llamadas a los servicios de terceros para resolver solo una consulta de GraphQL. ¿Qué sucedería si hay más tipos de habitaciones y habitaciones en un hotel? El número de llamadas a la API seguiría aumentando en función del número de tipos de habitaciones, habitaciones, reservas, y el número de usuarios en estas reservas. ¿Cómo solucionamos esto? Analicemos lo que realmente estamos haciendo en esta consulta. Estamos obteniendo la respuesta completa en una consulta de GraphQL, incluyendo a los usuarios y sus preferencias. Estamos obteniendo los tipos de habitaciones dentro del objeto de hotel, lo cual está bien. Pero para cada tipo de habitación, estamos llamando a la API de habitaciones para obtener las habitaciones porque esta es la estructura que espera la interfaz de usuario. Estamos haciendo esto porque no tenemos que ejecutar bucles en el frontend para obtener el objeto completo mapeado tal como lo requiere la interfaz de usuario. Estamos obteniendo las facturas dentro del objeto de reserva, lo que significa que llamaremos a la API de facturas para cada reserva. No tenemos que mostrar las preferencias del usuario al cargar. ¿Por qué obtenerlo y hacer la llamada inicial y mostrar un estado de carga al usuario? Esto no es justo para el usuario porque ni siquiera le importa ver las preferencias del usuario desde el principio. ¿Cómo solucionamos estos problemas? Entonces, ¿debería el esquema de GraphQL mapear uno a uno con su interfaz de usuario o con sus modelos de dominio? Si observas detenidamente, estamos obteniendo los tipos de habitaciones dentro del objeto de hotel porque los tipos de habitaciones son una propiedad de un hotel, lo cual está bien. Pero estamos obteniendo las habitaciones dentro de cada uno de estos tipos de habitaciones. Las habitaciones no son una propiedad de un tipo de habitación. Las habitaciones son una propiedad de un hotel. El modelo de dominio considera que las habitaciones son una propiedad de un hotel y no de un tipo de habitación. Estamos haciendo esto porque así es como la interfaz de usuario que estamos tratando de construir lo espera.

¿En qué nivel de la consulta deberíamos obtener las habitaciones? Deberíamos intentar diseñar nuestro esquema de GraphQL de manera similar a nuestro modelo de dominio, porque si lo diseñas basándote en tu interfaz de usuario, solo podrás satisfacer un caso de uso de tus clientes de frontend. Y el esquema de GraphQL debe diseñarse de manera robusta para que pueda ser utilizado por diferentes clientes de frontend.

El campo de habitaciones debería ser una propiedad del hotel y no de los tipos de habitaciones. Sigamos adelante. Aquí estamos obteniendo las preferencias dentro del objeto de usuario, y las preferencias son una propiedad de un usuario. Así es como también lo espera el modelo de dominio.

¿Cómo solucionamos este problema de múltiples llamadas a la API para el campo de preferencias del usuario, aunque esté mapeado correctamente? Aquí viene la parte interesante de la charla, agrupación y almacenamiento en caché utilizando Data Loader. Solo podrás entender la importancia de los data loaders, si has visto múltiples llamadas a tus servicios externos para resolver una sola consulta de GraphQL.

Data Loader básicamente recopila la solicitud de API dentro de un solo marco de ejecución. Lo que ves en la pantalla es el número de llamadas a la API antes de usar los data loaders, que es de 259 a los servicios externos. Ahora se reduce a dos llamadas a los servicios externos. ¿Cómo sucedió esto? Data Loader no realiza llamadas a la API de inmediato a los servicios externos. Recopilará todas las solicitudes de API y luego, dentro de un solo marco de ejecución, realizará una llamada de API en lote. Por ejemplo, para resolver cada factura, estábamos llamando a la API de facturas 25 veces. Aquí, si observas, esto es una llamada en lote. Data Loader está recopilando todos los ID de facturas y solo realizará una llamada a los servicios externos. Lo mismo ocurre con los archivos adjuntos, los ID de usuario y también con las preferencias. Por lo tanto, si cuentas esto, solo hay ocho llamadas que debes hacer a los servicios externos para obtener 25 reservas. Data Loader es una gran adición a la pila y no es muy difícil de implementar en el servidor de GraphQL.

Esto crea magia al reducir las 259 llamadas a los servicios externos a solo ocho y esto es un gran impulso para el rendimiento de tus aplicaciones. Veamos la implementación del cargador de facturas y el cargador de usuarios. Entonces, el cargador de facturas, esto toma algunas claves como los ID de las facturas y luego llama al cargador de facturas. Veremos la implementación de la función del cargador de facturas en un momento. Debes devolver estos data loaders desde los objetos de contexto para que estén disponibles en todos los resolutores. Así es como se ve una función del cargador de facturas. Recopila todos los ID de facturas dentro de un solo marco de ejecución y luego llama al servicio externo solo una vez. Devolverá una matriz de facturas. Entonces, desde tu resolutor, debes escribir cargador de facturas punto cargar. Este es el primer ID de factura, segundo ID de factura, todas estas facturas son diferentes, pero un servidor de GraphQL no llamará a la API de facturas de inmediato. Recopilará todos estos ID de facturas y luego realizará esta llamada agrupada de una vez.

Lo mismo ocurre con los usuarios. Esta es la API Badged que podemos usar para los usuarios y estos son todos usuarios diferentes, pero solo llamaríamos a la API secundaria una vez. La agrupación realmente mejora y ayuda mucho a mejorar el rendimiento de la aplicación.

Veamos cómo los Data Loaders ayudan en el almacenamiento en caché a nivel de solicitud. Si estás llamando a la misma clave, juguetes en un Data Loader en la misma solicitud, las respuestas posteriores se buscarían en la caché. Entendamos esto con la ayuda de un ejemplo.

Aquí tienes una consulta de GraphQL que estamos utilizando para obtener conferencias de JavaScript. Estamos obteniendo el nombre, la ubicación, los oradores de esa conferencia, sus charlas y el perfil de cada orador. Bob está hablando en cuatro conferencias, lo que significa que sin los Data Loaders, obviamente su perfil se obtendría cuatro veces, aunque tenga el mismo ID de perfil de usuario. Pero si usas Data Loaders para obtener este perfil de usuario, las llamadas posteriores para su perfil se servirían desde la caché.

Veamos la implementación. Esta es una función agrupada UserProfileLoader. Recopilará las claves y luego llamará a los servicios secundarios. Si ves userprofile.load, este es el mismo ID de usuario, ¿verdad? Este es el ID de usuario de Bob. En la primera llamada, llamaremos a los servicios secundarios. Estas son todas las mismas llamadas a la API. Por lo tanto, solo llamará a los servicios secundarios una vez. Perfecto. Parece que hemos logrado solucionar el desastre de las múltiples llamadas a la API mediante la agrupación y el almacenamiento en caché. Obviamente, se reducen las 259 llamadas a solo ocho. ¿Podemos hacer más? ¿Podemos mejorar aún más?

Si te has dado cuenta, el campo de preferencias en el objeto de usuario no está en el camino crítico de la interactividad de la interfaz de usuario. ¿Podemos aplazar la ejecución del resolvedor de preferencias de usuario? Sí, podemos. Podemos usar directivas diferidas para aplazar la ejecución del resolvedor de preferencias de usuario. Veamos cómo lo haríamos. Todo lo que tenemos que hacer es agregar la directiva diferida al campo de preferencias en tu consulta. La respuesta que obtendríamos, por lo tanto, las preferencias serían nulas en la respuesta inicial hasta que GraphQL las resuelva en el lado posterior. Y en la misma conexión HTTP, obtendríamos la respuesta de las preferencias como parches. Lo que ves aquí es la respuesta del objeto de reservas uno, clientes uno, y estas son las preferencias de ese cliente en particular. Las preferencias se cargarían de forma asíncrona en la interfaz de usuario, y no bloquearían la vista principal. Lo que hemos estado pensando hasta ahora es que las solicitudes se resuelven en una respuesta.

Entonces enviamos una solicitud en la conexión HTTP a un servidor GraphQL. El servidor GraphQL resuelve todos los campos en una consulta y envía la respuesta. Es fácil de entender si lo imaginas de esta manera.

Enviamos una solicitud a un servidor GraphQL, te suscribes a un observable, la misma conexión HTTP sigue abierta y el servidor GraphQL sigue enviando respuestas y parches según la ejecución de los campos. Veamos también cómo usaríamos los directores de transmisión.

Supongamos que tienes cien reservas para un hotel en particular. No quieres obtener todas las cientos de reservas en la misma consulta, ni siquiera podrías mostrar todas esas reservas en la vista del usuario. Entonces, en esta consulta le estamos diciendo a GraphQL que por favor nos envíe 10 reservas y transmita el resto de las reservas como parches en la misma conexión HTTP. Obtendremos 10 reservas en la respuesta inicial y las reservas posteriores se servirán como parches.

Todo esto funciona bien para una sola solicitud, pero hay algo importante que hemos pasado por alto. Los tipos de habitaciones y los números de habitación no cambian con frecuencia. ¿Podemos hacer algo al respecto? Veamos qué es el almacenamiento en caché a nivel de resolutor.

Podemos almacenar en caché datos estáticos que no dependen de la identidad del usuario en Redis o Memcache durante algún tiempo fijo. Los tipos de habitaciones y los campos de habitación de un hotel son estáticos y serán los mismos para todos los usuarios. Este es un buen ejemplo de almacenamiento en caché a nivel de resolutor. Veamos cómo lo haríamos.

Cuando un cliente de frontend solicita una consulta de reservas de hotel al servidor GraphQL. Mientras resolvemos los tipos de habitaciones, primero verificamos si los tipos de habitaciones están presentes en la caché de Redis. Si está presente, lo serviremos directamente desde la caché. Si no está presente, consultaremos al servidor de aguas abajo, almacenaremos la respuesta en Redis y luego la enviaremos de vuelta. Lo mismo ocurre con el resolutor de habitaciones. Verificaremos si las habitaciones están presentes en la caché de Redis. Si está presente, lo serviremos directamente desde la caché. De lo contrario, consultaremos al servicio de aguas abajo y almacenaremos la respuesta en Redis y luego la enviaremos de vuelta al resolutor.

Aquí, aunque los tipos de habitaciones y los campos de habitación no cambian con tanta frecuencia, seguimos consultando al servidor GraphQL. ¿Es posible obtener esta respuesta desde el servidor CDN más cercano sin tener que consultar al servidor GraphQL? Sí, estamos hablando de una solicitud GET aquí. En GraphQL, siempre hacemos una solicitud POST. Esto se debe a que enviamos la cadena de consulta a GraphQL como carga útil de la solicitud POST porque no se ajusta bien en una solicitud GET que se puede almacenar en caché. Entonces, el primer hito que debemos alcanzar es convertir POST en una solicitud GET. ¿Cómo lo hacemos? Podemos hacerlo utilizando consultas automáticas persistentes y es muy sencillo de implementar.

Con consultas automáticas persistentes, enviamos el hash de la cadena de consulta en una solicitud GET HTTP al servidor Apollo o al servidor GraphQL. Luego, el servidor determina que este hash en particular corresponde a esta cadena de consulta en particular. Resolverá esa consulta y enviará la respuesta de vuelta en el mismo formato de respuesta que el cliente esperaría. Así que aquí hemos logrado este objetivo de enviar una solicitud GET HTTP desde el cliente de frontend utilizando GraphQL.

¿Y ahora qué sigue? Una vez que podemos enviar una solicitud GET, lo que significa que podemos aprovechar todos los encabezados de control de caché disponibles. Podemos especificar la edad máxima de un campo en una consulta para el cual este campo en particular es válido. Y está bien resolver este campo desde el servicio CDN más cercano en lugar de golpear los servidores GraphQL. Sí, podemos aprovechar todos los encabezados de control de caché. Y esto mejoraría aún más el rendimiento.

Repasemos todo lo que aprendimos sobre el almacenamiento en caché. Aprendimos que podemos hacer almacenamiento en caché por solicitudes utilizando cargadores de datos. Podemos hacer almacenamiento en caché a nivel de resolutor para almacenar la respuesta de los servicios de aguas abajo en Redis o Memcache. Podemos utilizar consultas automáticas persistentes para enviar el hash de la cadena de consulta a GraphQL. Y podemos utilizar encabezados de control de caché en diferentes campos de la consulta. Hay una pregunta para reflexionar. Ahora que estamos utilizando una solicitud GET, ¿puede GraphQL admitir el código de estado de respuesta HTTP 304 no modificado? Pasaré al siguiente tema, que es monitorear las solicitudes de GraphQL en New Relic.

Esto es realmente interesante. Y es una gran adición al conjunto de herramientas. Lo que ves en la captura de pantalla, son las 20 consultas GraphQL más lentas. También puedes ver el tiempo de respuesta promedio más lento, el tiempo de respuesta promedio más lento, las 20 consultas GraphQL principales. Puedes ver los tiempos P95, P99 de una consulta GraphQL en particular utilizando esta herramienta poderosa. La fuente de esta captura de pantalla, son las llamadas que estás haciendo a servicios externos, el porcentaje de llamadas que estás haciendo a tus diferentes microservicios.

Esto muestra los detalles de seguimiento de una consulta GraphQL. Entonces, cada vez que hay un nuevo requisito o una nueva característica en el cliente de frontend, todo lo que pensamos es que tenemos que agregar este campo en particular en una consulta y listo. Obtendríamos la respuesta y la mostraríamos en la interfaz de usuario. Ni siquiera pensamos que este campo en particular va a realizar una llamada a la API a un servicio aguas abajo o va a golpear la base de datos. Y eso afectaría el rendimiento de esta consulta en particular. Entonces, al ver estos detalles de seguimiento, nos damos cuenta de que este campo en particular tarda tanto tiempo en resolverse o este campo en particular golpea el servidor backend. Este campo en particular realiza, este campo en particular está golpeando tu base de datos. Entonces, al ver este seguimiento, al ver los detalles de seguimiento de una consulta en particular, es muy fácil entender qué está consumiendo tiempo en esta consulta GraphQL.

Entonces, al analizar este seguimiento, al analizar los detalles de seguimiento de una consulta en particular, es muy fácil entender qué está consumiendo tiempo en esta consulta GraphQL.

Resumamos todo lo que aprendimos en esta charla. Los clientes pueden experimentar una disminución del rendimiento para consultas más grandes y más anidadas en GraphQL. Debemos estar atentos a la cantidad de solicitudes a la API o consultas a la base de datos que realizamos en una consulta GraphQL.

Debemos diseñar el esquema de GraphQL de manera más acorde a nuestro dominio y no mapearlo a la interfaz de usuario del frontend. Los cargadores de datos se utilizan para agrupar múltiples llamadas a la API al mismo punto final en una sola solicitud y así reducir la carga en tus servicios aguas abajo, como vimos para las API de facturas y usuarios. Los cargadores de datos también ayudan a almacenar en caché la misma solicitud a la API y llamar al servicio aguas abajo solo una vez para la misma clave de caché. Vimos que Bob, Bob habló en cuatro conferencias pero solo cargamos su perfil una vez porque su ID de perfil de usuario es el mismo.

Podemos utilizar diferentes directivas para diferir la respuesta de algunos campos en una consulta que no están en el camino crítico de la interactividad del usuario, que tardan más tiempo en resolverse o tienen un tamaño de respuesta más grande. Vimos que podemos diferir la ejecución del resolvedor de preferencias en un objeto de usuario. Podemos utilizar directivas de transmisión para transmitir la respuesta del campo de lista en una consulta. Podemos utilizar Redis o Memcached para almacenar en caché la respuesta de los servicios aguas abajo a nivel de resolvedor. Vimos que no es necesario llamar a los servicios backend para obtener datos estáticos como tipos de habitaciones y habitaciones de un hotel. Podemos obtenerlos directamente de Redis o Memcached. Por último, podemos utilizar consultas persistentes automáticas y realizar solicitudes GET desde el cliente del frontend a los servidores GraphQL. Aquí enviamos el hash de la consulta en una solicitud GET al servidor GraphQL. Utilizando esto, podemos aprovechar todas las cabeceras de control de caché especificando el TTL para algunos de los campos en esa consulta. Y luego podemos obtenerlos desde el servidor CDN más cercano. Por último, New Relic nos facilita la vida y muestra los detalles de seguimiento de una consulta GraphQL en particular. Realmente es una buena adición al conjunto de herramientas. Muchas gracias por escuchar. Que tengas un excelente día.

Entonces, al ver los resultados de la encuesta, solo como recordatorio, la pregunta fue si GraphQL admite un código de estado de respuesta 403. Y el 50% dice que no. Y luego entre sí y no estoy seguro, la división es del 25 al 25. Bueno, avísanos cuál es tu respuesta. Sí. Entonces es el código de estado de respuesta 304. Permíteme explicar qué es el código de estado de respuesta 304. Significa que es una respuesta de no modificada.

Eso significa que una entidad en particular que estás solicitando al servidor no ha sido modificada desde la última vez que la solicitaste. Lo cual significa, digamos, consideremos un ejemplo de una API REST. Estás solicitando una entidad en particular y ya tienes, digamos, la versión uno de esa entidad en tu cliente y la estás solicitando nuevamente, ¿de acuerdo? Y esta entidad no ha sido modificada. Entonces, el servidor te devolverá un código de estado de respuesta 304, lo que significa que por favor utiliza la entidad que ya tienes, eso ahorraría tiempo. No necesitas... El tiempo para descargar ese objeto en particular y analizarlo se ahorraría. Mi pregunta fue, esto lo podemos usar fácilmente en REST y aprovecharlo. Mi pregunta fue, ¿podemos admitir el código de estado de respuesta 304 en GraphQL? Actualmente no, porque GraphQL, en realidad no recuperamos solo una entidad en particular. Es un conjunto de diferentes y muchas entidades que recuperamos en una consulta en particular. Por lo tanto, enviar un código de respuesta como 304 no tiene sentido porque estamos tratando de decir que la consulta en particular en su totalidad no ha cambiado, lo cual puede que no sea cierto. Por lo tanto, podemos aprovechar las cabeceras de control de caché pero actualmente GraphQL envía 200, incluso si ninguno de los campos en la consulta ha cambiado. Genial. De acuerdo.

Luego una pregunta de seguimiento. ¿Soporta el código de estado 418? El 418 es, es el código de estado Soy una tetera, lo que significa que el servidor rechaza el intento de hacer café con una tetera. Supongo que no lo soporta, pero no estoy completamente seguro. No lo he probado. Creo que deberíamos implementarlo. Así que si alguien tiene tiempo para implementarlo, es un código de estado importante que necesitamos en GraphQL. Sí. Sí.

Muy bien. Pasemos a las preguntas. Si aún tienes alguna pregunta, todavía tienes tiempo para escribirlas mientras hablamos. Así que asegúrate de unirte al canal de Discord, GraphQL Milky Way Q&A.

Primera pregunta. ¿El tamaño de respuesta de una consulta GraphQL puede afectar el rendimiento de la aplicación? Y si es así, ¿cómo? Sí. Entonces, el tamaño de respuesta realmente afecta el rendimiento de la aplicación. Consideremos un ejemplo. Ahora, estás obteniendo cientos de objetos en una lista y estos objetos están anidados, ¿de acuerdo? Entonces, hemos visto en nuestra propia aplicación, hemos visto que estás transportando más de dos a cinco MB de datos a través de la red porque el área es bastante grande. Hay demasiados objetos y están bastante anidados, ¿de acuerdo? Entonces, si observas el tiempo de descarga que lleva este objeto, también es más porque el objeto es bastante grande. Sí, afecta el rendimiento de la aplicación. Si quieres superar este problema, lo que hemos hecho es en lugar de tener demasiados filtros en el lado del cliente y obtener toda la respuesta de GraphQL y tener filtros en el lado del cliente, podríamos intentar tener filtros en el lado del servidor para enviar menos datos y la respuesta filtrada al cliente. De esa manera, estarías descargando un contenido más pequeño. Estoy tratando de entenderlo. Sí, tiene mucho sentido. Pero, ¿qué pasa con cosas como la paginación, por supuesto que también puede ayudar. Pero nuevamente, si tu objeto es simplemente grande, puedes aplicar paginación. Sí, la paginación es una buena idea. Creo que siempre deberíamos obtener, como dije en la charla también, siempre deberíamos obtener. Si tienes cientos de reservas no obtengas todas las cientos de ellas.

Ni siquiera podrás mostrarlos en el viewport del usuario. Estás obteniendo 25 reservas. En algunos casos, estas 25 reservas son objetos anidados porque en GraphQL tienes flexibilidad para consultar campos dentro de campos dentro de campos, ¿verdad? Entonces puede haber muchos campos anidados. Sí, eso podría afectar el rendimiento de tu aplicación. Y como dije, ya sabes, si lo ves en la URL como podrías entender. Sí, podrías entender que esta consulta anidada en particular también está afectando el rendimiento.

Me silencié y ahora me des-silencié. Bienvenido al mundo digital. Es como, es como, esto es algo nuevo, reunirse de forma remota. Entonces el rendimiento es, por supuesto, bueno, uno de los temas más importantes para hacer una buena aplicación web. Por supuesto, hay muchas cosas que hacen una buena aplicación web. Y, bueno, la paginación es una cosa que puedes hacer, pero ¿hay alguna otra cosa en la que puedas pensar que pueda ayudar, por supuesto, con GraphQL para mejorar el rendimiento?

Sí, de hecho, ya sabes, como usar, diferir algunos campos en particular que no necesitas en el viewport del usuario, vi una charla de Uri que diferentes directivas de transmisión son bastante poderosas y son compatibles con GraphQL Yuga. Entonces, con estos campos, realmente no obtenemos, ya sabes, lo que no se requería en la interfaz de usuario, en la carga inicial por el usuario. Así que eso es bastante bueno para mejorar el rendimiento de tu aplicación. Pero más que eso, en nuestra aplicación, lo que hemos visto es simplemente obtener, ya sabes, obtener menos campos. En el lado del frontend, creemos que deberíamos obtener cinco o seis campos más y habrás terminado con la tarea que te han asignado, ¿verdad? Pero no entendemos que estos cinco o seis campos van a todos tus servicios secundarios. Ahí es cuando te das cuenta, ahí es cuando entiendes que el costo de esta consulta está afectando dos o tres consultas a la base de datos, afectando dos o tres servicios secundarios. Ahí es cuando te das cuenta de que va a llevar más tiempo. Sí. Sí. A veces, si entiendo correctamente, agregas dos o tres campos más a tu consulta y piensas que son solo dos o tres campos más, pero en realidad puede ser una consulta muy pesada. Entonces, básicamente, el consejo sería siempre estar monitoreando. Cuando estás editando una consulta, estar monitoreando, estar atento a lo que está sucediendo, probar antes, probar después, y asegurarte de no ralentizar significativamente tu aplicación. Sí, sí, absolutamente. De acuerdo, genial. Entonces, bien. Eso es bueno. Y volviendo un poco al lado de la interfaz de usuario. Entonces estamos diciendo que solo obtengas lo que está en el viewport, pero ¿también estás usando algo como pantallas de esqueleto en la interfaz de usuario? Sí, sí. Entonces, mientras obtienes tus datos, puedes aprovechar, como estamos usando suspense, ¿vale? Suspense en React, donde puedes mostrar el esqueleto de tu interfaz de usuario hasta que obtengas los datos, obtienes una mejora en el rendimiento percibido en el lado de la interfaz de usuario.

Sí, también podemos hacer muchas cosas en el lado del cliente para obtener mejoras en el rendimiento percibido para el usuario. El usuario siente que algo se está cargando, no hay una pantalla en blanco, o simplemente no le mostramos el cargador al usuario, hay algo que está ahí en la pantalla y el usuario tiene suficiente paciencia para esperar a que los datos lleguen.

Sí, me gusta ese término de rendimiento percibido. En mi opinión, es incluso más importante que el rendimiento real porque, bueno, si es rápido pero no se siente rápido, no importa, ¿verdad? Hmm, sí. Entonces, algo como una pantalla de esqueleto realmente puede ayudar al usuario a sentir que algo está sucediendo. Sí.

Recuerdo cuando todavía estaba en la escuela y estaba aprendiendo sobre el rendimiento y el rendimiento percibido, el ejemplo que dieron fue sobre un aeropuerto que tenía un largo recorrido, o un recorrido realmente corto desde que sales del avión hasta la cinta transportadora donde recoges tu equipaje. Y la gente se quejaba de que tenían que esperar 20 minutos por su equipaje. Y lo que hicieron fue crear una ruta más larga. Podría ser una caminata de dos minutos, pero la hicieron de 20 minutos. Así que la gente no está esperando 20 minutos. Solo están caminando por el aeropuerto durante 20 minutos. Y luego todos decían, oh Dios mío, no solo esperan, miro a la cámara aquí. Y me encanta ese ejemplo, pero sí, eso es rendimiento percibido en el mundo real para ti. Sí, fue un gran ejemplo.

Así que esas son todas las preguntas que tenemos por el momento. Ankita, muchas gracias por unirte a nosotros hoy. Vamos a tomar un breve descanso. Y si tienes más preguntas, Ankita estará en su chat especial, así que haz clic en el enlace en la línea de tiempo de abajo. Ankita, muchas gracias por unirte a nosotros y compartir tus conocimientos. Gracias. Muchas gracias. Adiós. Adiós.