GraphQL para Todos - Danielle Man

¡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?

¿Los ves? GraphQL fue diseñado para ser utilizado por desarrolladores. Por lo tanto, no es lo más accesible para personas del mundo de los datos que son muy técnicas pero están acostumbradas a trabajar con datos en formatos de tabla y hacer cosas como Excel, aplicar fórmulas de Excel y ser técnicas de esa manera. Así que recorramos esto juntos y hablemos sobre si estos obstáculos se pueden superar con GraphQL. Entonces, esta primera pregunta de si puedo optimizar mis consultas GraphQL lo suficiente para que tenga sentido. Lo que realmente me viene a la mente con esto es si podemos proporcionar un mapeo de nuestras consultas a una implementación que sea eficiente. GraphQL agrega esta capa de procesamiento en tu stack. Entonces, lo mejor que podemos intentar hacer es hacer que esa capa sea lo más delgada posible y evitar agregar procesamiento adicional en la capa de GraphQL. E idealmente, podemos tomar las consultas de GraphQL que llegan y mapearlas directamente a consultas de base de datos, lo cual garantiza el resultado más eficiente. Y hay muchas herramientas que hacen esto o que te ayudan a hacer esto específicamente con SQL que están disponibles. Incluso hay empresas que construyen un GraphQL sobre SQL como un servicio. Y en todas esas herramientas, lo que estás tratando de hacer es tomar tu consulta GraphQL y identificar la consulta SQL precisa que se debe realizar para obtener los datos solicitados.

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.

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

necesidad de saber cómo conectarse a la base de datos Druid. Las consultas flexibles también nos permiten iterar rápidamente con nuestro trabajo de funciones. Porque no tuvimos que saber cuáles eran nuestros objetivos finales precisos para comenzar. Y este esquema generado era bueno para mantenerse actualizado. Porque cada vez que agregábamos una nueva columna a una tabla, eso se incluiría automáticamente en el esquema. Por otro lado, creo que todavía está por verse si esto realmente cubría nuestras necesidades de producto. Fue un gran problema que nuestros datos de retorno no estuvieran en el formato adecuado para los diseños de nuestros clientes, porque aún teníamos que realizar muchos cálculos en nuestro frontend para obtener nuestros datos en las formas que necesitábamos. Y creo que el mayor anti-patrón de esto es que fue confuso. Que si agregabas campos bajo group by, en realidad ibas a afectar directamente cómo se ejecutaba la consulta y los datos que obtenías. Esto resultó ser algo intuitivo para muchos de nuestros compañeros de equipo, que esperarían que algo así se colocara en un argumento en su lugar. Entonces, creo que hay pros y contras en un enfoque como este. Pero el punto es que es posible traducir GraphQL directamente a otros lenguajes, especialmente lenguajes de bases de datos complejos. Y antes de pasar al tema de la optimización de consultas, solo quiero destacar que las preocupaciones de la API serán diferentes de las preocupaciones de la analítica. Los esquemas de GraphQL suelen construirse como API. Por lo tanto, es común tener cosas como paginación y otros tipos de limitaciones incorporadas. Pero si estás intentando hacer análisis de datos, la latencia de la solicitud no será tan importante como poder transmitir grandes resultados de datos y escanear matrices realmente grandes de datos. Entonces, estas dos cosas, estos dos mundos, en realidad tienen objetivos que compiten de alguna manera. Y eso es algo que debes tener en cuenta.

solo tendrá que lidiar con. Entonces, pregunta número 2. ¿Puedo expresar lo que quiero expresar? Creo que lo interesante de esto es que a pesar de que el lenguaje no tiene funciones de conteo y agregación incorporadas, GraphQL tiene este concepto llamado directivas que se pueden aplicar tanto a consultas como a esquemas. Y básicamente puedes definir lógica y funciones en directivas. Y si las aplicas a tus consultas, eso le dará al esquema alguna indicación sobre cómo se debe ejecutar la consulta. Y hay muchas cosas interesantes que la gente ha hecho con directivas, incluyendo cosas relacionadas con la autenticación y el salto, incluyendo el aplazamiento de campos. Pero lo que quería mostrarte hoy en el espíritu de lo que estamos hablando con la flexibilidad de las consultas es un proyecto llamado GraphQL LowDash.

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

