By now I’m hoping that you’ve had a chance to look at my previous tutorial titled, Using GraphQL with Golang and a NoSQL Database, which is more or less a quick start for using GraphQL with Couchbase. In that tutorial we saw how to create a GraphQL schema that allowed read-only queries as well as mutations against the data. However, the queries were not efficiently designed around potential data relationships.

We’re going to see how to improve upon the previous tutorial and handle relationships between the data models using GraphQL, Couchbase, and the Go programming language.

In the previous example we had created two GraphQL objects around accounts and blogs that looked like the following:

In the above example we had assumed that the account field in the blogType object was a key for the accountType object. By doing this we were able to run queries like the following:

The above works and there isn’t really anything wrong with using that approach, but it means that we have to keep passing around variables in our GraphQL query.

Alright, the schema didn’t really have anything to do with the above query. The query object is responsible for how the query performs, not the schema itself.

Remember, we had defined queries that leveraged Couchbase like the following:

So where am I going with this?

Instead of creating a query for every database interaction that we want to accomplish, it might be easier just to bake it into the GraphQL model. In other words, instead of referencing models by a string key, why not just reference another model?

Take the following modification to the blogType object:

We are still defining each of our possible API fields, but we are also defining a Resolve function for the account field. Inside the Resolve function we can get the data from the parent object, being the blogType object, and use it to query for account data when requested.

The GraphQL query we saw previously can become the following:

Alright so the above query may not exactly have the same meaning as the previous, but for this example it does. We’re saying we want to get a particular blog by account. Instead of providing the id for account, we can just get the information through that Resolve function that we had created.

Does this approach make queries unnecessary? No it doesn’t because there may be a need to query in different fashions. It did however allow us to do a type of JOIN operation with GraphQL.

Couchbase has N1QL, so wouldn’t a JOIN operation be better via the database and not in the backend? I mean, even though we’ve created relationships with GraphQL, we’re still doing numerous requests against the database. I would argue that it would be better to JOIN at the database level, not the application level. The fewer the requests, the faster the application, right?

Let’s modify the blogs query in our rootQuery object:

Instead of adding a Resolve function to the accounts field on the blogType object, we’re doing it all via the query. Our blogType object would look like the following:

If we wanted to write a query for this, we could easily do so like the following:

The above query would return all blogs and the account data associated to them. Instead of doing a query for each field, we’re doing it in a single request with N1QL.

Couchbase with N1QL is more plausible for this approach than a relational database because Couchbase encourages a flexible schema which can be easily modeled with GraphQL.


You just saw how to work with related data in a Golang application that uses GraphQL and the NoSQL database, Couchbase. With GraphQL you can create Resolve functions for each model field or you can create more complicated queries with N1QL and let the database do the heavy lifting. In both scenarios, the user can request exactly what they want without having to worry about a potentially excessive amount of API endpoints.

I encourage you to look at my previous example as it has more depth when it comes to GraphQL with Golang and Couchbase. You can even take it further and see another example I wrote titled, Getting Started with GraphQL using Golang.

To learn more about using Couchbase with Go, check out the Couchbase Developer Portal.

Posted by Nic Raboy, Developer Advocate, Couchbase

Nic Raboy is an advocate of modern web and mobile development technologies. He has experience in Java, JavaScript, Golang and a variety of frameworks such as Angular, NativeScript, and Apache Cordova. Nic writes about his development experiences related to making web and mobile development easier to understand.

Leave a reply