Los datos son conocimiento y el conocimiento es poder. Uno de los mayores poderes que tenemos como desarrolladores es la capacidad de acceder y manipular datos en bruto con facilidad. Pero se necesita mucho contexto para saber cómo escribir una consulta SQL o usar una API o hacer una solicitud CURL. Gran parte de nuestra energía en la comunidad de GraphQL se dedica a avanzar en la especificación y mejorar las herramientas para desarrolladores, pero no dedicamos mucho tiempo a hablar de lo que GraphQL puede hacer para ayudar a las personas en nuestras organizaciones más allá de nuestros desarrolladores: nuestros diseñadores, gerentes de producto, líderes empresariales, ingenieros de éxito del cliente, etc. En esta charla, compartiré los resultados de algunas investigaciones que realizamos en Apollo sobre la accesibilidad de GraphQL y mi visión de cómo GraphQL puede conectar a los humanos con datos que les impactan de manera mucho más efectiva, dándoles la capacidad de responder sus propias preguntas.
GraphQL para Todos - Danielle Man
Video Summary and Transcription
GraphQL puede ser la forma estándar de modelar y consultar datos comerciales, y tiene el potencial de ir más allá de solo ayudar a los desarrolladores. Optimizar las consultas de GraphQL implica mapearlas a consultas de base de datos eficientes. La traducción de consultas de Druid a GraphQL proporciona flexibilidad pero tiene desafíos con el formato de datos y la ejecución de consultas. Las directivas y herramientas como GraphQL LowDash pueden transformar matrices de objetos y proporcionar soporte para aplicar funciones a las consultas. Hacer que GraphQL sea más accesible e integrarlo en herramientas como Tableau puede desbloquear todo su potencial.
1. Introducción a GraphQL y su Potencial
Soy una gerente de ingeniería en Apollo, y hoy quiero hablar sobre cómo aprovechar y consumir completamente una API de GraphQL. GraphQL puede ser útil para las personas en su organización más allá de los desarrolladores. Puede ser la forma estándar en la que modelamos y consultamos nuestros datos empresariales. Compararemos SQL con GraphQL y discutiremos las preocupaciones de usar GraphQL como un punto de acceso universal para los datos.
¡Hola a todos! Mi nombre es Danielle, y soy una gerente de ingeniería en Apollo, donde mi equipo y yo somos responsables de construir herramientas de desarrollo específicamente para ayudar a las personas a consultar y utilizar las API de GraphQL. Hoy estoy muy emocionada de compartir algunas de las ideas que inspiran nuestro trabajo, centradas en cómo pueden utilizar GraphQL para conectar a las personas en sus organizaciones más allá de los desarrolladores, para que puedan acceder a los datos que les permitirán hacer su trabajo de manera más efectiva. Esta charla será un poco diferente a las demás, porque en lugar de hablar sobre cómo construir una API de GraphQL y los desafíos técnicos interesantes que presenta, quiero hablar sobre cómo aprovechar y consumir completamente una API de GraphQL. Creo que GraphQL puede ser útil para las personas en su organización mucho más allá de los desarrolladores que lo utilizan para consultar sus datos. Creo que pueden construir un gráfico unificado para sus datos, al que todos puedan acceder, y que empoderará a las personas en su organización como nunca antes. La accesibilidad a los datos es un problema muy difícil, y es complicado acceder a los datos de todos nuestros sistemas en estos días porque los almacenamos en diferentes lugares, diferentes bases de datos, diferentes microservicios, todo ha sido optimizado para diferentes tipos de datos, todo se consulta de manera ligeramente diferente, y a veces es difícil entender todos estos sistemas, incluso para los desarrolladores, pero hay muchas personas que podrían hacer su trabajo de manera más efectiva si pudieran conectarse a los datos en nuestros sistemas. Para el desarrollo de productos, hemos resuelto la situación de tener muchos servicios que son un poco diferentes al introducir una nueva capa con GraphQL y utilizarla para crear una API singular. Y creo que esta nueva capa que hemos introducido para nuestras API con GraphQL también se puede utilizar para resolver el problema más general del acceso a los datos en nuestras organizaciones. Creo que GraphQL puede ser la forma estándar en la que modelamos y consultamos nuestros datos empresariales para casi todos los casos de uso. Así que en nuestro tiempo hoy, quiero guiarlos a todos en cómo pensar en el uso de GraphQL de esta manera, mientras planteamos la pregunta de si GraphQL puede ser la forma en que creamos un punto de acceso universal para nuestros datos. Y para adentrarnos en este tema, quiero comenzar caminando juntos a través de una consulta SQL y comparándola un poco con GraphQL. Esta es una consulta que he escrito muchas veces, y es una pregunta de análisis. ¿Cuántos usuarios he visto en los últimos 30 días para cada cuenta? Y si desgloso esta consulta y observo los diferentes elementos, hay algunas cosas distintas que resaltan. El select me permite controlar lo que estoy solicitando entre una variedad de opciones, lo cual tenemos la misma capacidad de hacer con GraphQL. El where es una selección condicional. Solo quiero seleccionar usuarios si los he visto en los últimos 30 días. Con GraphQL, no tenemos nada específico en el lenguaje para expresar un filtro como este, pero aún podemos filtrar nuestros datos utilizando argumentos. El join nos permite seleccionar datos en varias tablas. Con GraphQL, en realidad construyes la lógica de unión en tu esquema. Por lo tanto, el escritor de la consulta no tiene que saber nada sobre cómo unir datos para beneficiarse de la capacidad de consultar datos unidos. De hecho, creo que la experiencia de GraphQL aquí es mucho mejor para el explorador de datos que la experiencia de SQL, porque no estás reconstruyendo tu lógica empresarial en torno a las uniones. Y luego, lo último que quiero señalar por ahora es esta capacidad de agrupar y contar. Esta idea de que tenemos agregación y funciones de matriz que podemos aplicar a nuestras consultas es algo que realmente extraño en GraphQL. Si quieres consultar algo que se calcula, debes incluir esos campos calculados en tu esquema, lo que significa que debes anticipar sus necesidades, lo cual puedes hacer para aplicaciones como la construcción de diseños y clientes, pero no puedes anticipar exhaustivamente todas las necesidades que alguien tendrá cuando simplemente esté navegando casualmente por tus datos. Así que volviendo a nuestra pregunta de si GraphQL puede ser la forma de crear un punto de acceso universal para nuestros datos, creo que las principales preocupaciones al adoptar este enfoque se desglosarán en tres categorías que quiero analizar juntos. ¿Puedo optimizar mis consultas lo suficiente como para que tenga sentido? GraphQL se construye sobre cualquier cosa, o podría construirse sobre cualquier cosa. Por lo tanto, será importante considerar que es posible que queramos consultar grandes cantidades de datos. En segundo lugar, ¿puedo expresar lo que quiero expresar? Creo que esto se reduce a lo que te mostré con la consulta SQL, donde GraphQL simplemente carece de elementos de cálculo en el propio lenguaje. Y en tercer lugar, ¿puedo ver las cosas de la manera que quiero?
2. Optimización de Consultas GraphQL
Las consultas GraphQL se pueden optimizar mapeándolas directamente a consultas de bases de datos eficientes, lo cual es el enfoque más eficiente. Herramientas como JoinMonster ayudan en este proceso. Para obtener más información, consulta la publicación del blog de Marc-Andre Giroux.
Y lo que tengo en esta diapositiva es un ejemplo de una de esas bibliotecas llamada JoinMonster que hace esto. Pero hay una excelente publicación de blog escrita sobre el tema de GraphQL a SQL, específicamente, que he vinculado aquí en esta diapositiva por Marc-Andre Giroux.
3. Traducción de Consultas Druid a GraphQL
Algo que nos interesa mucho en Apollo es cómo traducir las consultas de Druid a GraphQL. Construimos un traductor de Druid a GraphQL para satisfacer nuestras necesidades de producto. Generamos una parte de nuestro esquema GraphQL a partir de Druid, lo que permite transformar las consultas de GraphQL a Druid. Este enfoque proporcionaba flexibilidad pero tenía desafíos con el formato de los datos de retorno y la ejecución de las consultas.
Algo que nos interesa mucho en Apollo, sin embargo, es cómo traducir las consultas de Druid a GraphQL. Druid es una base de datos de series temporales diseñada para ayudarte a consultar datos analíticos a lo largo de grandes períodos de tiempo. Y en Apollo utilizamos Druid para algunas cosas. De hecho, construimos un traductor de Druid a GraphQL hace un par de años para satisfacer algunas de nuestras necesidades de producto.
Nuestro objetivo era construir una API flexible para consultar estadísticas. Básicamente, generamos una parte de nuestro esquema GraphQL a partir de Druid, de modo que las consultas GraphQL se transformaran en consultas a Druid. Así que quiero mostrarles cómo se ve eso en un ejemplo. Aquí tengo una consulta para datos sobre un servicio. Y la parte del esquema que se traduce a Druid, o se genera a partir de Druid, es la parte de estadísticas del esquema. Y cada campo que puedo consultar en estadísticas corresponde a una tabla en Druid. Así que si quiero consultar las estadísticas de consultas en Druid, puedo hacerlo allí, y eso proviene de la tabla de estadísticas de consultas. Y puedo solicitar el recuento total de solicitudes para este servicio en los últimos cinco minutos, que equivale a los últimos 300 segundos. Y podemos ver que hemos obtenido 2,285 solicitudes para este servicio en los últimos cinco minutos. Ahora, la parte realmente interesante de este esquema es que puedo agregar este campo a mi consulta dentro de group by. Y si selecciono campos dentro de group by, en realidad comenzaré a segmentar los datos en esa consulta. Entonces, mis 2,285 consultas o solicitudes se dividirán en el número de solicitudes que se realizaron para cada consulta. Y cada uno de los elementos por los que puedo agrupar, estos son efectivamente columnas en Druid. Entonces, puedo agrupar por nombre de cliente y segmentar aún más la consulta. Y cuanto más cosas agrupes, más parámetros tendrás, más resultados obtendrás de tu consulta. Así que esto se mapea directamente a Druid. Diría que esto funcionó extremadamente bien en cuanto a la flexibilidad. Porque puedes hacer consultas a Druid, lo cual no habría podido hacer de otra manera sin
4. Flexibilidad y Traducción de GraphQL
Las consultas flexibles permiten una rápida iteración con el trabajo de funciones. Sin embargo, este enfoque tiene sus pros y contras. Es posible traducir GraphQL a otros lenguajes, pero las preocupaciones de la API y la analítica tienen objetivos diferentes. La latencia de la solicitud es menos importante en la analítica de datos, donde se prioriza la transmisión y el escaneo de grandes resultados de datos.
5. Usando Directivas y GraphQL LowDash
GraphQL tiene un concepto llamado directivas, que se pueden aplicar a consultas y esquemas. Un proyecto, GraphQL LowDash, implementa funciones para transformar matrices de objetos. Proporciona soporte para aplicar funciones de LowDash a consultas a través de directivas. Se muestra un ejemplo utilizando el gráfico de GitHub, consultando los problemas más votados en el repositorio del servidor Apollo.
LowDash es una biblioteca de utilidades en JavaScript, e implementa una gran cantidad de funciones para transformar matrices de objetos. Estas funciones incluyen filtrar, contar, mínimo, máximo, ordenar, invertir, todo tipo de cosas. Y GraphQL LowDash es un paquete de nodo. Y puedes agregarlo a tu servidor, y lo que hará es proporcionar soporte para aplicar funciones de LowDash a tus consultas a través de directivas para que puedas transformar los resultados de tus consultas. Y para mostrarte realmente lo que está sucediendo con GraphQL LowDash, pensé que podríamos saltar a otro ejemplo. Y mi gráfico favorito para consultar es el gráfico de GitHub. Así que pensé que podríamos intentar hacer la pregunta de análisis del gráfico de GitHub, que es cuáles son los problemas más votados en el repositorio del servidor Apollo. Así que aquí he comenzado con una consulta para el repositorio del servidor Apollo. He pedido una lista de problemas. Y en cada problema, en realidad podemos consultar las reacciones que las personas han tenido hacia ese problema. Así que pensé que una buena manera de representar los votos sería que las personas proporcionaran una reacción de pulgar hacia arriba en los problemas. Entonces, si miramos nuestros datos, puedes ver que tenemos pulgares hacia arriba aquí, tenemos ojos. Y lo que quiero hacer es transformar este resultado en la respuesta a nuestra pregunta. Entonces, lo primero que voy a hacer es mapear esta matriz de bordes para intentar contar el número de reacciones de pulgar hacia arriba que tenemos. Entonces, en bordes, voy a decir vamos a mapear esto a node.content. Y si vuelvo a ejecutar esta consulta, verás que ahora esa matriz es mucho más simple. No es una matriz de objetos. Es solo una matriz de cadenas. Y en realidad, en lugar de mapear, si cuento por node.content, obtendremos un recuento real del número de reacciones. Así que ahora sabemos cuántos pulgares hacia arriba tenemos, cuántos ojos tenemos como reacciones, pero aún no sabemos cuáles son nuestros problemas. Así que pidamos los títulos de estos problemas. Y no quiero en mis resultados un tipo de objeto de reacciones. Quiero un solo número que represente los votos. Así que voy a obtener
6. Transformando Datos y Accesibilidad en GraphQL
En este ejemplo, transformamos los datos mediante mapeo, ordenamiento y filtrado para obtener el resultado deseado. La capacidad de aplicar transformaciones a los resultados de las consultas es poderosa, pero puede romper el principio de GraphQL. Si bien es adecuado para analizar datos dentro de la consola, no se recomienda para el desarrollo de aplicaciones. Si necesitas campos calculados, deben estar integrados en tu esquema. Por último, la accesibilidad de GraphQL para personas no desarrolladoras es un desafío debido a la complejidad del lenguaje.
7. Trabajando con Respuestas de GraphQL
Hoy quiero centrarme en compartir algunas ideas sobre cómo trabajar con las respuestas de las consultas de GraphQL. JSON es un formato hermoso para los desarrolladores y las APIs, pero no se utiliza comúnmente fuera del mundo del desarrollo. Quiero mostrarte el modo Tabla, que te permite interactuar con los datos JSON de una manera más amigable para el usuario. Al hacer que nuestras herramientas sean más accesibles, permitimos a las personas ir más allá de lo que se puede hacer con código. GraphQL puede tener un impacto significativo en las organizaciones más allá de solo ayudar a los desarrolladores a ser más productivos.
Y cuando hablamos de respuestas de API, al menos las de GraphQL, estamos hablando de trabajar con datos JSON. JSON es un formato hermoso para los desarrolladores y las APIs porque puedes expresar objetos complejos, es legible para los humanos y es básicamente aceptado y utilizable universalmente en nuestro código. Pero el problema con JSON es que es algo muy centrado en los desarrolladores y no es muy común trabajar con él fuera del mundo del desarrollo. Por lo general, cuando hablamos de conjuntos de datos, hablamos de tablas y CSV y cargar cosas en Excel. Y convertir JSON en tablas generalmente requiere código porque no es necesariamente una transformación obvia. Y si no te sientes cómodo escribiendo código, entonces te quedas atascado. Así que mi última demostración aquí es bastante rápida, pero solo quiero mostrarte a todos que hay más en la navegación de respuestas de GraphQL que simplemente desplazarse por largas matrices de datos JSON. Y quiero animarte a esperar siempre más de tus herramientas. Entonces, si volvemos a nuestro ejemplo de GitHub, quiero mostrarte rápidamente el modo Tabla, que es una idea de que podrías generar una tabla lo mejor que puedas a partir de los resultados JSON y dar a las personas algunas herramientas para interactuar con sus datos de una manera que no sea JSON. Así que, con el modo Tabla aquí, podemos ordenar nuestras columnas alfabéticamente por título. También podemos ordenar nuestros votos, lo que nos habría evitado tener que agregar esta directiva de ordenamiento. También puedo descargar estos datos a un CSV si quisiera y moverlo a otra herramienta. Al incorporar la accessibility en nuestras herramientas de esta manera, permitimos a las personas ir más allá, ya sabes, de lo que se puede hacer con código. Así que veo muchas ventajas en hacer que nuestras herramientas sean más accesibles de esta manera. El modo Tabla es mucho más fácil de analizar para los casos de uso de los desarrolladores. Y algo como esto naturalmente se sentirá más familiar y acogedor para todos los demás. Y no veo muchas desventajas en incorporar cosas en nuestras herramientas de esta manera, aparte de la eventualidad de que no queremos sobrecargar nuestras herramientas con demasiadas cosas y hacerlas demasiado ocupadas para cualquier caso de uso en particular. Pero más allá de trabajar con datos y tu editor, he visto a personas crear integraciones entre GraphQL y otras herramientas que ya son familiares en sus flujos de trabajo, como Tableau. Y encuentro ese tipo de integraciones y ese tipo de pensamiento realmente inspirador. Entonces, al finalizar, quiero dejarte a todos con esta idea. GraphQL puede tener un impacto en tu organización mucho más allá de ayudar a tus desarrolladores a ser más productivos. He hablado con gerentes de producto que usan un Graph para incluir consultas en las especificaciones de sus productos para iniciar proyectos, y diseñadores que les gusta explorar el Graph para descubrir qué datos pueden agregar a los bocetos. He enseñado a nuestro equipo de éxito del cliente cómo usar el Graph para ejecutar mutaciones de administrador que aún no existen en nuestra aplicación de administración. Y aspiro a enseñar algún día incluso a tu equipo de ventas cómo usar el Graph para buscar información en nombre de sus cuentas. Si nuestras herramientas se vuelven lo suficientemente accesibles y nuestros esquemas están bien diseñados y bien construidos, tal vez ni siquiera necesitemos muchas de nuestras integraciones y aplicaciones de administración en el futuro
8. Animo para Diseñar un Esquema Flexible
Te animo a diseñar tu esquema con flexibilidad, esperar más de tus herramientas y compartir tu Graph con tu organización. Prueba la herramienta Explorer en Apollo Studio.
QnA
Q&A sobre graphql-loadash y Explorer
Si tienes alguna pregunta, no dudes en mencionarme en el Discord de la conferencia o contactarme en Twitter o hacerla en la sección de preguntas y respuestas. Las funciones add underscore vienen con un paquete llamado graphql-loadash, que no se empaqueta directamente con Apollo Server. La mayoría de mi uso de graphql-loadash ha sido en el frontend, en el explorer. No hay problemas de rendimiento notables con graphql-loadash. Tengo un sueño de tener gráficos en el explorer, pero actualmente no está disponible.
Haciendo que GraphQL sea accesible y su potencial
Gran parte de la inspiración para hacer que GraphQL sea más accesible proviene de mi experiencia consumiendo APIs de GraphQL durante los últimos cuatro años. Las personas querían que sus herramientas fueran más accesibles, especialmente al comenzar. Hemos visto cómo las personas integran GraphQL en herramientas como Tableau. Para utilizar GraphQL como una herramienta genérica de consulta de datos, las APIs deben diseñarse de manera que lo permita. La especificación de GraphQL es consistente, de tipado fuerte y ampliamente adoptada en el mundo del desarrollo.
Y lo que hemos hecho en Apollo, relacionado con esta charla, es realizar investigaciones con usuarios sobre cómo las personas comienzan a utilizar GraphQL y escriben consultas en general a medida que avanzan en su viaje con GraphQL. Y cuando realizamos esa investigación de usuarios hace aproximadamente un año, descubrimos que las personas querían que sus herramientas fueran más accesibles, especialmente al comenzar, porque GraphQL en sí mismo es como un lenguaje. Es como código. Tienes que aprender cómo escribirlo. Y hay muchas personas que podrían beneficiarse de ver data si solo pudieran escribir consultas, pero se intimidan al ver un editor en blanco que les dice que escriban algo de código para hacer algo. Entonces, gran parte de lo que hemos hecho se basa en una investigación que realizamos en Apollo para hacer que GraphQL sea más accesible, para hacer que los datos en tu API sean un poco más descubribles, pero sí, gran parte de esto es algo que se me ocurrió a mí. Diré que sí a eso. Bueno, podrías haber dicho simplemente sí. Lo siento. Estamos buscando una respuesta larga. Queremos tener tu opinión y por eso te tenemos aquí hablando. Solo estoy bromeando contigo. Tenemos una pregunta de Hoang, gracias por la charla, estuvo genial. ¿Crees que GraphQL podría ser realmente una solución accesible o preferirías usar otra herramienta para acceder a los datos? Entonces, como usar GraphQL en lugar de otra herramienta como Tableau o algo para acceder a los datos, lo interpretaré de esa manera. Creo que GraphQL puede convertirse en la forma en que accedes a los datos de manera genérica. Esa es la imagen que intenté pintar con la charla. Y he visto a personas usar GraphQL e integrarlo en una herramienta como Tableau. Me pareció realmente inspirador e interesante. Creo que para llegar a ese punto, necesitamos diseñar las APIs de una manera que permita su uso de esa manera. No creo que GraphQL por sí solo pueda ser utilizado como una herramienta genérica de consulta de datos. Creo que debes usar GraphQL para construir tu API en una herramienta genérica debido a los puntos que mencioné sobre el rendimiento y el diseño del esquema que se utiliza de manera flexible, entre otras cosas. Ser clave para hacer que tus datos sean más accesibles en general. Pero creo que se puede usar. Creo que el hecho de que la especificación de GraphQL sea consistente y de tipado fuerte y ya esté tan adoptada en el mundo del desarrollo, todo lleva a la conclusión de que se puede utilizar de esa manera.
Implementando GraphQL en Empresas
La charla presenta una visión para utilizar la API de GraphQL en su máximo potencial. La implementación depende de las prácticas individuales de cada empresa, pero la clave es diseñar el esquema de manera flexible y traducirlo directamente a consultas de base de datos, lo que resulta en un mejor rendimiento y una mayor adopción dentro de la organización.