Convert REST to GraphQL With No-Code
So you want to take advantage of GraphQL? Have some related data you want to expose as a single graph? Read to learn about stitching REST into GraphQL.
Join the DZone community and get the full member experience.Join For Free
So you want to take advantage of GraphQL? Perhaps you have some related data you want to expose as a single graph?
Rather than refactor those endpoints, you can take those related REST endpoints or APIs, and using Tyk you can quickly wire them together and expose them as a single GraphQL API, with full API Management security applied, too, if you want.
In this example, we'll stitch together three different REST resources that are all related in some way, into a single graph and protect it with Tyk Open Source gateway.
The REST Endpoints We’ll Stitch Together
For this example, we can use some openly available REST endpoints. I recommend you do the same for this run-through. Once you've completed it (takes less than 10minutes) you can repeat the process with your own APIs.
Within posts, each post can have comments, so we can go to that resource and bring up the comments for a post. In this example, I'm pulling up all the comments for post ID 41.
This is all pretty standard REST API convention. It's likely you have products and services that offer something along these lines. This is quite a simple scenario, with everything under a single domain to make a quick demonstration, but of course, much more complex scenarios are just as possible with Tyk.
Tyk is an Open Source API Gateway. It also offers a dashboard that you can install or connect to via the Cloud. The dashboard has an easy-to-use GUI that makes stitching REST into GraphQL a very simple process. If you don't already have Tyk installed on your machine, you can grab a free account at Tyk Cloud. It takes a few minutes to signup.
Stitching REST Into a Single Graph
Now you need to log in to your Tyk dashboard. It doesn't matter whether you have it installed locally, on a server, or you are using Tyk cloud: the software and steps are the same throughout.
- Go to the APIs menu and click "Create API". Give it a name. In this tutorial, we've called it "composed". Check "GraphQL" under "Type" and "Compose new GraphQL service" under "details". Hit "Configure API" in the top right.
- Now we need to handle security. For the purposes of this demonstration, we'll leave it "open". Scroll down the page until you see "Authentication," and select "Open (keyless)" from the menu. Save at the top-right.
- You should now see a list of your APIs on screen. Select the one we just created. You likely called it "composed" if you are following this tutorial to the letter. Click the "schema" tab. You'll see that by default, it has "mutation" at the top. We don't need that for the purposes of this example, so go ahead and take that out, but keep the query below it.
Now it is time to add a new user type. In our example, a user has an ID, name, username, and email. Id is an ID, the name is a String, and so is the username. You'll see that Tyk offers auto-completes as you're working through this to make things easier.
There are some others we can add, but for our example, this is all we need.
Now that we've added our user, we need to create a query. Here we can change the default query into the user query. We're also going to add that the user takes an id, which is an ID. As this is mandatory, we're going to mark that with an exclamation point, and the type is a User.
4. OK, click the tab marked "data sources." You'll see the user object and our query. You'll also see that the user has a warning! which says "data sources required", so let's edit that by clicking the arrow >.
Now we see our ID argument is there as it should be, so select the "data source" tab, and click "Define Data Source". From the drop-down, select "REST," as we're stitching together REST resources that aren't already in Tyk.
In the URL field, we're going to paste in the user's URL using Golang templating (indicated by brackets). Also, we're going to use "dot arguments" to access the arguments that are available in the data model that we just looked at, and then .id for the name of that argument. Now we can update the field with the button at the bottom right.
Now let's go to the playground tab and write a user query that asks for the name and the email. You'll see if you hover over that it warns that an ID is mandatory, so we can add an ID number in, then hit play:
Our GraphQL resolver has taken the query, resolved it against the REST upstream, and returned the data for user id 5:
If I now want to see all the posts that belong to this user, we need to tie those in. To do this, go back to the "schema" tab, and create a new type called a post, which has an id (which is an ID) plus a title and a body, both of which are Strings.
The user now has a new type, which is Post, so let's add that in:
Click "Data Sources", and under User, we can see a type of posts. Click that, as we need to define this as a data source so that our GraphQL resolver knows that if we ask for a post, it should make a REST call to this resource. Now hit "Data Source" and choose from the "pre-defined data sources" list (the template we created earlier), then edit it to add /posts and replace .argument with .object.id.
By switching arguments to .obect, we can use any of the fields that were resolved from this current data source. We could use.id.name, dot email, that username. I'm going to use the ID because that's the user ID that we want to inject into this next call. Choose "update" at the bottom right.
Now go to "playground", and update the query to include posts, with userid, title, and id, Once we hit "play", we can see the output. All the posts belong to that user.
In the results, you can see that each post has an ID, and that's what we're going to use next for comments, as posts can have comments.
Go back to the schema tab and let's add Comment as a type, including postId, id, name, body, and email. The first two of those are ID and the last three are String:
That means we also have to modify our post type because posts can have comments. That's an array of type comments, so make that change and then switch to Data Sources.
Go to Post, click "comments", then "Data Sources".
As in the last step, select from the pre-defined list. Update the URL as below, then hit "update".
OK, time to go back to the playground and try this out. As we add to this, you can see auto-complete is helping us out:
Add comments, postId, name, email, and body; then hit play:
And we've done it. We've stitched together the various REST endpoints into a single graph, which now returns comments, posts, the users, etc. all in a single graph. For speed, we're just using the playground, but users can now hit this on your Tyk gateway and use GraphQL against your REST endpoints. REST to GraphQL transformed, in just ten minutes!
Opinions expressed by DZone contributors are their own.