edges.thumbs-up aquí. Y voy a alias este campo como reacciones a votos. Porque hemos decidido que un pulgar hacia arriba es un voto. Y ahora que tengo mi matriz de data básicamente eso que quiero, quiero transformarlo en algo que sea un poco más fácil de analizar. Así que no quiero realmente este tipo de objeto nodo como intermediario entre mi matriz y el título y votos y mis problemas. Así que para mi matriz de bordes voy a mapear solo mi nodo. Y lo que realmente quiero hacer es ordenar esta matriz en orden descendente para poder ver el problema más votado. Así que voy a ordenar por votos para mi matriz. Y parece que la ordenación por defecto es ascendente, lo cual tiene sentido. Así que voy a invertir esta matriz. Y parece que tengo algunos problemas aquí que no tienen ningún voto en absoluto, lo cual también tiene sentido. Así que voy a filtrar solo los problemas con votos. Y ahora tenemos la respuesta a nuestra pregunta. El problema más votado aquí es un problema de playground de Apollo server fastify. Si queremos investigar esto más, puedo obtener la URL y seguirla. Pero tenemos que volver a la presentación. Así que hay algunas cosas que quiero señalar de este ejemplo. La capacidad de agregar, agrupar y aplicar transformaciones a los resultados de las consultas es algo realmente poderoso en mi opinión. Esto es lo que te permite hacer preguntas a tus data y obtener respuestas dentro del contexto de tu herramienta. Sin tener que sacar tus data de esa herramienta y moverla a otra herramienta. Esto también es lo que permite a las personas usar tu esquema más allá de lo que puedas haber imaginado y construido en tu esquema a través de campos calculados. Por otro lado, GraphQL LODASH no es particularmente intuitivo. Me ha llevado varias horas de experimentación sentirme cómodo con él. E incluso ahora no soy un experto. Y lo más importante que quiero señalar sobre este ejemplo es que transformar nuestros data de esta manera realmente rompe un principio de GraphQL, que dice que las respuestas deben ser congruentes con las consultas que se enviaron. Así que para casos de uso como este, donde estás escribiendo consultas para analizar data dentro de la consola, no creo que sea un gran problema porque no estás sacando esa experiencia fuera de la ventana única. Pero si intentáramos realmente tomar esta consulta y ponerla en nuestro código, ahí es donde nos meteríamos en problemas y las cosas se pondrían complicadas porque otras herramientas para desarrolladores como la generación de código van a depender de que nos mantengamos en conformidad con las especificaciones. Esto es algo que me encanta, pero no recomendaría usarlo para el desarrollo de aplicaciones. Si necesitas campos calculados allí, debes construirlos en tu esquema. Y finalmente, nuestra tercera pregunta, ¿cómo veo las cosas de la manera que quiero verlas? Como mencioné anteriormente, lo que más me motiva de GraphQL es esta oportunidad que veo de hacer que los data sean más accesibles. Y creo que el último gran problema que tenemos que abordar es si GraphQL en sí mismo será lo suficientemente accesible para ser utilizado por personas que no son desarrolladoras. Es realmente difícil mirar un editor en blanco y comenzar con una consulta cuando ni siquiera sabes

lo que es el lenguaje. Podría dar una charla separada sobre la construcción de consultas y el aspecto de descubrimiento de datos al navegar por los datos. Aquí tengo una imagen del Explorador de GraphiQL a la izquierda y del Explorador de Studio a la derecha, ambos han pensado mucho en cómo ayudarte a escribir consultas sin necesidad de saber exactamente qué escribir. Pero desafortunadamente, hoy no tenemos suficiente tiempo para profundizar en la construcción de consultas. En su lugar, quiero compartir algunas ideas contigo sobre cómo trabajar con las respuestas de nuestras consultas.

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

