DEV Community

Sedky Abou-Shamalah
Sedky Abou-Shamalah

Posted on

Convert REST to GraphQL With No-Code

REST to GraphQL magic

What would you do if you needed to turn three legacy REST services into one smart, secure and easy to manage data graph? And what would you then do with that graph?

In this article, we’ll walk you through the magic of using Universal Data Graph (UDG) to combine multiple REST services into a single graph. How you then leverage that power is entirely up to you…

Universal Data Graph in action

Imagine you have three different REST resources that you want to tie together into a single graph. In fact, don’t just imagine, work alongside this article using publicly available resources from JSON Placeholder to see how easy it is.

For the purposes of this process, we suggest using the Users resource, which returns a list of users:

Enter an ID and you can see a single resource. For example:

An individual user can have posts, as you can see here: Enter the URL and you’ll see a long list of posts that belong to that individual user.

The final level of this is that each post can have comments. So if you have a post with an ID of 41, you can look at to view them.

Let the stitching begin

What if, instead of making three different calls, you stitched those three resources together? That way, you could work with a single graph call instead.

To do so, start with the Tyk Dashboard and add a new API. Call it ‘composed’ and check the ‘GraphQL’ and ‘Compose new GraphQL service’ options. Next, click ‘Configure API’ at the top right of the dashboard and select ‘Open (Keyless)*’ as your authentication mode.

Save and then click into your API to start building the schema. Click on ‘Schema.’ You won’t need a mutation, so delete that and just keep the query.

Next, add a new user type, entering the ID (ID), name (String), email (String) and username (String). There are more that you can add, but these are sufficient for demonstration purposes.

Image description

Now, change the default query into the user query, taking in ID (mark it with an exclamation mark to show its mandatory) and setting the type as a user.

That’s it in the schema editor. Now switch over to ‘data sources’ and you’ll see your user query. Data sources are required, so click on the user query and then on ‘data source’ where you can toggle the ‘define data sources’ slider.

You’ll have a couple of options when it comes to data source type. Click on ‘REST’ and enter the URL you used earlier:

Then, instead of the ‘5’ you can use Golang templating – {{ }} – and ‘.arguments’ to access the arguments that are available in the data model. Enter ‘.id’ for the name of the argument that you made. So you should end up with a URL that reads:{{ }}
Enter fullscreen mode Exit fullscreen mode

Choose Get as the method and click ‘Update field’ at the bottom right. And that’s it.

Time to play

Now it’s time to head to the playground within the Tyk Dashboard and write your user query, asking for the ID, name and email. You’ll need to include a user ID, so opt for 5, in line with the example we’re working on.

Hit the play symbol.

Image description

As you can see, the GraphQL resolver has taken the graph query and resolved it into the REST call to the upstream with the ID of 5.

Adding in the posts

Now, let’s tie in the posts. To see all the posts that belong to this user, head back to the schema and add in a new type, called post. Add in the user ID (ID), post ID (ID), title (String) and body (String).

The user can now have a new type, so add posts to the user types (an array of type post).

Image description

Head over to data sources again and you’ll see that the user has a new type: posts. You can now define this as a data source, so that your GraphQL resolver knows to make a REST call to this resource if you ask for a post.

Click on ‘posts’ under the user type and, in the data model section, ensure that ‘Is List’ is checked. Now, under data sources, toggle the define data sources slider and use the predefined example that you built previously:{{ }}
Enter fullscreen mode Exit fullscreen mode

Next, add the endpoint:{{ }}/posts
Enter fullscreen mode Exit fullscreen mode

Now, this data source doesn’t have an argument, so instead of, you can use .object – that lets you use any of the fields that were resolved from this current data source. In this example that means you can use any of ID, name, email, username or posts. Using .id will inject the user ID into the next call:{{ }}/posts
Enter fullscreen mode Exit fullscreen mode

With me so far? Great. Click ‘Update field’ and go back to the playground.

You can now add posts, including user ID, title and the ID of the posts, into your query. Hit play and you’ll see the results – all the posts that belong to user number 5, including their titles and post IDs.

Next, you can use those post IDs for the next chain: comments.

Adding in the comments

Each post can have a comment. You can see this takes an argument in the query parameter, as shown here with the post ID:

To get the comments for any post ID, head back to your schema once more and add a new type: comment, along with post ID (ID), comment ID (ID), name (String), body (String) and email (String).

Now you can modify your post type to include comments (an array of type comment).

Image description

Head over to data sources again, open up comments within the post type and toggle ‘define data sources’ in ‘data sources.’

Now, you want to make a REST call to comments with a query parameter of postid and using the ID field from the post data source, like this:{{ }}/posts
Enter fullscreen mode Exit fullscreen mode

Update field once again and head over to the playground, where you can now add comments to your query, including the post ID, name, email and body.

Image description

Hit play and voilà – you can now see the comments for each post.

And that’s it – that’s how easy it is to stitch three different REST resources together, combining them into a single graph.

Now it’s your turn. Where will this newfound ability take you?

Top comments (0)