You can listen to the podcast and read the show notes here
Michael: Welcome back to the show. I'm here with Mark Drew from Command MD, a web development consultancy in London, he's the founder. That's a bit like George Washington founded United States except it's a little bit smaller.
Mark: Just a tad, just a tad, we'll soon be quite as … you know give me 400 years and …
Michael: There we go yeah.
Mark: And I'm sure we'll be quite as big as the United State.
Michael: Exactly, so we're going to be looking at getting graphical with GraphQL. We’ll look at the history of A.P.I. use, and where GraphQL fits into that. Why you should use it, who's using it, what exactly is the fundamentals of it, some of the subtle language concepts, and mutations that we can look at in there. And also, how you'd use it from ColdFusion, and how to get started on that. We'll have a quick demo in the middle of the episode, so you can see that.
Mark: And we [inaudible] [00:58] demo gods that everything goes well.
Michael: Always praise the demo gods. And we'll also check in on how C.F. objective was, and what's coming up at the C.F. camp for Mark. So, welcome Mark.
Mark: Well, thank you nice to see you again I should say. Are these in order?
Michael: Yes, they probably are moderately in order. We do shuffle randomly sometimes, but you know you're not alone because otherwise you're going to be like but we have not seen him before yes. So, thank you, thank you for having me on.
Michael: Yes, it's a pleasure having you here, that great British humor.
Mark: Well, okay, anyway.
Michael: Yes, so if you're using API’s, people used to use SOAP, and they used REST, but now perhaps they're going to use GraphQL after going to your talk at C.F. objective that was recent.
Mark: All these are can know there's a reason to have another tool out there. This is why I do a lot of presentations is sometimes, I don't know about a subject and I basically throw myself in and say hey, I want to go and talk about the subject I don't know much about. So it forces me to actually look into it to a point that I can describe it to somebody else. And once you've done that, you actually have to have gathered enough knowledge about it that you're actually fairly good at it. [Crosstalk]
Michael: Yes a great technique. I recommend it to our listeners. If you see some subject and you want to maybe you don't want to go straight to a conference, but perhaps you can teach it to your co-workers.
Mark: Yeah, exactly. I don't really suggest this is a very good technique. I mean and it also allows you to … It gives you a vantage point from which to learn a technology. So as you're learning, it you saying, “How would I describe this is somebody else?” Which we don't normally do. We go like, “How do I understand it? How would I do it?” And then do it a few times. And once you explain it once or twice, you understand the holes in your knowledge, right. Which is a technique I’ve been using for years. I mean this is why I talk of conferences, and keep on thinking about them because otherwise all you're doing is kind of preaching from the pulpit, and retracing things that you know already. And that doesn't make us better human beings, that doesn't make us better brains. So, this is why I like looking at new technologies and talking at conferences about it.
Michael: I mean that's genius. Helps you get younger every year.
Mark: Right yeah, and one day I'll be like well, it helps you understand, or realize how little you know. So when you think getting younger, by the time by now you realize how little you know because you're so much to know, right. But if you're always talking about one subject you think you know it all. But you only know in the compass, and you never get out of your comfort zone. So, long story short this is how I came on to work in GraphQL. And I actually have to give a shout out to Adam Tuttle because he did suggest it to me on Twitter and said we need talk about GraphQL [inaudible] because for those who don't know Adam Tuttle actually does Taffy – the rest library for C.F.M.L.
So, thrown in there which is known Shannon's but we shall add it in there. But anyway, so you ever so he said to me not what here have a look how you would use it from C.F.M.L. Which kind of bring us on to like what war Graph QL is, right? But before we can really talk about what GraphQL is, you have to understand like the procession is basically a way to query API’s, but why would you need yet another way to query API's, right?
Michael: And an A.P.I. is just ways you access someone else's system.
Mark: Right exactly, and we've all been using SOAP for one point or another it was meant to be this great way to access stuff, but it turned out even more complicated. So for about the last decade, people have been using this other scheme which is called REST which is what nearly every single A.P.I. out there is. It does is great because it is H.T.M.L. based; sorry, H.T.T.P. based. You can put it behind S.S.L., you can put it behind a caching server like Vanish, or something like that and it all works because you've got all this technology.
It’s like just using existing technologies, and passing Jason right, back or forth and back right. And he can … and this is a great little system because he's got simple stuff, right. So you represent you have like this representational state transfer; that's what REST stands for. But your basic create this whole idea of like an object, a person, and then you have an end point that's called like person. And then, the next parameter like the next fall the path would be their I.D.’s. So you don’t get on a person with their ID because one, and you have this very kind of simplistic unique URI’s for every object in your system, right.
Makes sense, fantastic, there's nothing wrong with that. You then use let's say you do a put which creates a new person, you do a post which updates a person, and you do a delete method, and it deletes a person. This is often tacky stuff, and very standard H.T.T.P. stuff that we were kind of used to, and this is great, fantastic stuff. But things kind of start breaking down a little bit and we start missing things. Like for example, one of the big promises, have you ever looked at the Twitter A.P.I. said I always use a Twitter because it's a nice.
Michael: If I'm a little insomniac at night, I get that out.
Mark: And just have a little read.
Michael: Yeah, immediately to sleep.
Mark: Right but for a system that's meant to give you like 140 characters well known that is just gives 140 characters. If you actually look at what if you go and fetch an individual tweet brings you back is a huge amount of data. There’s like all stuff about the use of the stuff, about the location of the tweet. There’s stuff about who else was mentioned in the tweet, any attachments, etcetera. And if you start looking it's like a massive Jason packet and you can’t say well, as part of rest you can't say just give me a little bit of… right. So, doesn’t get lots of other stuff, right.
And for example if I want to get a tweet by you and it said, “Here are my friends” right that are mentioned in this, and there might be links to them and I have to go and do another whole bunch of other course turn get all those people write. So for example, I want to get if you mention five people in a tweet and I wanted to get their pictures, I'd have to do one get request for your tweet, and then this other five people mentioned. Another five get requests for user profile of that person and then do some other people ACP request to get actually the images right so that's one of the top eleven get requests to get one tweet with all the people will their images which is okay. But this kind of, why can't I just go and get all the URL’s and then I have like six H.T.T.P. requests which include images rather than eleven, right; much easier.
And any of the similar problem is like what you could then change your A.P.I. to say you're going to go get a tweet, but return the full objects of the people that are mentioned. So now, you muddying up the representation of your stuff. You're adding kind of filters to it; not even filters you're doing like or you do a different A.P.I. which is kind of like, some kind of like prefix queries. It’s like for example get tweet with all the friends, or get tweet with all the mentions, or something like that, right. Which just kind of bloating up your A.P.I. because you can imagine as a programmer, I can imagine like 20 different versions of queries I'm going to want to do.
Like I get a tweet with all the likes, and who's liked it. Like now you get like a very expanded documentation. And of course we know how well the developers a document stuff so. You know unless you've got a team that documentation is not going to be written. I worked with an A.P.I. recently that we couldn't get something to work. They said it would work in the A.P.I. like it should work, it should work, and there was a not to be the missed out there was in one of the blog posts thanks developers. This is a big company you know, obviously.
Michael: It's a pretty much standard.
Mark: Yeah exactly, and this is a good thing about SOAP because it was self-describing saying this is what I expect, this is what I give you, very dryly though. But this is where we lost in REST. Now that he's gone somewhere of course, there are systems out there like swagger that kind of generate your A.P.I. and you can generate your documentation out of that; out of your system. There's ways of doing it, but they're not comfortable ways of doing it, right. Then you get to the other part of the documentation is that you have to version it.
That's why every REST service starts with a slight V1. Right because now if you want to make any changes now the whole point is that an A.P.I. also off with changes all the time, right. It should be inbuilt that you can change it, right. Now the problem is is that for example, if we wanted to get a twit, and let's say Twitter there's an added categories to a tweet, right. I guess you have hash tags. But for example, if we're now going to have like an array of categories that have tweeters in, and I added that, that's fine because my existing clients that weren’t using it now just added that they're not using that but now they're getting that sent to them, but that’s fine, right, that’s fine.
But what happens if I change the format of the date. For example if I had like some you know, just like localized date and then I wanted to change it to U.T.C. now a whole bunch of clients are going to break right. And you have like two options, so you can either keep the old version like forever, and support it to the sun burns out because there's always going to be that one client that's going to be still using that version. And again as I said documentation, like all of these changes never get updated, and don't. All they do eventually and not fast, and so these are like real issues with REST. So out of that comes GraphQL. So, GraphQL actually came out of Facebook's problems with REST. So back in about 2012 (I'm going to get the date probably wrong).
But I don’t know if you remember that if you were using Facebook. They had a mobile app, or they built a mobile app that was basically like a web version in an app. Like they were using a web viewing in an app. They have like a cut down web version of it, and it was getting very slow, so they wanted to build a native version. To build a native version, you have to build an A.P.I. So they started looking at SOAP, at REST of various different API’s [inaudible] because they have a couple of quid to spend on engineers to just going to have a look rather than implement. And they came up with GraphQL. So the whole point was to create a data query language so you could like query the trees.
So you can imagine for Facebook you want to get a person, and you want to get all their friends, and you want to see their friends' friends and be able to do those queries easily, right. They've been using it internally since about 2012. I'm guessing which is when the mobile app was rewritten. And then they created an open source version back in 2015, and they never released and this is spec for says natural language, so you can implement it in other languages. So you don't have to you know, they made a reference implementation but then you can actually build it in P.H.P. or ColdFusion, or whatever you want to build it in.
So generally, when you're building A.P.I.’s you have and this is what the problem was. Was that you're going to have like your system right so the gateway to your A.P.I. that goes and talks to all your different database servers all have a huge structure to your application to your business logic. And you find out that you have you’re A.P.I. But sometimes, you go like well, we're not going to be stupid like Twitter. We're going to have a mobile version of a twitter client that gives you like streamline stuff. And they go okay, we also have a desktop versions, doesn't give you like this cut down version.
So, now we have two A.P.I.’s that you’re modifying. The whole idea is that you have GraphQL that replaces those two, or you work alongside with those two that queries all your services, and you can just send in a query. Go and get me a tweet with just give me the text and maybe get all the images of the people that come back and it’ll go and return, so the client to find queries.
Michael: So really it's pretty similar to how we use S.Q.L. to query a database.
Michael: In modern terms as opposed to the ways before the Sequel database was invented people had flat files and they did all kinds of gymnastics to try and get their data. And this the same kind of evolution from REST to GraphQL.
Mark: Right because his goal. A couple of things in there which help. But like Sequel, has this ability to jump, and have connections, and have ages, and nodes of those edges. In other words, is able to jump the object that you're looking at and say okay, so this is connected to something else let's have a look at that, right. So the whole idea of GraphQL is hierarchical, so you can do a query of the top. And then, I can see the children of that, and then go into the children, and do like a hierarchy of data queries. And when I return that back, I can get a hierarchical structure back, right. Like a tree of data back.
The other idea about it’s product centric which I guess a little bit sequel is a little bit. In other words, all the nouns are using are nouns of your system. So I have a tweet, I have a person, I have a spaceship, I have a car, or you know those are the nouns that I'm using my system, those would be used in the language. It's also [inaudible] 16:07, so it knows what the variables are going in are, and the variables are coming out are. So you could create your own variables, you can have objects. Go and get me a person, and that's an object, and that's kind of a variable that you could possibly pass round, right.
And you can also let the client specify the queries rather than say here's where the U.R.L. end point because you have a GraphQL end point. You can say like well the point specify what they're asking for and suddenly you know. It's also introspective, so part of the spec is that it will return information about itself. So you can say you can ask me about these things and this is a poll where documentation comes out of me. Because these things have these properties and these there are these types and I'll return this, and this is what you should ask me because then you can compound them and put them together.
Michael: So no more reading weird blogs about the A.P.I. to find out what's currently in there you can write introspective.
Mark: Right exactly, you just like see in they're going Oh, right okay, so that's what it's going to give me, right. I should show you a little demo maybe because now that we've talked all about it, I can give you a little.
Michael: Yes, let's have a quick look at some code here
Mark: okay so
Michael: For those listening on audio will try and narrow…
Mark: It’s kind of like [crosstalk] [17:30]
Michael: It's like watching cricket on the radio, right.
Mark: So, Mars coming up to bowl here. You just use the language of probably 90 percent of your listeners don't have it and you say…
Michael: Well, watching baseball on the radio, but they probably wouldn't identify. I don't know who does that anymore either. That used to be a big thing.
Mark: Yeah, but now it’s podcast. It's like watching podcast on the radio.
Mark: No, I don't know. But for example: there's a great website. I don't know if you have seen this which is called ‘Swapi’ which is the Star Wars A.P.I. which allows you to get [crosstalk]
Michael: Aha! critical
Mark: It's critical right which allows you to get …
Michael: Everyone should be using this right
Mark: Yeah I think Raymond [inaudible] [18:14] told me the guy's going to stop supporting this, and if he is, I think someone should take it on because it's fantastic. But it … [crosstalk]
Michael: … a little playground where you can try out an A.P.I. that isn't going to cause tweets to get emitted.
Mark: Right exactly, so for example, you can do like as part of A.P.I. You can go to forward slash people forward slash one(/people/1). And what you get is a nice Jason structure which is often like Skywalker because with his name, his height, his mass. I guess he knows mass about if he’s going to be slammed into a wall, or something like that. But also, you get like things which are quite important here is that in the proper REST A.P.I. you have a home world. And because there's a link to another object in the system has actually got a link to the URI of that object, right.
So for example: the home world is planets number one which is tattering, right. You also have for example, an array of relationship so you have can say, “Which films has he been in?” And then, you get a nice array of films Skywalker has been in, right. And they haven’t updated, the last time I looked, they hadn’t updated it. And you can say which species and you see that is these are very big links and a date that this record was created, and edited, and it’s own U.R.L.
So this is just to give you an idea of what kind of data are stored in the Star Wars A.P.I. because we also have a GraphQL connection to that A.P.I. It’s called the swapi; the GraphQL swapi. Let me just… Should I show us?
Michael: Yes let's have a quick peek at what that looks like.
Mark: There we go. So here we go, so this is what GraphQL. Let's go and get a person, so you have curly brackets. The interesting thing about GraphQL which throws people first is that it looks like Jason but it's not Jason. Right so you don't need to put all the double quotes. They’ve tried to trim out all the stuff that you really don't need to be putting in there. So, I can say I can press control space and it tells me all the things that are available in there, and these endpoints allow me to say to search just the schema. So, if I want to search for a person. It tells me that a person has got a name, a birth year, eye color. This is what is self-descripting, right.
Michael: Don't forget the mass.
Mark: The mass exactly has mass. Where is the mass? There you go. So, your mass tells me this type of float, right.
Mark: And home world that is actually linked to a planet, and I can see what's in a planet, right. Now this is actually an A.P.I. returning a call into an SUI. So, let's say… let's actually do some searching for those people that are watching at home, and if not you have to watch us on YouTube. So, if I now put person, and I can see person ID is equal to one, right. Now this is the hierarchical bit because now, if I try to run that, they said, “Well, you do not you didn't ask for anything to come back,” right.
Michael: This is one of the good things about GraphQL. You actually get error messages back.
Michael: Whereas when you're doing the REST stuff sometimes, it's little cryptical as to why it didn't work.
Mark: Right, you either get a 500 error, 404 error, all they should [inaudible] 21:49 and you have Wikipedia on the other screen to find out what 407 actually means. I don't know. Can’t remember what version I used. But for example now I can put name, and I can put comma, and let’s get mass.
Mark: And the data that comes back is a struck. I actually get Jason data back which is nice GraphQL queries don't have to be in Jason, but you get Jason back. So you get… here’s some data, you get a person, Luke Skywalker, mass of 77. That's fantastic, but let’s say I want to find out what the name of the planet that he was at was, right. So now, remember in the how I showed you were his home world was just a link to another [crosstalk] system.
Michael: Yes another the REST call.
Mark: Right, so now I can go give me the home world, and then again like [crosstalk] [22:42]
Michael: The great thing there is you didn't have to know what the parameter name was. It's all coming to the introspection.
Mark: Exactly, so there we go. We have home world tattering and I can see what else it has. It has [inaudible], it has a dynamiter, the number of standard hours; so this is rotation period, over two period, the gravity, the population; which I think is fairly low, isn’t it? And I can see what else is in there. So, I can see a whole bunch of different things that are related and I can just literally call that and I get data being returned which is a person with a mass of 77, a home [inaudible] [23:23] to equal status I mean and a population of 200,000; quite big
Michael: That was a lot quicker than doing it using REST.
Mark: Right because you would have had to do one call to go and get Luke, trim out all the stuff, or ignore all the stuff was actually returned. Because this data packet is literally what the server returned back to you, and if in your application that's all you need, is great. Because unless you know your team and maybe all of us listening to this are developers. But ask your team managers how much your A.P.I. is costing in traffic. You don’t need to pay for traffic very popular site. Maybe like cutting it down to like one percent might be like quite good thing.
Michael: And then if some of if the A.P.I. changes in the future, do you have to change the Graph QL query, or?
Mark: You would have to change a query, but at least there is are you getting are not held in a third party documentation system, right. The error that you start getting in your systems because you’re using are going to be like … I don't know. Name is not… As you saw there, name is required or something like that, right.
Now the other part about this is that it can reach out to a rays of stuff. So for example: let's say film connections. In other words, which films he was in, right. Will Rick is going to the edges of the query, so you can call an edge. and for each edge right. So for each edge, we have a node, so these are basically this is a relationship to other queries, right?
Mark: So for each node in that edge, I can now look at where the title of the film was. So, you can now hit that and I get phone connection. Here's all the edges, and here's all the nodes. I’ve reached node, I have a title for it. This is what they call the relationship to an array of other stuff. So, Luke has one home world so that you know once one relationship. And but if I have a want to many relationship, those are called edges, and in each edge you have a node. So I can do like well, I can do things like the titles, or open in Corel; that's very interesting and let’s say the director.
Right so I can get all that data just that I wouldn't have known was there much easier. Just all in one hit. So now you can imagine. I was doing an A.P.I. So you know Luke Skywalker who's quite skinny from the home of tattooing that appeared in ‘A New Hope’ and all of these things, right. And I'm not on one hit do that and most of the films are directed by George Lucas. Well there weren't, but a couple of the films were directed by George Lucas.
Michael: it's genius
Mark: It’s genius and it just … It’s that easy, right?
Mark: Now of course even in your application, you might have …
Michael: And can you put you know like in S.Q.L. you could say, bring me back everyone who has mass less than 80 [crosstalk] [26:38]
Mark: That would be up to your application and it's not up to GraphQL to do that, and how you do that is by passing variables. I know it’ll be up to your query to do that. I think they're working, I haven’t quite gotten to this part unless I do by filters, and you can pass in a filter as part of the arguments because here's a firm connection that you could probably pass in. First before last, right. These are the only filters a film connection has. The film connection query in the back end of this, but you could see that you could say mass equals something, right?
Mark: Less than you'd have to implement that because it's not quite a query language like Sequel that everyone knows how the engine is meant to respond. This is a query language for your service land, right. So is up to you to implement it. But if we look at for example: I know the edges is always throw something but the nice thing about film connections I can do something like page info, or total count, or films, right so I can run that (I don’t know if that is going to say). Right, needed expected names. So, I can do film connection, films. So. You get the same thing here. With that name. Oh I think this is … I have to put a variable in there, sorry. But the whole point about the connection is that you can also get meta data about it. So, you can get page info which needs to be has the experience and [inaudible] etcetera. Or you can get total count. Expected name, I’ve not found… aha! There you go.
Michael: The best way to think about edges is if you had a … if you were looking at a drawing of a tree maybe a child’s drawing where the trunk came out, and then it split into branches, and those branches had sub-branches.
Michael: So, an edge is like a branch, and a node is where the branch generates.
Mark: And like even for each one of those you can keep on going down so.
Mark: For example: two films, let’s do that. Is so I’ve got the films are going to title. Let’s see producers, so you can have producers, and returns in array. Because those are not massive objects in our system they're just things. But we could have … each film could have for example, species connection, or starship connection, or a character connection. So you can get a list of characters are in each film that Luke Skywalker has also been in.
Michael: Right and you can see the tree nature of this because some of the movies have two producers, some have three, probably some have one.
Michael: And then in your code you can pass through the stuff as you want to.
Mark: Exactly, so I mean that's essential concept of it. So you can actually pass variables, so this would be on your client. This is how you will implement it in your mobile app, if you're building a react app, and using this as a query language into your A.P.I. Obviously, what you don't want to be doing which you kind of have to in Sequel well, you don't have to totally in Sequel is doing this replacement, right. So, I can do something like ID. So, hold on a second. Well, you can actually do. You'll be passing on the string, but you can also say, define which variables are going to pass unless you consider that this is a query, right.
So you can have person, ID, account number the syntax of [inaudible] [30:51] something like this. So, this is my query of … Oh sorry! The query, get Luke, get; sorry. This is getting a person, and getting all the film connections; get person. We could pass in a person ID. I'm not doing the best example because I'm just doing this off the top of my head which is. And then you could pass it here as a variable. I’ve got the syntax wrong, so every one that has this will be screaming at me. This is a problem I'd love coding even on podcasts. So person ID equals 1. And you could pass it like that, right.
Michael: Right seeing passing a variable to your code to the GraphQL query.
Mark: right syntax
Michael: I know some of the other things you mentioned earlier were fragments.
Mark: Right, fragments is this whole idea that you can actually replace some code in there. So, for example: if we had various queries that we were using, and we were getting a normal thing which is let's leave this. So, for example: we're always getting name, and I don't know. This is an age, name and …
Michael: Characters are ageless.
Mark: Let's simplify this a little bit. So, let's say we're always going. To move to many brackets. So if we're getting [crosstalk] [32:41]
Michael: If you were all if you weren't good with curly brackets before you started writing GraphQL, you’ll be a curly brackets genius when you finish.
Mark: Exactly, so if you're always getting name and birth year for different queries, we could fragmentize that, and I was just creating as an include. So what you can do is fragments. We're going to call it person, person in for maybe. On person, right. Because it means that this fragment only works on a person okay. And then we can say it’s that, and you can say is name and birth year, right. So, already knows what we're trying to do, and I can then put there like do like three dots, and I can do. Person I hope this will work in this client. But this is essentially what it is. Right, so it is now getting the same thing everything included there.
Michael: So it's this is sort of like a stored procedure in Sequel.
Mark: To a stored procedure. I mean this would be on the client. So basically, what you're doing is doing like includes of a…
Michael: code fragment
Mark: of a code fragment
Michael: And we'll put the U.R.L. to this example in the show notes, so if you want to try it out at home.
Mark: Let’s say the person by ID, dollar sign, ID [inaudible] The good things is that this client that I'm using is not something on one machine. It's something on the web that anyone can actually use, right.
Mark: So, now that we've got this, we can actually pass into this function so to speak. We can pass in a variable. Let’s say four and if we run that … expected name not found. Oh right!
Michael: I think we didn't pray to the demo gods quite enough for …
Mark: We didn't, let's just say.
Michael: Maybe you can tell us about mutation in GraphQL.
Mark: One more thing please. There we go. Never used on one user. There we go, too many curly brackets. Exactly so the whole idea is that you can actually pass variables to your query like you would do query [inaudible] [35:59], or something like that. But it's actually built in to say this is a query language. So the thing about mutations is this whole idea that well you want to let's say I can’t do that with this A.P.I. because it's just a read only A.P.I. But you want to change your data, right. So you want to mutate your data whether you want to add some stuff mutations are basically like a lone word for crowd operations of creating and updating stuff, right. So mutations I want to see if they have any let’s … I doubt it … mutation.
What you can do is create a mutation that says I want you to … there's no mutations. I would have got like a list like let's say create tweet. So, when I'm creating a tweet, I would want to say that I'm going to add an ID of whatever. I want to put a text of Hello. And I can do something like that right. So that's the basic functions as I'm passing a function with some variables in it saying I want you to update with this. The interesting thing about the mutations with GraphQL is that you can also define once you've created something, what you want to return. Right, so for example: like we do this all the time. We do not create in Sequel, and then when we spent an hour looking for the query to go and get the last inserted item. Right, do you know what I mean? It's like we're always doing this.
Mark: And part of GraphQL is like literally if I go under created tweet. I can't demo here because this is not the right A.P.I. But if I created send a mutation of creating a tweet, I could also parse a variables, but also say what I want you to return back. So I can return the ID, and the text again. So once you've done the function you get a return. And you could be the text, the results, and anything else, but it's already like inbuilt to say if I've created this object, or if I’ve mutated this object, I will return you some data straight back and this is actually mutations
Michael: Fabulous, so if you want to use this in ColdFusion is it hard, easy, medium?
Mark: Well, I found two things is creating your own GraphQL server is a little bit harder because normally we go down to Java for a lot of the clever stuff, right. But if you wanted to access GraphQL services, it's pretty easy. It's just ACDP. Right so you might need to get tokens, you might need to do those kind of things which are within the A.P.I. right. You have like other tokens and stuff like that. But essentially, what you're sending over are the queries. The gotchas are that you have to remove a lot of the double spacing. So, as you saw here in this example of got like lots of tabs and things like that though you're probably right. You have to strip all of that out before you send it.
That’s the main gotcha that I found. But it did tell me. It was like this is not in the right format. I don't know what you're talking about. But that's not the greatest thing to do when you first testing an A.P.I. So that was the only gotchas I really got. The rest kind of works the same. You for example send Jason string which has got your queries, and you send it with a query which is your query, and the other key would be your variables which is another Jason within Jason of your variables. And that’s it, and then you get Jason back which you just as you stand really deal with stuff. Something I always use it and [crosstalk] [39:55]
Michael: So it seems a little ironic the GraphQL is designed to make other A.P.I.’s you used to use. You’re calling it as a standard A.P.I.
Mark: Well, as a standard H.T.T.P., right?
Michael: Okay, it's not a REST call then.
Mark: It's not a REST call per se. It’s a H.T.T.P. call.
Mark: Is it REST? I can’t remember. I don’t think a parse is in there. You don't parse a header unless you want it to be a certain format. Because it returns it.
Michael: Are there any libraries that help with using this or?
Mark: At the moment none for … There’s tons of libraries but not specifically for C.F.M.L. I can see building one very easily. Probably, by the time I finish you know if Mark [inaudible] is listened to the podcast by the time that we're doing this he's already written one. I know him. He’ll probably build one that quickly. But there are lot of server side libraries for other languages like node, and J.S., and Skyline and, PHPS central built in there. What's interesting is that there's a Java version that I was investigating and it's used you can do it in two ways.
You can implement it manually in Java. And I was saying each node, and describing each node, and describing your A.P.I. In essence, or you can use something called IDL which is a domain specific language for defining the spec. So this whole schema can be actually defined as a language that then you pass into the Java and it generates all the stops for it. So the problem only will be then writing that, and anytime there’s a query, being able to tie to your query, to your business object. So that's the bridge that I haven't crossed yet. But stay tuned I’ll probably come up with solutions for that by maybe October. We shall see.
Michael: Coming up real soon now.
Mark: Yeah, any time right now.
Michael: So, who's using GraphQL? Does anyone use this?
Mark: Well obviously [crosstalk] [42:08]
Michael: If anyone we might have heard of Facebook. I think I've heard of them.
Mark: Yeah but I mean selling Facebook syncing a list. I don't know how many people doing a lot of Facebook integration right. I think even Twitter using all of it, but I haven’t found the end point yet. I haven’t been really looking. But the one that I was looking in was very interesting for me, was GitHub. So, I think most people use GitHub. If they don't, they should do. But it’s good to manage your repos and stuff like that. You can actually look at your own repositories, look at various repositories, and hit the A.P.I. And I think they're deprecating their rest A.P.I. in favor of a GraphQL A.P.I. Right, so they're going like go check out our old REST A.P.I. But if you really want to use our stuff is going to be the GraphQL 1, and I think that makes a lot of sense because is fairly little processing they have to do on the server side already because it already ties into all their systems.
Michael: And some other ones people might recognize into it who do bookkeeping software, Pinterest,
Mark: Shopify a shop which is
Michael: Shopify, Sky T.V.
Mark: Which anyone in Europe would recognize. And the whole idea is that you're using less resources over the Internet you know.
Michael: And using less of your mental brain packs you didn't have to figure out the A.P.I.’s documentation.
Mark: For each individual object in your system, right. So like for example like even serve the mental exercise that we could have had for trying to get all the different parts of the Star Wars’ A.P.I.’s. Like are we talking about ships, are we talking about starships, are we talking about planets or systems. I don't know you know, right. It's like I have to go look at what the thing was. But even in our exploration just now we just went by, and started like just exploring it without having to know the documentation for that and knowing which fields are they?
What are they called? It’s already in there because you can explore all of that, and then get that query, and paste it into your system. That's what makes it a lot faster than something else. I used a bit of software called poll like docs poll. Which is used to interact with resources. It’s a very great software. I'm not getting you know getting any paid back from them. But even though it's a great bit of software, it does a lot of stuff, it doesn't help me with finding out what's there, right. It helps me do it when I have to do it, but it doesn't help me find out what's there when you're there.
And I really wish I did a lot of work with different payment providers I had a lot of REST services recently as part of version projects. And oh my God! If they were just done GraphQL even not knowing the processes he would tell you these are the functions you can call. These are the mutators to our system you know create payment, create this, create that. I will require these fields because it's already self-defined. I don't have to be reading crappy, crappy payment provider documentation. And they really don't know how to do documentation. For example [crosstalk] [45:17]
Michael: They know how to charge a percentage that's what they [crosstalk]
Mark: They know how to do that, right. But I mean Jesus! One of them had… I don’t know how many people have come across this. But you would expect you know maybe because we were from ColdFusion background. A structure has keys but then the sort order of them is kind of pretty random especially if you add them. I’ll actually specifically say that in a certain order and this payment for the need of the keys in a Jason request to be in a certain order.
Mark: Right so it's like, great, genius! I mean that's not even a part of the spec of Jason, right. Jason can be in whatever order because you could put it. Automatically you could do whatever you like. But it was failing with a non-expressive error which makes me lose more of my hair.
Michael: We were doing this project connecting to the SAML server recently, and they had like really wacky things they didn't document. But things had to be in a certain order, and then sometimes, it didn't matter what the case was, and sometimes it did matter. All kinds of and sometimes the whitespace was ignored, and sometimes you absolutely had to have just the right kind of white space.
Mark: And this is the problem, they don't document that stuff. You only find it out through testing. And when are you testing? You’re testing hitting their system.
Michael: Oh yeah, and then they don't give you error messages back.
Mark: Or they might not give you a test account so.
Mark: You're test is actually you actually running whatever.
Michael: Or they're in a time zone on the opposite side of the world so you send some test requests, and you don't hear back if they worked until the next day.
Mark: Right, so that slows things down a tad [inaudible]
Mark: And those are the pain points that GraphQL are meant to ease or at least get out of the way. Is not everything but there's a … funny enough I just got a spider right in there. Let's see if we can put it in front of the camera. There you go.
Michael: Is there a big spider?
Mark: No, we're in England. It’s a tiny spider. We're not in Peru where you have…
Michael: Yes, could be an enormous spider. Could be the size of that NASCAR line spider. So it is GraphQL faster to run as well, or?
Mark: faster to run
Michael: Well, doing a bunch of REST call.
Mark: Yeah, it would be because you got that network stuff out of the way. It doesn't kind of sit in front of your A.P.I. so we could, but it sits in front of your business plan right. So, you've created a… The business objects to that. Now you do the queries on the backend GraphQL is not going to help you with. But if you are doing the same things, if you add it up to the query times to service 15 requests versus the query time to service one request. And then, you say like well how much return one megabyte of Jason back versus returning 100 kilobytes of stuff for GraphQL. I think you find the benefits there, right? If your A.P.I. is pretty lean anyway. If you're returning True/False variables back, it might not be the best way. But it might be a good way to hit your system to query a system.
Michael: And I know you mentioned an Apollo server somewhere earlier. What exactly does that?
Mark: Right, so Apollos are a whole is a whole bunch of different tools, so as a community to focus or tools for working with GraphQL. So, for example: we’ve got an IOS client, they’ve got an android client, they’ve got a client for react. And it's their own client call Apollo client. And it's also a server which is for essentially for most of the node service and from outside like Express [inaudible] and various different things that allows you to create your own GraphQL interface to your systems. Which are great little tools you can have a look at.
Mark: I think the last thing [crosstalk]
Michael: Yeah, anything else on GraphQL? I guess we should give people why we call this episode let's get graphical.
Mark: What do you want me to sing it?
Michael: Yes singing it. Channel your [inaudible] you know you can join
Mark: When we have to get graphical, graphic comical [singing] [49:48]. Here you go.
Mark: Yeah, yeah, yeah, query, query, query.
Michael: Only here on C.F. Alive can you see Mark Drew …
Michael: Channel, channel Olivia Newton John while coding in ColdFusion.
Mark: Next episode I should be wearing those [inaudible] [50:16].
Michael: Well have a parental advisory on that episode.
Mark: The screen will go all blurry.
Michael: So, anything else on Graph QL before we switch to a related topic?
Mark: Yeah, the last one is a project that I saw called ‘Graph dot call’ which is a back end. So, if you're really wanting to use growth like you're trying to build a mobile app they want to store some data, and you don't really build the backend because you want to build actual data you can actually have a GraphQL backend for mobile, and we have developers already. So you can just go and then define your objects and they'll store it all for you, and provide an interface for you. So that's a really interesting little project there.
Mark: And that's it, that's meaningful GraphQL. And you're going to be … You spoke about this at C.F. objective. Are you talking about it anywhere else?
Mark: Yeah, that's a great segue Michael. I’ll be talking at C.F. camp in October, and NC DEF CON about it.
Mark: I think these are the talks I’ve got accepted so.
Mark: Yes, so it should be good fun. It's nice to travel out to North Carolina, Raleigh North Carolina, and then Munich. And I think it's in the same place and you can check in C.F. camp’s a great little conference because it's in Munich. But it's also in Munich airport, so you can literally fly in, go to the conference, and then like fly out when it's finished.
Mark: A couple days later of course you might have to find a hotel for the night in between, but it's…
Michael: Yeah, just sleep in the airport.
Mark: Just sleep in the airport. Is a great airport, and there’s the bar literally down there. So that's a great because you don't have to this is a prom with a lot of conferences. Like especially the one and C.F. objective I just went to which was in Washington D.C. which is this you for flying to Dulles and you've got like this hour to get from Dulles to D.C. where the conference is I mean you know that because [crosstalk] [52:22]
Mark: Is a big city, DC.
Mark: It’s a big city right, and for some reason each time I have traffic. And I think vicious traffic. I don't think it's a time of the day thing.
Michael: Well, one day, they'll have a metro link all the way to Dulles. I think they have that already.
Mark: They’re building it.
Michael: Yeah, they’re building it. They've been building it for at least ten years.
Mark: They're getting there because I think we're driving back from the airport and I could see all this building work and then as you train. But as you know if you fly to conferences a lot is those travel bits that really necking you out. Because you come out of the plane, do your thing, and then, you have to like through this whole bunch of traveling and [crosstalk].
Michael: The nice thing about C.F. summit in Las Vegas is the Las Vegas airports right slap bang in the middle of Las Vegas.
Mark: Right, right so you go like a ten minute drive or something like that.
Michael: Yeah, just get in a New Bern there, and there you go.
Michael: I guess they're a bit more laissez faire in Nevada about where they put the airport.
Mark: Well, they had a choice. They had a big flat desert.
Michael: That's true too. Yes, it was pretty empty before they started putting casinos there.
Mark: Right, and they say well, we need an airport make it really close and …
Mark: … move over there. But last time I went to Las Vegas was a very long time ago. I don't think the town went out all the way to McCarron. I think it's…
Michael: Oh! It's gone a long way around it by now.
Mark: Yeah, the Las Vegas has been the fastest growing US city for decades, isn’t that?
Michael: I don't know the exact statistics on that, but it certainly has grown a lot, and there’s more to Las Vegas than just the casinos. Because I have a friend who bought a condo there because it was a cheap deal. And he bought it because you get cheap flights from there to all over the U.S.
Michael: It's pretty central. Yeah because I have a suspicion the casino subsidized pricing flights.
Michael: Yeah, but I was talking with Alicia from Adobe about C.F. summit. She was telling me all the exciting things happening there. [Crosstalk]. Yeah, it's all going to be a Mirage this year apparently.
Mark: It's also at the moment, and tell me if I'm wrong. Isn't it the Adobe developer week of them?
Michael: Right now, it's happening right this moment, yes.
Mark: It started yesterday. I got my notification yesterday, so I jumped in on a webinar there.
Michael: We've been tweeting about it.
Mark: What’s this Twitter thing you keep on going on about? I want to join.
Mark: Now I am on the tweeters. But yes, that’s a good one. When is the summit? C.F. summit.
Michael: November fifteen, sixteen; is it? I don’t know the official… Just before thanksgiving for those who celebrate.
Mark: A random [inaudible]
Michael: Actually, I think it's Thursday the sixteenth, Friday the seventeenth. But I think there might be an optional thing on the fifteenth. I'm a little
Michael: I'm trying to remember if they had an optional day the day before. I think some … I'm sure someone maybe autists or someone else is doing some training the day before.
Mark: They're very clever with autism in that they were like awesome at C.F. objective. They run their training the days before. They're also run some sessions during it as well as all that their machine I mean.
Michael: Yes, they are. And I think with some training the day before C.F. camp as well.
Mark: I would not be surprised. I mean to be honest, that's genius because it makes as a presenter at conferences, or as a sponsor. Even if it doesn't make all the money back or anything like that at least it’s chipped off that the edge. It takes the edge of all the flights, and stuff like that. And the time that you take to take off to do these things, you know?
Michael: Yeah, and it gets definite. And it gets the word out I know Preside is doing a training the day before.
Michael: And they definitely are not doing it for the money because they're only charging like five dollars or so.
Mark: Right but it's really worth it for them, right?
Michael: Yeah because they want to get more people using their C.M.S. So you know, I mean unless you're buddies with a Pathan [56:46] which is their logo. You may not even have heard of Preside. So this is a chance to get the word out and get more people using it. It's an open source C.M.S. So, it's not like the thing cost any money.
Michael: But you know…
Mark: Getting the word out. That’s the whole point.
Michael: Yeah, well thanks for telling us all about GraphQL today, and giving us your [inaudible] [57:12] John impression.
Mark: I hope this is not the only takeaways, but yeah.
Michael: No, I think the takeaway was for me that makes using A.P.I. is a lot easier and faster. Both for development and for when you run the code so.
Mark: Well, you're most welcome. I like being on the show. I mean now that you're on YouTube, you also have to like, and subscribe which…
Michael: Yes, like and subscribe please and actually, what the usual think I ask is please leave a review on iTunes. Because the reason is the more reviews we get, the more when people search for stuff apparently they throw things up in the search results higher.
Michael: When you have more reviews.
Mark: I have to do that for my podcast.
Michael: People are searching for ColdFusion or GraphQL.
Mark: Well yes, or no come up right? Also, and CFML. So like you love the C.F.M.L./ColdFusion, GraphQL.
Mark: Right, you just part of a screen like this just write this into the review I guess.
Michael: Maybe we can do that. I try and keep the editing on these things simple. Anyway, thanks for joining us from London today.
Mark: my pleasure
Michael: Beautiful sunny summer day there.
Mark: Yeah, let's say that it is.