porque todos podrían simplemente usar el Graph. Así que te animo a todos a pensar en cómo diseñar tu esquema con flexibilidad para que se pueda utilizar más allá de las formas que has imaginado hasta ahora. Te animo a seguir esperando siempre más de tus herramientas, especialmente cuando se trata de hacerlas más accesibles para diferentes grupos de personas. Y sobre todo, te animo a compartir tu Graph con toda tu organización y a hacer el trabajo para que tu Graph funcione para todos. Si estás interesado en probar lo que he estado mostrando, esa es la herramienta que mi equipo construye llamada Explorer en Apollo Studio.

y es gratuito para usar. Muchas gracias a todos por sintonizar y escuchar. 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. Mis mensajes directos están abiertos y espero verte en internet. ¡Hola, excelente charla y sin más preámbulos, creo que deberíamos pasar directamente a las preguntas del público y la primera pregunta es de Rada. Oh, disculpa, estaba mirando las preguntas equivocadas. Es de Nikin. ¿Se necesita alguna implementación adicional para usar las funciones add underscore o vienen con Apollo Server? Sí, esa es una excelente pregunta. Es un conjunto de directivas que vienen con un paquete llamado graphql-loadash y graphql-loadash no se empaqueta directamente con Apollo Server pero definitivamente puedes usar estas dos cosas juntas. Graphql-loadash es solo su propio paquete de npm. Pero la herramienta que les estaba mostrando para escribir esas consultas se llama, la llamamos el explorer, está en Apollo Studio y si haces una consulta a través del explorer, el explorer extiende automáticamente el esquema que estás usando con esas directivas. Por lo tanto, puedes hacer consultas en el frontend con graphql-loadash utilizando el explorer pero si estás utilizando otra herramienta de consulta, necesitarías agregar eso a tu servidor. De acuerdo. Gracias por la pregunta, Deegan. La siguiente pregunta es de TheWorstDef, ese es un gran apodo. ¿Hay algún problema de rendimiento notable con graphql-loadash? Esa es una buena pregunta. La mayoría de mi uso de graphql-loadash ha sido en el frontend, en el explorer. Y las ocasiones en las que ha sido lento es cuando estás consultando una gran cantidad de datos que luego transformas en el frontend. Y la lentitud en ese caso, no se debe a graphql-loadash. Principalmente se debe a la gran cantidad de datos que se envían por la red. Pero imagino que si colocas graphql-loadash en tu servidor, sería mucho mejor, con un rendimiento diferente y mejor. Pero los desafíos que tendrás allí, si usas graphql-loadash y lo proporcionas a tus clientes, entonces estarás rompiendo la especificación de otras formas. Por lo tanto, debes ser específico acerca de dónde lo usas y por qué eliges usarlo. De acuerdo, y luego el peor desarrollador, que ahora espero sea el mejor desarrollador, tiene una pregunta de seguimiento también. ¿Qué otros tipos de visualizaciones tienen sentido? ¿Alguna vez habrá gráficos en el Explorer? Tengo un sueño de que algún día haya gráficos en el Explorer, pero actualmente no los hay. Pero puedes imaginar todo tipo de cosas. Si obtienes un array de datos y son todos números, ¿por qué no te daríamos un gráfico? ¿Por qué no tendríamos formas de transformar tus resultados para verlos de manera más visual? Así que sí, tener gráficos en el Explorer es como un sueño para mí, aunque llevarlo a cabo y hacerlo práctico para todos y como un caso de uso genérico podría ser un problema un poco desafiante. Pero no es algo que no se pueda hacer. Tienes que establecer un estándar muy alto para ti mismo y hacer que funcione. Pero tal vez el peor desarrollador pueda ayudarte. Es cierto. También estaba pensando mientras veía la charla, ¿esta forma de trabajar es algo que se te ocurrió a ti o es algo que estás haciendo en Apollo o

