GraphQL nativo, GraphQL como lenguaje de consulta de base de datos

Hola a todos, soy Brichts, estoy muy emocionado hoy de hablar en la conferencia GraphQL Galaxy. Soy Databrichts en Twitter, trabajo para la base de datos Vana y hoy voy a hablar sobre NativeGraphQL o GraphQL como lenguaje de consulta de base de datos.

Ahora, si hablamos de Native GraphQL en VANA, ¿qué significa? Bueno, en primer lugar, tenemos un lenguaje de consulta VANA que llamamos FQL y básicamente NativeGraphQL significa que una consulta GraphQL se traduce en una consulta FQL. Esta traducción uno a uno tiene enormes ventajas, así que primero, te preguntarás qué ventajas tiene, vamos a ver eso, y la pregunta 2, ¿por qué no todos hacen esto si hay tales ventajas?

Para responder a estas preguntas, en realidad tenemos que responder otras preguntas como ¿cómo funcionan los resolutores de GraphQL? Así que hagamos un desvío. ¿Cómo funcionan los resolutores de GraphQL? Bueno, típicamente, si tienes una consulta como esta con getList, toDo, title, cada campo aquí, como getList y toDo's y title son campos, se asignarán a una función. Así que getList será una función y delegará en la función toDo's, que a su vez delegará en la función title, por ejemplo, en el atributo title. Esta es una cadena de resolutores, que es una cadena de funciones, pero en realidad es más un árbol de resolutores de llamadas a funciones.

Porque aquí hay una función que llama a n funciones. Y si invertimos esto, obtenemos n más 1 y básicamente es un problema. Y esto se llama el problema de n más uno. Por eso lo invertí. ¿Y cuándo es esto un problema? Bueno, básicamente, si vas a llamar a la base de datos para cada uno de estos resolutores, porque entonces obtienes n más uno llamadas a la base de datos, lo cual no es eficiente. Así que la pregunta cuatro, ¿cómo podemos resolver el problema de n más uno? Bueno, hay múltiples soluciones. La solución uno es la agrupación o el almacenamiento en caché en memoria. Así que en ese enfoque, vamos a engancharnos en estas funciones, por ejemplo, todo.titles, y simplemente esperar hasta que se llamen todos los todo.titles y luego combinarlos. Así que en lugar de hacer n llamadas para estos todo.titles, vamos a hacer una llamada. Así que en total, dos llamadas. Eso es agrupación y a menudo se combina con el almacenamiento en caché. Así que si llega una llamada similar, en lugar de ir a la base de datos, podemos ir a una caché en memoria, por lo que no accedemos a la base de datos en absoluto.

Una implementación muy popular es el data loader de Facebook, que puedes conectar fácilmente a tus resolutores y se encargará de ello. Sin embargo, también hay un problema con esta solución. Debería ser en realidad el último recurso. ¿Por qué? Tus datos ya no están en vivo. Ya no son consistentes. No se puede aplicar a todo. No se puede agrupar todo. Así que seguirás teniendo múltiples llamadas. ¿Qué pasa con la validación de caché, la presión de memoria con la que de repente tienes que lidiar? Así que introduce complejidad. La primera pregunta, ¿qué ventajas proporciona el enfoque de VANA? Bueno, no trata con estos problemas porque no tiene estos problemas.

Está activo por defecto. Es consistente. No requiere trabajo adicional. Y no hay problema de restricción de memoria. Simplemente funciona de inmediato. Así que no tienes que hacer esto.

Solución dos, generar una consulta, que es lo que FANAS hace en segundo plano. Pero ¿por qué no todos hacen eso? Si miráramos SQL, por ejemplo, y digamos que seleccionamos un asterisco de listas donde el ID es igual a algo, luego iríamos a las llamadas de tareas por hacer y haríamos lo mismo y trataríamos de concatenar esa consulta. Por supuesto, tendríamos que hacerlo para múltiples tareas por hacer, por lo que terminaríamos con una unión. Y el problema es que si nos adentramos así en un recorrido de GraphQL, podríamos terminar con muchas uniones. Ahora, no solo es súper complejo analizar esta consulta y luego generar SQL a partir de ella y luego transformar los resultados de nuevo a un formato de GraphQL, sino que también podría ser ineficiente dependiendo de las uniones. Podrías obtener mucha información innecesaria y luego tener que descartar cosas. Y luego, ¿cómo vamos a paginar esto? Limitar a 100 puede que no sea exactamente lo que estás buscando. Entonces, el problema aquí es que lo que las uniones resuelven, que es una unión entre dos tablas, es un problema diferente al problema real, que es más como un problema de recorrido de árbol o un problema similar a un grafo. Entonces, las uniones pueden ser la herramienta equivocada para el trabajo.

Entonces, existe una implementación, una implementación muy impresionante, llamada JoinMonster, que en realidad surge del problema que están tratando de resolver. Una unión monstruosa que podría ser el resultado de una consulta GraphQL. Si observamos el trabajo involucrado, podemos ver que es un problema complejo de resolver. Esa es la pregunta 4, ¿cómo podemos resolver el problema de n más uno, las dos soluciones? Eso nos lleva de vuelta a la pregunta 2, ¿por qué no todos hacen esto? Bueno, acabamos de mostrarlo, el lenguaje de consulta puede que no se ajuste al problema o el plan de ejecución puede que no se ajuste al problema. Y, por supuesto, ¿por qué FQL se ajusta al problema? Bueno, lo hacemos de manera bastante diferente porque es un lenguaje de consulta diferente y tiene propiedades bastante similares a un grafo. Si miramos la misma consulta, comenzaríamos obteniendo una lista con match, index y el ID de la lista. Inmediatamente lo envolveríamos en paginate, por lo que en realidad tendremos paginación en cada nivel, y una paginación muy sensata con un cursor después y antes que siempre es correcto. Luego simplemente mapeamos los resultados de estas listas y llamamos a una función. Eso es en realidad como un lenguaje de programación normal, donde simplemente mapearías algo y luego llamarías a la función. En esa función podemos hacer lo que queramos y si miramos las tareas por hacer allí, bueno, ¿qué es esto? Es solo una función de JavaScript porque estoy usando el controlador de JavaScript para FQL, donde simplemente lanzamos más FQL. Composición de funciones puras. Luego vemos el mismo patrón, paginar y mapear. Así que tenemos el segundo nivel de paginación de inmediato y mapear y nuevamente una función que se llamará. Esto es en realidad un recorrido similar a un grafo que estamos implementando en FQL. Debido a que eso es posible, fue muy fácil para Fana implementar esa traducción uno a uno de GraphQL a FQL. Entonces, ¿qué está sucediendo realmente aquí, si observamos la ejecución de la consulta, es que mapeamos get sobre todas las listas, luego paginamos eso de inmediato y luego simplemente continuamos mapeando obteniendo y paginando en cada nivel. No hay problema de unión monstruosa porque lo hacemos de manera completamente diferente, por lo que no tenemos que resolver el problema. Entonces, la pregunta cinco, eso es por qué FQL se ajusta al problema. Volviendo a la pregunta uno, ¿qué ventaja trae eso, porque hemos mencionado ventajas pero hay otras? Debido a que tenemos las mismas ventajas que el resto del lenguaje FQL nativo normal, podemos combinar eso con FQL y usar FQL por su flexibilidad y potencia, y GraphQL por su facilidad de uso. Tenemos escalabilidad multi-región de inmediato, escalabilidad de inmediato, tenemos ACID al 100% y transaccionalidad de inmediato. Eso es lo que es el GraphQL nativo. Espero que te guste esa idea y si quieres probarlo gratis, visita fana.com.