Hoy vamos a hablar sobre la medición del costo de una consulta GraphQL con Mercury's Explain. Primero, permíteme presentarme. Mi nombre es Marco Ippolito, soy un desarrollador de software en NearForm y colaborador de Node.js. Soy de Spoltore, que es una pequeña ciudad en Abruzzo, Italia, pero actualmente vivo en Milán.
Así que empecemos. Me gusta comparar GraphQL con nuestro comprador personal. Simplemente creamos una lista de elementos que queremos. No necesitamos saber dónde se encuentran los elementos. No necesitamos saber en qué supermercado, en qué pasillo. Simplemente tenemos una consulta, que es básicamente una lista, y él los va a buscar por nosotros. A diferencia de REST, hay algunas diferencias. Por ejemplo, con REST tienes que conocer la ruta donde se encuentra el elemento, mientras que con GraphQL simplemente no te importa. Si cambias la disposición de la tienda, no te importa, pero esto oculta algunos problemas.
¿Y qué hay del costo? Bueno, hay algunas implicaciones. Por ejemplo, cuando tenemos una consulta GraphQL, solo podemos ver el costo total. Por ejemplo, cuántos milisegundos tardó en resolverse la consulta, lo cual no es ideal porque si obtenemos docenas de campos, no sabemos qué campo es más costoso que el otro. Esto significa que es muy difícil depurar y optimizar una consulta lenta, especialmente si usas fragmentos. En aplicaciones de producción grandes, tendemos a usar fragmentos con campos centralizados que queremos solicitar, pero esto dificulta detectar campos adicionales que no necesitamos en una consulta específica. Podemos decir que en GraphQL es muy importante conocer el costo de cada campo de una consulta. De lo contrario, tendrás grandes problemas de rendimiento.
Esta es una de las principales razones por las que en NearForm creamos Mercurius Explain. Mercurius es el adaptador GraphQL para Fastify, y Mercurius Explain es un complemento que puede agregarse fácilmente a tu instancia de Mercurius. Las principales características de este complemento son el Perfilador, que básicamente registra el tiempo de resolución de cada resolutor GraphQL en el atributo Explain de tu respuesta GraphQL. Esto es muy útil porque puedes ver el tiempo de resolución en milisegundos. Como puedes ver en este JSON, está el inicio, el fin y el tiempo total que un resolutor específico tardó para un campo específico de tu consulta. También cuenta con las llamadas al resolutor, que es básicamente un contador de cuántas veces se invoca un resolutor. Funciona perfectamente en una puerta de enlace en una Federación, que es básicamente lo que usamos para aplicaciones de producción grandes. Está asegurado por la firma, por lo que puedes usar tus propias políticas de autorización, por ejemplo, verificar si en la solicitud hay un encabezado específico, y también es muy rápido. Creamos este complemento que está destinado a ser utilizado específicamente en producción, pero también durante el desarrollo. Por eso este complemento también cuenta con un complemento GraphQL. Como puedes ver en esta imagen, en el lado izquierdo está el tiempo de resolución de cada campo de nuestra consulta. Mientras estás en la fase de desarrollo, puedes detectar fácilmente un campo lento o si hay algún problema de rendimiento con este complemento, puedes detectarlo de inmediato. También tenemos el diagrama de barras para cada resolutor. Como puedes ver a la izquierda, está en milisegundos. Para cada resolución puedes ver cuándo comenzó, cuándo terminó, es muy específico. Así que te recomiendo que uses este complemento en prácticamente todas las circunstancias, producción, desarrollo, pequeño, grande, porque es muy útil y es muy importante en GraphQL conocer el costo de una consulta. Así que gracias por escuchar, aquí dejo mis cuentas en redes sociales, y también quiero agradecer a Davide Fiorello, quien es el cerebro detrás de este complemento. Y eso es todo, muchas gracias.
Comments