In this tutorial we're going to show you how you can use a single query to get not only results in a single table, but at the same time return related results from another table.

For example:

Using related_records is powerful because:

Here are a few of the terms you may come across in this topic:

The great thing about related records being as flexible as they are is that there are a lot of examples we could choose from. Our first example though will try to keep things simple by fetching Blog posts with their associated authors.

We've already covered how to write a records query and filter it so it contains only blog posts. Here's an example:

Since these two modules - the Blog and Authors Module - are both created by Siteglide, they already store the information needed to join them inside their properties. We only need to look at the existing properties in detail to get the information we need to build our query.

There are several ways to do this. One of the easiest to do on an everyday basis is to use Introducing Siteglide CLI to pull your site, then to look in marketplace_builder/form_configurations:

For this exercise, we'd be looking at module_3 for blog and module_6 for authors.

In Blog, scroll down or use ctrl-f to search for author The form configuration will contain both the human-friendly name and the Siteglide ID for each field:

Great! It's a datasource field, which is pefect, because it will already be set up to contain IDs of Author records related to each Blog record. We don't need to look at the Author record now to know that the module_field_3_4 property of the Blog and the id of the Author should match. Sometimes, you'll need to look at both.

Since this is a GraphQL tutorial- here's an alternative way to check the form-configurations- using a query (see how we use filter to look for only the Blog and Author configurations)!

In the Siteglide Admin, we can check that some of the Blogs already have authors set in the datasource field, in this case this Blog item has an Author ID of 100 in the field:

To start with, look inside results in explorer: related_record and related_records appear as possible results. By including these special objects inside the results object, we can define a branching tree of related results.

The two options are similar but have one key difference:

The main reason to pay attention to which you choose is that it will change the way you structure your Liquid to access the data- remember if there is an array in the data you may need to loop over it in order to access it.

For now, let's use related_record, as we have a datasource field to join with, and only one Author per Blog record:

Remember, we use a string with no spaces and a colon to "rename" things in GraphQL. It's a good idea to rename this related_record to describe what it will return. In this case, it describes a single author.

This will make it easier to understand the results and allow you to add other related_records in future (it won't let you if names clash).

As mentioned in the glossary, the join_on_property is used to define the property in the current result record which will be used to match with a related record. In step 3 we worked out it was module_field_3_4.

The foreign property is the counterpart to the join_on_property, but it refers to the property in the record we are looking for, in this case the Author record is the record, and the property is id.

Note the syntax is the same, even though module_field_3_4 is a custom property and id is a core property in platformOS.

table here is a filter, despite not being inside a filter object. It must be set to describe the table we should look in for these related records. In this case, the ID of the Authors module: module_6

We've already defined which results we want for Blog items, and that we want to return a related author per blog item, but we also need to define which authors properties should be returned.

We could return the whole properties object, but where possible it's worth being extra efficient when working with relationships. There is more work for the query to do, and it may run more slowly. Maybe we just need the author's name and an image (I use the information we looked at in step 2 to find the module_6 image field ID)?

The results go in the new object under related_record after the arguments; no results key is needed:

That's the query itself done!

The results in JSON may look like the below (we've minimised Blog properties which aren't useful to the example):

As always, when outputting in Liquid, you can use dot notation (see Liquid Dot Notation or Tutorial 5 - Using Liquid to run GraphQL queries on your Site) to access the results, until you get to an array. Since we only asked for a single author, we can use dot notation inside the blog record to access the author. We still need to loop over the blog results as always:

What if you need this to fetch information the other way around, e.g. you are on a page which displays information about an author and you wish to display a list of the Author's Blog Posts? An additional aspect to this is that this is a 1:many relationship- it's no problem- we'll use related_records plural instead of related_record to return an array instead of an object. Starting with the query above, lets make some changes:

Next, you could experiment with some of these options: