A estas alturas espero que ya hayas tenido la oportunidad de echar un vistazo a mi anterior tutorial titulado, Uso de GraphQL con Golang y una base de datos NoSQLque es más o menos una guía rápida para utilizar GraphQL con Couchbase. Allí vimos cómo crear un esquema GraphQL que permitía consultas de sólo lectura y mutaciones contra los datos. Sin embargo, las consultas no se diseñaron de forma eficiente en torno a las posibles relaciones entre los datos.
Vamos a ver cómo manejar y definir relaciones entre modelos de datos utilizando GraphQLCouchbase y el lenguaje de programación Go.
En el ejemplo anterior habíamos creado dos objetos GraphQL en torno a cuentas y blogs con el siguiente aspecto:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
accountType := graphql.NuevoObjeto(graphql.ObjectConfig{ Nombre: "Cuenta", Campos: graphql.Campos{ "id": &graphql.Campo{ Tipo: graphql.Cadena, }, "nombre": &graphql.Campo{ Tipo: graphql.Cadena, }, "apellido": &graphql.Campo{ Tipo: graphql.Cadena, }, }, }) blogTipo := graphql.NuevoObjeto(graphql.ObjectConfig{ Nombre: "Blog, Campos: graphql.Campos{ "id": &graphql.Campo{ Tipo: graphql.Cadena, }, "cuenta": &graphql.Campo{ Tipo: graphql.Cadena, }, "título: &graphql.Campo{ Tipo: graphql.Cadena, }, "contenido": &graphql.Campo{ Tipo: graphql.Cadena, }, }, }) |
En el ejemplo anterior, habíamos supuesto que el cuenta en el campo blogTipo era una clave para el accountType objeto. De este modo pudimos ejecutar consultas como las siguientes:
|
1 2 3 4 5 6 7 8 9 10 |
{ cuenta(id: "12345") { nombre, apellido } blogs(cuenta: "12345") { título, contenido } } |
El enfoque anterior funciona, pero tenemos que seguir pasando variables en nuestro Consulta GraphQL.
De acuerdo, el esquema en realidad no tiene nada que ver con la consulta anterior. El objeto de consulta es responsable de cómo se realiza la consulta, no el esquema en sí.
Recuerda que habíamos definido consultas que aprovechaban Couchbase como las siguientes:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
"cuentas": &graphql.Campo{ Tipo: graphql.NuevaLista(accountType), Resolver: func(p graphql.ResolverParámetros) (interfaz{}, error) { consulta := gocb.NuevoN1qlQuery("SELECT META(cuenta).id, cuenta.* FROM ejemplo COMO cuenta WHERE cuenta.tipo = 'cuenta'") filas, err := cubo.EjecutarN1qlQuery(consulta, nil) si err != nil { devolver nil, err } var cuentas []Cuenta var fila Cuenta para filas.Siguiente(&fila) { cuentas = añadir(cuentas, fila) } devolver cuentas, nil }, }, |
¿Adónde quiero llegar?
En lugar de crear consultas para cada interacción que queramos realizar, es más fácil incorporarlas al modelo GraphQL. En otras palabras, en lugar de hacer referencia a los modelos por una clave de cadena, ¿por qué no hacer referencia a otro modelo?
Realice la siguiente modificación en el blogTipo objeto:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
blogTipo := graphql.NuevoObjeto(graphql.ObjectConfig{ Nombre: "Blog, Campos: graphql.Campos{ "id": &graphql.Campo{ Tipo: graphql.Cadena, }, "cuenta": &graphql.Campo{ Tipo: accountType, Resolver: func(parámetros graphql.ResolverParámetros) (interfaz{}, error) { blog := parámetros.Fuente.(Blog) var cuenta Cuenta cuenta.ID = blog.Cuenta _, err := cubo.Visite(blog.Cuenta, &cuenta) si err != nil { devolver nil, err } devolver cuenta, nil }, }, "título: &graphql.Campo{ Tipo: graphql.Cadena, }, "contenido": &graphql.Campo{ Tipo: graphql.Cadena, }, }, }) |
Seguimos definiendo cada uno de nuestros posibles campos API, pero también definimos un campo Resolver para la función cuenta campo. Dentro del Resolver podemos obtener los datos del objeto padre, siendo la función blogTipo y utilizarlo para consultar los datos de la cuenta cuando se soliciten.
La consulta GraphQL que vimos anteriormente puede convertirse en lo siguiente:
|
1 2 3 4 5 6 7 8 9 10 |
{ blog(cuenta: "12345") { cuenta { nombre, apellido }, título, contenido } } |
De acuerdo, puede que la consulta anterior no tenga exactamente el mismo significado que la anterior, pero para este ejemplo sí lo tiene. Estamos diciendo que queremos obtener un blog en particular por cuenta. En lugar de proporcionar el id de la cuenta, podemos obtener la información a través de que Resolver que habíamos creado.
¿Este enfoque hace innecesarias las consultas? No, no lo hace porque puede ser necesario realizar consultas de diferentes maneras. Sin embargo, nos permite hacer un tipo de ÚNASE A con GraphQL.
Couchbase tiene N1QL, por lo que no sería un ÚNASE A sería mejor a través de la base de datos y no en el backend? Es decir, aunque hayamos creado relaciones NoSQL con GraphQL, seguimos haciendo numerosas peticiones contra la base de datos. Yo diría que sería mejor para GraphQL hacer JOIN a nivel de base de datos, no a nivel de aplicación. Cuantas menos peticiones, más rápida será la aplicación, ¿no?
Modifiquemos el blogs en nuestra rootQuery objeto:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
"blogs": &graphql.Campo{ Tipo: graphql.NuevaLista(blogTipo), Resolver: func(parámetros graphql.ResolverParámetros) (interfaz{}, error) { consulta := gocb.NuevoN1qlQuery(` SELECCIONE META(blog).id, blog.título, blog.contenido, { META(cuenta).id, cuenta.nombre, cuenta.apellido } AS cuenta DESDE ejemplo AS blog ÚNASE A ejemplo AS cuenta EN TECLAS blog.cuenta DONDE blog.tipo = blog `) filas, err := cubo.EjecutarN1qlQuery(consulta, nil) si err != nil { devolver nil, err } var blogs []Blog var fila Blog para filas.Siguiente(&fila) { blogs = añadir(blogs, fila) } devolver blogs, nil }, }, |
En lugar de añadir un Resolver a la función cuentas en el campo blogTipo lo hacemos todo a través de la consulta. Nuestro blogTipo tendría el siguiente aspecto:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
blogTipo := graphql.NuevoObjeto(graphql.ObjectConfig{ Nombre: "Blog, Campos: graphql.Campos{ "id": &graphql.Campo{ Tipo: graphql.Cadena, }, "cuenta": &graphql.Campo{ Tipo: accountType, }, "título: &graphql.Campo{ Tipo: graphql.Cadena, }, "contenido": &graphql.Campo{ Tipo: graphql.Cadena, }, }, }) |
Si quisiéramos escribir una consulta para esto, podríamos hacerlo fácilmente como la siguiente:
|
1 2 3 4 5 6 7 8 9 10 |
{ blogs { título, contenido, cuenta { nombre, apellido } } } |
La consulta anterior devolvería todos los blogs y los datos de cuenta asociados a ellos. En lugar de hacer una consulta para cada campo, lo hacemos en una sola petición con N1QL.
Couchbase N1QL hace este enfoque más plausible que una base de datos relacional como el esquema flexible que puede ser fácilmente modelado con GraphQL.
Conclusión
Acabas de ver cómo trabajar con tipos de datos relacionados en una aplicación Golang que utiliza GraphQL y la base de datos NoSQL, Couchbase. Con las relaciones GraphQL, puedes crear Resolver para cada campo del modelo o puede crear consultas más complicadas con N1QL y dejar que la base de datos haga el trabajo pesado. En ambos escenarios, el usuario puede solicitar exactamente lo que desea sin tener que preocuparse por una cantidad potencialmente excesiva de puntos finales de API.
Le animo a que consulte mi ejemplo anterior ya que tiene más profundidad cuando se trata de GraphQL con tipos de datos Golang y Couchbase. Usted puede incluso llevarlo más lejos y ver otro ejemplo que escribí titulado, Primeros pasos con GraphQL usando Golang.
Para obtener más información sobre las relaciones de datos y el uso de Couchbase con Go, consulte el artículo Portal para desarrolladores de Couchbase.