tal vez en uno de tus empleadores anteriores? Sí, sí, esa es una gran pregunta. Gran parte de la inspiration para las ideas de esta charla sobre hacer que GraphQL sea más accesible para personas que recién comienzan y para personas desde la perspectiva de escribir consultas proviene de mi propia experiencia consumiendo APIs de GraphQL durante los últimos cuatro años para construir aplicaciones. Siempre he sido un desarrollador de frontend. Siempre he venido desde la perspectiva de escribir consultas, no de construir esquemas y mi experiencia en la construcción de esquemas es mucho más reciente que mi experiencia en aprender GraphQL a través del mundo de las consultas.

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.

De acuerdo. Luego tenemos una pregunta más. Oh, ¿cómo ves que lleguemos desde donde estamos ahora hasta trabajar de la manera propuesta y cómo implementarías esto en una empresa? Sí. Bueno, mi charla trata de pintar una visión de lo que la API de GraphQL podría ser utilizada para hacer. Pero no prescribe necesariamente cómo llegar allí, porque creo que siempre dependerá de cómo hace las cosas tu empresa y qué es lo correcto para tu empresa. Pero creo que lo que quiero que todos ustedes entiendan es que deberían pensar en que su API pueda ser utilizada de esta manera para que puedan diseñar su esquema de una manera más flexible. Puede ser traducido más directamente a consultas de base de datos y tener un mejor rendimiento. Y si llegamos a ese punto cada vez más y más, entonces más y más personas en sus empresas podrán usarlo y habrá un interés natural. Entonces, creo que la forma de llegar allí no es una fórmula prescriptiva. Es un modelo mental y una forma de pensar que debes adoptar y llevar a tus empresas. De acuerdo. Luego una pregunta más. Creo que es la última pregunta a la que tenemos tiempo para responder. Es de, voy a hacer mi mejor esfuerzo para pronunciar esto. Sneha Siv. Con GraphQL... Entonces, retrocedamos. Con la flexibilidad de GraphQL, ¿ves alguna preocupación con GraphQL LowDash y las consultas costosas que pueden hacer los clientes o hay soluciones alternativas posibles? Bueno, sí, veo una preocupación con las consultas costosas que pueden hacer los clientes. Y ahí es donde creo que entra en juego la línea de código donde haces todo lo posible para traducir tu esquema en consultas de base de datos, porque si tienes tus consultas de esquema o tus consultas de GraphQL en tu esquema traduciéndose más directamente al lenguaje de tu base de datos, entonces el costo de lo que el cliente podría estar solicitando se transferirá a la base de datos, que creo que es el mejor escenario porque eso es para lo que están diseñadas las bases de datos. Veo a GraphQL LowDash como una especie de puente para brindarte más flexibilidad en el esquema sin que ya esté presente. No recomendaría necesariamente que alguien comience a depender de GraphQL LowDash para desarrollo real. Si necesitas que tu aplicación haga algo y estás escribiendo consultas en una aplicación real, debes diseñar tu esquema para que tenga lo que tu aplicación necesita. Si solo estás tratando de proporcionar tu esquema como una forma de acceso general a los datos y consultas ocasionales a través de algo como GraphQL o el Explorador, creo que GraphQL LowDash puede ser útil para eso porque te brinda flexibilidad que tal vez no tenías en cuenta. Entonces, sí, veo problemas con que sea costoso. Es por eso que esto es más una idea, sin embargo, que una forma prescriptiva de recomendar cómo hacer las cosas. Sí. De acuerdo. Creo que eso es todo el tiempo que tenemos. Tenemos una pregunta más, que es para mí y simplemente la voy a compartir. Es de Josh y quiere saber sobre mi experiencia. Así que, tengo un hermoso planeta en forma de dona y así es como se ve la Tierra desde lejos en la galaxia. Así que, solo busca `planeta en forma de dona` en Google y lo encontrarás, Josh. Daniel, muchas gracias por unirte a nosotros. Vas a quedarte con nosotros un poco más para el panel de discusión que viene a continuación en este momento. Pero primero, vamos a ver los resultados. No, vamos a ver algo más. Así que, nos vemos en un momento. Gracias. Gracias por tenerme.