REST is an API design architecture, which, in the last few years, has become the norm for implementing web services. It uses HTTP to get data and perform various operations (POST, GET, PUT, and DELETE) in JSON format, allowing better and faster parsing of data. But REST comes with some downsides that have enterprises considering alternative mechanisms to manage performance, developer time, and production of their APIs — enter GraphQL. GraphQL doesn't have to be a replacement to REST, the two API designs can co-exist and be leveraged for the appropriate use-case. Join us for a conversation about what benefits, shortcomings, tooling, and design decisions you need to consider while making this evaluation.
English version
Video Summary and Transcription
GraphQL is an up and coming trend in API development, allowing for the combination of REST endpoints into a single API call. Tyk, an open source API gateway vendor, is now offering full lifecycle API management. With GraphQL, developers can import REST APIs into Tyk and convert them into GraphQL APIs, simplifying the process and reducing the number of API calls required. This lightning talk provides a demonstration of importing IDs, defining data sources, and combining endpoints using GraphQL.
Available in Español
1. Introduction to GraphQL and Tyk
Short description:
Hello, everybody. Thanks for coming to watch this lightning talk on GraphQL. My name is Sedghi, I'm a Technical Lead at Tyk. GraphQL is an up and coming trend. We're an open source API gateway vendor and now full lifecycle API management. Today, I'm going to import some REST APIs into Tyk and convert them into a GraphQL API. Let's go to the API management dashboard and see how it works.
Hello, everybody. Thanks for coming to watch this lightning talk on GraphQL. I'm very excited to talk to you today. So who am I real quick before we get into, what are we talking about? My name is Sedghi, I'm a Technical Lead at Tyk. I lead a group of very talented sales engineers and consulting engineers. And we talk to customers all over the world and from companies of all sizes about GraphQL, about rest, about APIs, about Kubernetes and Docker. It's a very fortunate position to be at a cross function of many different domains intersecting.
GraphQL is an up and coming trend. And what is Tyk? We're an open source API gateway vendor and now full lifecycle API management. So feel free to go to tyk.io and you get a feel for what that is.
So what are we going to do today? So I'm going to import some REST APIs into Tyk. So we have a collection of REST APIs, we're going to import them into our API management. We're automatically going to convert REST APIs into a GraphQL API. And then that's it, we're going to profit. I'm going to show you how easy it is to do that. And so what do we have? So we have a user REST endpoint that has an ID, name, username, email, and then posts. And this post it's an array that refers to all the posts made by this user. A post has these fields, and then it posts those comments, and a comment is an array of this type. And so these are three different endpoints. I'm going to compose this into a single GraphQL API for you, and we can talk about the different approaches.
All right, so let's go. So here we are, I'm in the API management dashboard, we're not going to get into the nitty-gritty of all the different stuff, but you can see we have this API here, it's called GraphQL posts v2. And right now, we have a user type and a post type. So I've already defined my schemas, and it's a one to one representation of the underlying API. So if I go here and I go to users one, so I want the rest resource of where the user ID is one, and it returns to me all the JSON payloads. So we have Leanne Graham is the name, the username, the email, and so on. And so I've taken these fields from JSON, I've mapped it into this GraphQL schema. And then I went and I injected posts. So here we have a second API, and it's called posts. So we have all the posts that belong to this user.
2. Using GraphQL to Combine REST Endpoints
Short description:
You can see it's an array where each post has an ID. We're going to pull that using a single API call. We get back all of the data from two separate endpoints combined into a single API call. Now, we'll inject comments as a subarray of posts. We've generated an API in Tyk and imported all of the endpoints. Next, we'll define a new schema for comments.
You can see it's an array where each post has an ID. And so that's two different rest endpoints. Now I'm going to show you how using GraphQL, we're going to pull that using a single API call.
So we have this user, where the ID is one. If you've never seen this before, it's a GraphQL playground. It allows us to query data, it has IntelliSense, which is going to help us actually to show what fields we can ask for. And so I want the ID name and email for the user where the ID is one. And next I want all the posts. And I want the title and the body of each post. And if I fire that off, we get back all of the data that we just got back from two separate endpoints. And we've combined into a single API call. So we'll talk about why that's powerful shortly.
But first, so you can see that there's no vaporware going on here, we'll go ahead and we'll inject comments as a subarray of posts. So comments looks like this. And so we're going to go to the comments endpoint and you can see where the post ID equals X and you get all the comments with their IDs that belong to the post where the ID is Y. So we're just going to go ahead and inject that. So what I'm going to do is I'm going to take the Swagger JSON or open API spec. I'm going to go into Tyk and then I'm going to import an API and we can see it from Swagger and then I'll grab the endpoint here and I'll dump it in. So we have that. There's the base URL and there's the version and then we're going to generate the API. And just like that, we've generated an API. The listen path is foobar and the authentication type is openkeyless. So we'll go ahead and create that. If we go under Endpoint Designer, we can see that we've imported all of the endpoints. So we have the post, the to-do, users, albums, photos, comments, and so on. And so now we've imported our API. It's now in Tyk.
Now the next thing to do is go ahead under our graphical. We're going to define a new schema. So it's a type comment where, let's see, a comment has an ID, a name, and an email.
3. Importing IDs and Defining Data Sources
Short description:
So let's import the ID, name, and email. Create a new field called comments under posts, which is an array of type comment. Define a new data source, TykRest, and select the comments endpoint. Inject the post ID from the parent object. With REST, we had to make multiple API calls to different endpoints and figure out relationships. With GraphQL, it's a single API request for all the data.
So let's just import those. So an ID, a name, and an email. And they're all of type string. And let's just do that. Okay, finally, we're going to create a new field under posts where it's called comments, and that's an array of type comment. And then, are we done? Well, kinda.
If we go back to our playground, and we, whoops, you can see now we have this comments type when I can ask for the name and the email of each comment. But we get back a no. Why? Well, that's because we haven't actually told type where to get the data for this comments field yet. So that's where we have to go and define that next.
So under here, we're going to go under post, under comments. I'm going to define a data source. I'm going to say, not an existing one. We're going to define a new one. It's TykRest, the data source. And then we're going to select our JSON placeholder that we just imported. And now we can even select the endpoint itself. And instead of that, we're going to say comments where the post ID equals. And then we're going to inject the ID of the type post and update. And we're going to give it a name, comments endpoint, and then update and update. And now we've told Type, okay, when a request comes in, and somebody asks for a comments field that belongs to posts, go to the comments endpoint and inject the post ID from the parent object. And so now if I fire off the same request, well, I screwed it up. So that sucks. But the idea is that's how it should have worked. So demo gods and all that, but I don't know. Anyway, we have 45 seconds left before we end. So I'm not going to get into debug mode and figure out what I did wrong. But that's the idea in a nutshell.
So what we wanted to talk about was the difference between querying a request for GraphQL, so versus REST. And so with REST, you can see if we wanted all this data, not only did we have to go to three different endpoints, but in addition to that, we had to figure out the relationships. So us on the front end building out, let's say a landing page for a social media application, we had to make a call to user. And then we have to make a second call to get all the posts that belong to this user. So we have to inject the user ID into this call. And then finally, we have to go under comments and comments and inject all of the post IDs and make one API call for each of my posts. So there's potentially dozens and dozens of API calls that we had to make. That is no longer the case. It's just a single GraphQL API request, if it worked, and we got all the data back in one go. So I'm over time now, so I'm going to go ahead and stop.
