 Good evening everyone. Thanks for having me in Denver. My name is Pertik Patel and from Atlanta, so I'm not enjoying your deftly dry humanity here. I don't know how you people live in this dry environment, but Atlanta had been sought at least 90% humanity after the ocean. So anyways, thanks for having me. I work at IBM doing Java and cloud and other things. I'm also a Java champion and do lots of other stuff. And also in Atlanta, one of the other things I do is I help run the Atlanta Java user group. And we put on a little Java conference called DevTaxes. It's in his 14th or 15th year. And we even let Matt speak at the conference. He's coming back to speak again this year. So we're expecting a big crowd this year, about 2200 to 2500 people, 15 concurred tracks. People you know like Ben Kat and Matt, Neil Ford, other folks like that will be there. You should come check it out. It's run by the Atlanta jugs. So it's a super low-cost, nonprofit conference, but probably the biggest Java conference in the US now. Okay, so anyways, come check it out. It's in the first week of March and it's DevTaxes.com run by the Atlanta jug, which is just another jug, but we have a conference. So anyways, so before we launch into this and talk about GraphQL, I just want to mention quickly a word from my employer, IBM. IBM is a massive contributor to open source and specifically open source Java. And these are just some of the open source things that IBM produces. And a lot of the open source tools, for example, OpenWisk, is something that is an open source project from Apache, of course, but that is what powers IBM Cloud, for example, for various different things. So anyways, IBM, tons of open source stuff, open liberty, Eclipse Foundation, etc. So you should check it out. And I think you all had a serverless person from IBM come recently. Is that right? Maybe a few months ago? Yeah, it's been married. No, married. Upgar. Didn't he come here recently? Okay, there you go. All right, so I'm not crazy. All right. So in this session, we're going to talk about GraphQL. We're going to do an introduction. So this is an introductory level GraphQL session. But the more interesting part for many of you as Java developers will be, how do you implement a GraphQL server in Java? Okay. So before I launch into this, how many people are currently using GraphQL or know what it is? Okay. All right, good. So it feels like most people don't. So for those of you who do, just read Twitter for the first 30 minutes and then come back. Okay. But we will show implementations of GraphQL server side stuff in Java towards the end after we do an introduction. Okay. Actually, while I'm taking a survey, how many people use Spring to build Java applications? How many people are using EE? Okay. So it's about three people out of 60. It is what it is. So anyway, it's GraphQL. So GraphQL, first of all, as you can tell from the name, is a query language. But it's more than that. It actually defines schema and a few other things. And we'll get into the details on where the edges of GraphQL are and where the edge of your application and the code that you write will be. Okay. So GraphQL, you might be thinking, well, why do we need another query language? We already have SQL and we write code in Java and JavaScript and maybe you're using Kotlin and other things like that. But GraphQL solves a very specific problem, which is how do we interface or build APIs in a more sane way? Something a little bit more sophisticated than REST. I assume everybody in this room knows what REST is or has built APIs or built a RESTful endpoint. It's relatively straightforward. We'll do comparison in a bit and talk about that. But at the core, GraphQL is an API query building language and specification. More than anything, it's a specification. And we'll talk about the origins in just a second. But as we're going through and talking about GraphQL, keep in the back of your head that we are specifically tackling the problem of how do we build nice APIs. It doesn't matter if you're using Java in the back end or some other language. Most of this talk is applicable for any back end system that you're using or front end system for that matter. So GraphQL is normally meant to be consumed in web browser using standard JavaScript. But there are GraphQL libraries that you can mix into Android or into iOS development or whatever. You can even do server to server communications using GraphQL. We'll get into some of the nitty-gritty details in a bit and we'll show you how some of that works as well. GraphQL was created by Facebook back in 2012 and they open sourced the specification in 2015. So it's been around for a little bit of time. It has gone through a couple of iterations, no major iterations, but we'll talk about why GraphQL is interesting compared to REST and other ways of building APIs and connecting to those API endpoints. All right. So first of all, GraphQL is a specification. There is not necessarily like a reference implementation which is what you might expect from a specification. So anyone can do an implementation of GraphQL. There is a client implementation which pretty much everyone uses which we'll talk about in a bit. But again, GraphQL is more a specification on how you should build and design your API interfaces and kind of the plumbing that you do in between plumbing is not the right word, but kind of the motif around it. Now, you might be thinking at this point, we just built our API. We just switched off of SOAP and we just went to REST. How many people are still using SOAP, by the way? Anybody? It's okay to raise your hand. We won't really kill you too much. At least one person. You mean one SOAP endpoint. Okay. Right. So you might be thinking, well, we just finished rewriting everything from SOAP or whatever you were using into REST for APIs. Now you're telling me that, okay, maybe I should start or we should start looking at GraphQL rather than REST. And of course, in technology, everything moves forward. Like especially nowadays, it feels like technology moves forward at an increasingly rapid pace with open source and all the other things around it. But one of the things I want to emphasize is that you don't have to throw away all the infrastructure you've written in REST or even in SOAP. You can actually use GraphQL to wrap your existing APIs and other things that you have and unify everything into one place. Okay. So it's not an either or kind of situation. You can actually build a GraphQL interface into your application and you can wrap existing RESTful endpoints if you want to. Okay. So it's a great way to do migration or transition or actually you can keep all your RESTful APIs and you can keep them for as long as you want, but you can put a nice wrapper of GraphQL around it to make it easier for front-end developers to go and get stuff. Okay. So it's not a pure replacement for REST. It's slightly, might just cut out for a second. Okay. But the way I like to think of GraphQL is that it's just another tool in your tool belt. Okay. So I'm not dogmatic about most things when it comes to, well, computing at least or software. So like I said, you can wrap your RESTful APIs or you can wrap your SOAP API or you can wrap anything. When we do a demonstration, I'll show you how you can actually wrap, for example, a GIFI service if you want, right, and expose it as an API endpoint using GraphQL. All right. So any data source can be underneath and it doesn't even need to be a data source, right? It doesn't have to be a database or whatever, right? You can wrap any kind of thing that you have access to programmatically underneath the hood as in GraphQL API endpoint. Okay. Okay. So the question is, and please ask questions, otherwise I'll be done in 30 minutes. Well, that would mean we'll get to the bar faster, which is a good thing, but no. So the question is, what about a file system? It absolutely wraps a file system. Okay. And again, when we go and look at the implementation in Java for how we build out a GraphQL server, you'll see how easy it is to do something like that. It's actually, there are a couple of different tools we'll talk about, but the one tool that I want to highlight makes it very easy. So you can wrap a file system, you can wrap, like say you have some kind of stock trading application or infrastructure, you can wrap something that serves stock quotes off of a TCP pipe if you want. So you can literally wrap anything. Now, unlike REST, where you have multiple endpoints, if you take a REST, you may have, for example, a RESTful endpoint, which you're exposing user configuration, user config, right? So you'll have a URI on your server called slash user config, and you use the four HTTP verbs to go and get data, change data, delete data, etc. Right? And then you'll have a, I don't know, let's say you have a department or whatever other endpoint. So you have slash user config or slash shopping cart to go get or item or whatever, right? So you have these different endpoints. So when you're building stuff out of REST, one of the things that you have to do as a developer is that you have to have documentation that is completely outside of the actual programming in terms of these are all the endpoints you have, because eventually, as you're building these endpoints, you have to give them to somebody and say, okay, here's the endpoints we have. This is what you can use to go and build our front-end application. Yes or no? GraphQL will work with Swagger, yes. Again, GraphQL can wrap anything, right? But it's up to you, the programmer, to do that. Whether you like is free, as you know. So you have to do, you do have to write some code to be able to glue whatever you have in the back end that you wish to expose through your GraphQL endpoint. But you have to write the wrapper or whatever to make that thing work. All right. So unlike REST, where you have multiple endpoints slash users slash idler slash whatever, GraphQL has a single entry point, right? That entry point is arbitrary, but people typically use slash GraphQL as the entry point into your GraphQL API. But that's the only URI that you actually have, right? We'll see why that is in just a second. The other thing that's unique about GraphQL is it is schema-based. So GraphQL, the depth, the specification relies very heavily on the way that we think of schemes, or basically you have to build up a schema. Now there are a couple of different ways, depending on the server side tool you're using to build a GraphQL server to build up a schema. You can do it using a DSL that they provide for you, or you can just do it programmatically, which is what I do, because I don't like to write coding a third language where I can be as lazy as possible and just have the actual code document what my schema will look like. And the schema basically is what is it that we're exposing in our API? So key differences with REST, we have multiple endpoints and we don't have built-in definition of what our API looks like. We have to document that somehow, right, as an external job or work that we have to do. In GraphQL, when you build a GraphQL server, the schema is defined by the way you build the server. So you actually get a schema definition for free as you're building a GraphQL server, which is awesome. And we'll look at a tool in just a second where you can introspect, actually right now, where we can introspect existing GraphQL endpoint. So let's jump over here. And this tool that I'm using, is that too small? Do I need to make it bigger? Is that okay? Matt, can you read that? Okay. Are you on laser? All right. So this tool that I'm using is called GraphiQLG, R-A-P-H-I QML. And this is just like an open source tool that you can go and get. And you can actually bundle this tool inside of your own GraphQL server. And if you're working in the job world, you literally just go include something in your Maven palm file, basically a GraphiQL starter, and it automatically adds everything you need to be able to run this. Okay. So you can do this like literally by just adding in a jar file into your project. All right. So let's do some queries. There are a couple of key verbs in the GraphQL specification. The two that we care about are query and mutation. You can probably guess what query does. You can probably guess what mutation does. Query is a way that you go fetch data and mutation is a way that you go and change it, right? Whether it's changing or deleting data. So we're going to just do some queries real quick. And let's actually go and clear this out. And one of the nice things about having this schema that's provided is that you can have a nice tool like this where say you're new to the company or you're new to this project or you're building out a new feature and you don't know what all the APIs look like on the background. You can actually go introspect and look at what's available to you. So what I did there is I just hit control space and it brought up this browser. So I can come in here and I can say give me all of the starships and from there, right? Oh, that name doesn't work here. But you can see as I type this out, it actually tells me what's available inside of this specific position in the schema. So I go get my all starship starships collection. And then I'm going to go pick the name and let's go grab the, okay, we'll print the ID out to it and we can do that model. And then let's go and see, let's just run this for now, okay? And we will run this and you can see the data we get back. You get all starships, starships and you can see kind of maps what we have on the left side in terms of our query, then the name of that starship and then what the model is, etc. Let's see which one is the biggest of these. I think there's a length. No, not the length. Okay, we'll do the length as well. And then what's the biggest crew that we can fit onto these guys? Okay, all right. So there you go. So what I'm doing is I'm basically exploring a GraphQL endpoint here using GraphQL to go and kind of build out a query. And when I write GraphQL queries, this is what I do. I'll go in and say, okay, I'm building this specific feature. I'm going to pull up the GraphQL. I'm going to just start basically interactively playing around to get to a point where I interactively build this query and say, okay, this is what I need. I'll copy that and I'll drop it into my front-end code and I have exactly what I need. Okay, I don't have to like fill around and look at documentation. It's very interactive and almost sounds like fun, right? Okay, so we have our starships here. Yes, sir, good. Okay, so the question is, is the left side on this paying client? So this entire thing, this whole thing called GraphQL that we're looking at here, is basically just a web application running in the browser. So it is actually running on my browser, but when I go and say, go run this query, it's actually going to the server, grabbing the data and then showing it in the right page. So it's actually making a round trip to the server when I go and actually execute the query. When I do this, when I go in here and I pull up the tooltip or the hint or whatever you want to call it, that is all actually just running in the browser, right? Because again, GraphQL has a schema that you get. So that means that the client is able to suck that schema down into the browser and it basically just runs all this long. Yes, one second. I have to remember how to do this because I don't actually ever look at the schema. Actually, I'm going to do this as a different browser window. Okay, it looks like this server doesn't specifically expose the schema directly. So one thing we can do here is... No, you're right. It is getting it from somewhere, but for this specific example, I don't know where it's getting it from. But yes, let me take your question and answer a completely different question. Is that okay? You don't need to look at the schema because if you look at the raw schema, it'll be huge and it is not really human really. It's the best way to put it. What you prefer to do is in the tool right here, what you can do is you can pop up in the documentation explorer and you can say, okay, go look at the root. The root has all these things inside of it. And then let's go look at the planets. And then here's my planet info. This is all the stuff inside the planet. And let me go find... Right, that's what I'm trying to get at. Is that you can go look at the schema or something like this would be huge because it contains a whole bunch of stuff in it. But it's easier just to look at the schema browser and you can just play around. You can see I clicked on species here and it can go and it tells me if I then drill down into species. The species object contains a name, a classification, blah, blah, blah, blah, blah, right? So you can actually go browse the schema directly in the schema browser if you want. But looking at the schema in its raw JSON format or GraphQL format to be specific is not very useful, okay? More questions? Okay, so the question was will the schema auto update when the data behind it changes? The short answer is yes. The long answer is we'll cover that in more detail in a few minutes, okay? Yes, sir? Okay, so if you're selling an API as a service, which is basically what you're asking, right? How do you basically document and let your client access it and how do they just basically use it, right? So what you would do is you would incorporate GraphQL as part of your GraphQL server. So they would go to GraphQL.yourcompany.com or whatever and you would expose that as a public endpoint or maybe a security endpoint for your client to go and look at, okay? And yes, you can also, there are other tools you can actually get where it will take the schema and like draw a nice diagram and stuff like that too. Okay, so all that is possible. Did that answer your question or did that answer a completely different question? The short answer is yes and no. But I tell you what, as I go through this, if I haven't completely answered your question, why don't we come back to it, okay? All right, so we have our, let's go back to where we're here. All right, so I just want to do a couple more queries to give you an idea of what kind of powers involved and what options you have for this. All right, so in this specific schema, if we go into here and we see somewhere in here, there should be this thing called filled connection. So we have Star Wars Starships here and this specific, this specific GraphQL API exposes all the Starships and all the films that the Starships appear in. So you see I've picked film connection here, so I can go into here and say, go and get me the films that it appears in and give me the name of that film, title instead, okay? Let's go run this. And now you'll see that we've traversed in the relationship. So Starship contains films, or it may actually be the other way around I think, but the way that's modeled here is that Starships appear in a film. So there's this connection or this relationship to films. And so when we ran this query, you can see that CR90 Corvette appeared in these three movies. And let's just scroll down to a more esoteric one. It looks like the A-Wing interceptor only appeared in Return of the Jedi, et cetera, et cetera, okay? But anyways, the point here is that what we did is we went from the Starship object and traversed into the film object now. Yes, we have a question. Yeah, so the comment is, this kind of looks like, we just looked at a relation. So is this specifically for relational databases or no SQL databases or what? The short answer is to be friendly, okay? So you can have, for example, you could write a GraphQL API server that uses a GraphQL job of course, and then you can use Postgres behind it, or you can use Neo4j behind it, right? Or whatever you want. You can even have a in-memory Redis cluster that sits behind your GraphQL API, and you can just go reach it to the Redis cluster and get data from that and expose it as an API or expose it to the API. So again, you have to code them. It's not like you're just dropping GraphQL Java and they're like, oh, okay, everything is closed. You actually have to go in and say, I want to expose these specific things that I have or entities or whatever you want to call them to these are the things I want to expose into the API, okay? But it can be Postgres or Oracle or DB2 or Neo4j or Cloud Ant or Couchbase or whatever, like the Redis back and start to be anything, and or like somebody else asks, you can even expose something else to the API system if you want, okay? But that's because you as the developer have to program that. All right, so we've traversed a relationship. We've looked at some things here. Let's see, let's do one more thing here, right? So it looks like the Starship thing has quite a few different fields in it. How do I just go and get all of them? Let's just get rid of all this and we'll just take this out for now too. Let's just try to do this now, right? Let's like star wild card. Let's just go get everything. Let's see what happens. It says syntax error cannot parse the character star, right? The reason for that is unlike REST in GraphQL cannot get everything that is in an object or an entity. You have to be explicit about getting the things that you want, right? So there's no way to do a wild card in GraphQL, right? We'll talk about why in just a minute. So I'm going to leave a little bit of a cliffhanger there for me about this. Make sure you don't fall asleep after all that beer and pizza. All right. Yes, man. Ah, okay. So excellent question. Now, saying that I just want to do some testing where I don't want to use GraphQL to get this stuff, right? So what I can do is I can just go and invoke this directly from, there it is. Okay. All right. So here's a curl command. Let's make this bigger. There's a lot of stuff here, but I'll zoom in on the part that we care about. Here's our end point. So again, I'm just running this demo locally, right? Or this is a different demo. But anyways, I could go point it at the other way. And if we go, blah, blah, blah, blah, blah, whatever. If we go here, you can see here's query. And here's a curly brace, cars, ID, name, is the car cool variables. We'll talk about variables in GraphQL in a minute, right? But yeah, so I can go run this from the command line and you can see I get my data back. Or if you want to, you can also go and I have the same thing running in Postman. Does everyone know what Postman is? It's basically a way just to call JSON endpoint or anything for that matter. So in my headers, I have set up the local host and a bunch of others. You don't need all these headers. The only ones that you need actually, the only one that you really need is the content type, set the application JSON, everything else, you don't really need it all. But this is like a complete example. And then if I go to the body, you'll see I have query, cars, the stuff that's in the cars object, and then the rest of the GraphQL stuff that you need. And I'll go run this, make sure it works. This is hitting a different API endpoint than we were looking at. But you can see there it works. Can I answer your question? Okay. Yes, man. That is interesting. I know. I'm glad someone's awake and paying attention. So thank you. Let's go look at our posts. Okay. Where do you see get? Yeah, that's right. So this brings up a good question. When you typically make a call to a GraphQL endpoint, you will use post because you have a body, right? And is it even possible to send a body along with the get request? I know it's out of spec, but you know, we're programmers, so we do things, you know, we don't care about the rules, right? We're trying to make things as esoteric and difficult as possible. So, so, so yeah, so you basically, you have to use a post, right? I'm sure you can do it with a get or a code or whatever. But since you have body, and I think the postman example actually, this is the postman example, right? You can see that I have it's at the post, I have the header set. And of course, the body is in here in URI encoded in this specific case, or JSON encoded to be specific. Okay. And actually, this is sending it, you can send this body as either just text or as binary. Okay. So it's, that doesn't really matter to be honest with you, because usually your query is so small that is the data that's big. All right. So let's make sure we've covered everything here. We talked about there's simple query traverse collection, starships, you know what we didn't talk about. So, so one thing that we can do here, I'm not going to go pull this off, you can just look at this and get the idea. But if you look right here, if you say you just want to get one starship instead of everything, it's a ID, blah, blah, blah. And of course, you can have multiple discriminators on this to say, I want something I want the starship that's in the color white and has a crew of at least 500 or whatever. Right. So all that's all that basic stuff in terms of being able to do GraphQL commands queries by parameters as possible. Okay. So there's that. And one thing we didn't talk about is variables. Let's just look at that really quickly. If you remember, just from a second ago, when we looked at this postman, we set the query, and then we set this variables. In this case, this was done. So what you can actually do is you can actually construct a GraphQL query where you use the dollar sign and you say, this is the variable that I wish to have. And this exclamation point here means that that is required. Okay. So you cannot not have it. And then you can see we use that variable right here, but we go create the starship. And then in the variables segment of our request, we include starship with the ID, and that will get picked up as a parameter here and substituted into there. Okay. So you have a way to design queries which are flexible. You don't have to, you know, we're not cave in anymore. We don't do hard string concatenation to do these kinds of things. We use variables. Okay. So the ability to do variables is here. All right. So it's a quick fly by about that. When you talk to briefly about how can I get every field in object? Because it's very likely that eventually you'll have an object that has 25 or 50 or 100 fields or something. Right. And short answer is you can't. Okay. It is deliberate actually in the GraphQL specification that there's no kind of, there's no wild card, no way to do a wild card to get everything. Okay. And this point is when people like literally just walk out and say, so you tell me that for my 50, so I have my user config object which has 40 fields in it. And every time I need to use that in GraphQL query, I'm going to have to type out all 40 of those fields. Right. The short answer is yes and no. You will have to do it at least once. Okay. We'll talk about fragments in just a second. Okay. But so what you do is you use something called fragments, which are reusable definitions in your GraphQL. So you don't have to type out those 40 fields every time. You just type them once in a fragment and then you reuse that fragment over and over. Okay. But in GraphQL, you only get what you asked for. You do not get everything. There's no wild card. But you can get everything you need in one call. Right. We haven't done a query like that yet. So let's go do that real quick. So let's go back into here. Let's control Z this out. And let's say that you have something in your application where you want to show all the starships and you want to show all the species in the Star Wars universe. So if we're building this as a RESTful application, what would you need to do? You would have to make one call to the slash starships endpoint. Again, this is REST. You get all your starships and then you make a second call to all the slash species endpoint. And then you get all your species. So you had to make two calls to get that. And this is one of the key advantages of GraphQL is that I can query disparate objects in the same call. So I can come into here and let me try to get this right. I can say all species, species, name. Okay. And this is a bit of a contrived example, but a more real world example is when the user first logged into your shopping portal application, right? What are you going to fetch? You're going to, you're going to have to use this logged in, you're going to fetch the user config, all the items that they were looking at in their history, and all the items they may have left in their cart. Those are three completely different things, but you want to fetch them as quickly as possible to get the user up and running with GraphQL. You can just fetch them in one shot with one single call. Okay. So now if I go run this, if I scroll to the bottom, you can see that here are, so here's my starships right here, and you can see here's my species right here. So what we did is we actually queried two completely disparate objects in the same call. So instead of making two calls or three calls or four calls to get those four different types of information, I can just make one call and get everything in one shot. Yes, sir. So this is a good question. Why is there all starships and specified starships as well? Okay. So the GraphQL specification, basically everything I've discussed so far, what it does not get into is how you specifically design the collections and the objects and things like that. So I would probably not do it like this necessarily, but this is, the short answer is it depends on the developer. Typically what people like to do is they like to have a collection here. So if we go into the docs, let's go back to here for this specific endpoint. So the reason why it's modeled like this, so if we just look, for example, let's just go to all starships. So the reason why it's modeled like all starships and then starships as kind of the actual object is that all starships is not actually an object. It's not an actual entity if you will. The starships is the actual entity. Now all starships is you can think of it as like a repository object. You can use JPA. Are you doing what with JPA? So or Spring JPA, right? It's like a repository, right? It's like a way to access the actual underlying entity that's underneath it. If we look at the documentation here, you can see one reason that people would want to do that is so that we can do pagination. So here I could say, give me all the starships after the tenth one or give me the first one or the last one or whatever. So it is specifically, in this case, it's used specifically around being able to do pagination. Just one second. So one thing that we can do here is let's go back to our previous example real quick. So we did this before and let's say the feature calls for I want a list of all the starships and the first movie that they appeared in. In this case, the data is giving us the movies in chronological or time area, right? So what I can do here is and I'm going to get this totally wrong probably. We'll do first colon one or hit enter and of course that didn't work. What I do wrong here? What's that? Was that free within the all starships? No. You know what? Let's try it. I did warn you that I would screw this up. So there you go. Thank you. All right. So what this is done now is I'm getting all the starships and the first movie that appeared. Okay. But in discriminator and it's a good question though, right? If we look at this, go back to this real quick. This case, pagination, you don't have to build it like this. Yes, sir. Okay. So the question is, what is this query syntax? It looks kind of like JSON, but you are correct. GraphQL is not JSON. As you can see from this last example I ran where I have the friends and first colon one. So GraphQL is not JSON. We always get back JSON, right? You've seen in the right pane, we've always gotten back JSON. GraphQL is not JSON. It is its own language. I don't know what they based it on or whatever, but it's its own language. Okay. All right. Let's get back to our slide real quick. And so we get everything in one call. Which is nice. So let's talk about some of the advantages over this. And we'll also talk about some disadvantages over the rest of you guys. So the two common problems when building REST APIs is what's called overfetching and underfetching. Overfetching is you go get slash user config in a REST API and you get all 40 fields, but I don't want all 40 fields. I just need five field dials, this REST for endpoint. What do you do to solve that in REST? Well, I know there's some people in here who built REST APIs recently. How do you fix that specific problem? The greatest thing only returns you a subset of the objects, not the properties in the objects. Right. And then you have to do some additional processing in the background. Yeah, you could do that. But what's that? Right. And so the typical option here is instead of having slash user config, you say slash user config for console or whatever you create a separate endpoint, which does what you said, which is just has like the specific things. And yes, you could pass in as a query parameter, but again, that's, it all feels a little messy, doesn't it, when you get to that point. Right. So as you've seen so far, GraphQL specifically solves the overfetching problem. The other problem with REST is underfetching. And we've demoed a solution to this already. Right. I want to go and get all the starships and all the films that those starships appear in REST. What do we have to do? We have to go and make two calls to go get those things. It's called underfetching. In GraphQL, you just say, I want this thing that's over here, but I want this completely unrelated object over here. And you can do that in one single query. And so GraphQL solves the underfetching problem as well. Okay. And of course, if you've done JavaScript before and you need to make four RESTful calls back to back, you sank into the morass of callback Helen JavaScript. And yes, there are ways to, are we recording this bet? He's not, he's not listening to that. I was going to make a joke about JavaScript, but since it's being recorded. Can you edit that part? Like five seconds? All right. Anyways, there are ways to ameliorate the callback Helen JavaScript, but in my opinion, it is not as nice as I would like it to be when working in JavaScript to, again, sidestep callback Helen issues. Yes, sir. Yeah. So the comment is, say I want to change something. Like I just want to change the color of a starship or whatever, right? But, and I don't want to change the other 10 fields inside of it. When we do that in REST, we have to do a couple of different things where we create a special endpoint to do that, or maybe we provide all the parameters and just to change field with the change in it. In GraphQL, you can just say, go and just change the name on the starship or the color of the starship or whatever. Yes, you can do that. And that is allowed by the specification. However, it's up to use the program to be able to know that when I just see a mutation in GraphQL come into my server and just the colors provided, that that means that I should just update the color on that specific item. So if you don't program it properly, you can go and completely nuke everything that's in that specific object and just update the color. We'll get into the implementation a bit and hopefully it will be a little more obvious in terms of how when we build a GraphQL server, what we have to do to be able to make it conform to the specification. Some of the edge cases like that, that we have to think about, but not necessarily obsessive. Okay. Was there another question? Yes. So the question is, is say that you have a enumeration in your data type or in your, in the object, let's just call that. Is tool smart enough to say that I want all the cars which are made by yeah, what are the enumeration for the type for a lot of cars or in fact, I don't know the answer to that question. Let me think about that. Maybe you'll come to me towards that. I don't believe that is possible in GraphQL, but I could be wrong. All right. So let's push on. And, right, someone already asked this question in, slightly asked this question. In REST, it's harder to update multiple resources. If you want to change a user config and a shopping cart and item at the same time, you have to make three separate calls to do that thing. Just like in the GraphQL query where we were able to go and fetch disparate objects, we can make mutations to disparate objects in the same GraphQL query. So you can say, change the user config and change this and change this and change this. And you can press one fields and whatever data and everything like that. So the idea is that you can optimize over a single call. So, is GraphQL handle rollback and transactional logic? No, that's your job. You have to code whatever that is that you're doing. If everything is in one database, that's super easy as you know, right? You just write a JP query, you start a transaction, you go up to those three things, you end the transaction, everything works. Everything goes through everything goes through. If not, you get a rollback, right? But if they're disparate data sources, then you have to code that sometimes, right? That is outside of the GraphQL specification. It does not tell you how or what to do to handle those things. All right. So in some ways, GraphQL is faster because you can go get just the data you need. You can just make one call to get that data. And also it's a little bit simpler in terms of API and architectural design, okay? And I put those in quotes because there was always had cases there, right? So there are cases where it may not necessarily be faster, it may not necessarily be simpler. But on the whole, it can be simpler, it can be faster, okay? All right. So I'll probably talk about wall cards, but let's talk about them a little bit more. Why is it that we don't want the loading fetch or I do a wall card fetch, right? There are a couple of very good reasons. This is why they're resisted. If you go look at the GraphQL GitHub issues, it seems like every now and then it's always like, why can't we do wall cards? And they just like get shut down eventually after much discussion. But the point of not being able to do wall cards is around systems design, okay? So your front-end developer, so back-end developer somewhere, maybe in the same building or maybe halfway across the world, goes and makes a change to your API server and removes the field that you were using. You start, you spin up your, you're going to write unit tests for your front-end stuff, obviously, integration, whatever, end-to-end tests. You spin it up and you get error or something that maybe you don't even get error. Maybe like everything just works, but on the UI, there's some bit of data as this, right? That is the worst possible outcome as a developer is when something changes and it's breaking, but it doesn't trigger some kind of test failure, automated test failure. So what happens in GraphQL is if someone removes a field inside an object and you're still referencing it in your GraphQL query, you get a big fat note error. So it's very explicit when the API changes in some way. You know that something has changed and you need to accommodate for that change as the front-end developer. Similarly, if you add a field into something, say you add a field into a object and that field is very, very large. If you're using a RESTful API, now you're getting the stuff that, you know, that you already get and then you're getting not like all this extra stuff, okay? And you don't want that. We're basically exacerbating the overfetching problem in this case, right? Because in REST, they're just, oh, here's a new field that has a whole bunch of stuff in it that you're not using. Don't care about it, right? So again, being explicit helps you with the overfetching and underfetching problem. It also helps with overall systems design and testing. That's why you have to be explicit about it. Okay? So let's skip that. All right, so app breaks in all these ways. Overfetching on newly added relations. So what happens if you add a relation that goes and fetches a bunch of stuff? Now you're getting a lot of data, right? So that's why we don't have all types, okay? So, but there's a way to add more areas, as I said before. We use something called fragments. So say we had users and we're always going to get the ID, the username and whatever stuff. So what we can do is we can create something called a fragment. And in this fragment, we say this specific fragment contains these things. And then when I want to use it, I can reuse it over and over by doing dot, dot, dot user fragment. And that basically will just go and pull these fields in. Okay? So one person has to write this thing one time or write out all the fields one time. And then you don't have to do it over and over when you have different types of queries. Okay? All right. So with that, let's step into GraphQL and Java. And there is one library for building GraphQL servers in Java. And funnily enough, it's called GraphQL-Java. Okay? We will look at this very quickly, because GraphQL-Java is a low-level library. And I prefer not to code in low level, if I can help. I prefer to code at a higher level, using cool things like annotations in Java that make my life easier and make me write less code because I'm not a good programmer. And the more code I write, the more bugs I make. So I like to write less code. Okay? So anyways, the library I like to use, which sits on top of, let's say, Raps, GraphQL job, is called GraphQL-SPQR, or pronounced GraphQL speaker. We'll spend more time looking at that. But let's have a look. And if you, you know, I like to throw a diagram every now and then. You have a people idea of what, like, we're actually building up here. All right? So we have a database at the bottom, typical use case. We'll use something like JDBC or JPA. We put our GraphQL stuff or our GraphQL Java on top of that, and that's how we build our endpoint. Okay? So this is kind of what our execution stack looks like. All right. So in the end, the data can be anything. It can be our DMS. It could be a NoSQL database. It can be a file system or whatever. It's up to you. See that? It comes in just a second. All right? And when we're building stuff with GraphQL, building up server implementation, you can wrap anything you want, but you always have to think in terms of API design. Right? What am I exposing? Am I exposing too much stuff? Is this the appropriate types of things to do? What relationships do I need to expose to make the front-end developer successful and efficient in building what they need to build? All the basics of API design, you have to still keep in the back of your brain. All right. So let's do a quick demo, drop into IntelliJ IDEA, and let's get the correct application down here. All right. So first what I'm going to do is I'm just going to do a quick fly by of GraphQL Java, a low-level library. All right? So let's start with, actually, let's start at the end of the object. Okay? So here's our book. And you can see here's at entity, which is JPA. And in here, we don't have anything that is GraphQL specific. It's just a plain entity object. Okay? There's nothing in here, but let's go look at this repository. This is just a spring repository for that. Now let's get into our resolver. All right? So now this is where we're getting into GraphQL stuff. So you can see your book resolver implements GraphQL resolver, and it passes in the specific type that is wrapping, which is book, right here, which is highlighted. Okay? So this is our resolver, and our resolver, in this case, has one thing, which is get off. Okay? Now we'll look at how we build a GraphQL query. Again, this is on the server side. Say class query implements GraphQL query resolver. We pass it in the book repository that we were just looking at. And then here are the functions, which are actually exposed by, which are actually exposed as GraphQL queries. Okay? So for this specific example, we would have something called find all books, find all authors, count books, count authors. Those will all be things that we could use in a query. Okay? Similarly, if we go over to mutation, which we haven't looked at mutations, but mutations look exactly like queries, except you pass updated data. We have mutation, implements GraphQL mutation resolver. And then inside of here, it allows us to do new author, new book, delete book, update book page count, right? So these are things that we can use when we make a GraphQL mutation call back to our server. Okay? But the important part here is we're using GraphQL, GraphQL mutation resolver. And the way we stitch all this together is we go and is, oh, what they have, we haven't talked about errors yet, but I'll get into that in just a second. Okay? And what we do is we go and grab these resolvers that we created, and we basically stitch them together and give them to the underlying GraphQL Java library and initialize the library with the resolvers, which give us access to the mutations of the queries. And again, I went through this very quickly just to give you a feel for how coding this in the low-level library works. What we care about is using GraphQL speaker and doing it a higher level. Yes. That's right. So the GraphQL resolver actually looks very much like a spring data repository. And it is a corollary to it. But let's jump to the next example using GraphQL speaker, which is much easier to follow and much easier to code. Okay? I was going to do that now, because that's what we really care about. Sure. All right. So here is our entity object, right? So it's car. In this case, we're using Lumbuk instead of writing out all the getters and setters. So that's what this at getter and at setters, right? So you can see I've imported Lumbuk here, right? And Lumbuk two-strain, Lumbuk equals hash code, right? Again, because I'm super lazy. I don't like to type all this stuff out, okay? But here's our entity object. And right here, right in our entity object, you can see what we do is we say include this as part of the GraphQL schema definition at GraphQL query, name equals ID. In this case, you can see I even gave it a description. Where would that description be used when you browse the schema in GraphQL? Okay? So you actually go and annotate this, and you don't have to produce additional documentation because everything can just be put directly into the GraphQL schema, which you can then browse through GraphQL or whatever tool you use to look at, okay? So I go expose the ID and the name here. Let's look at the car service. This car repository is not interesting. You can see there's, this is just JPA and spring data stuff. We go look at the car service. This is the interesting part of it, right? So there's our repository in here. And at GraphQL query, name equals cars. If you want to get a single one, here's car, at GraphQL mutation, save car, at GraphQL mutation, delete car, et cetera, et cetera. Okay? And the final piece of this, that's just setting up sample data. Come on, open up. Okay? Is our little controller here. And what GraphQL speaker does is that we don't have to define all the dissolvers and this and that and kind of leave everything together. We just go up in the annotations, at places we want to, specific bits of the data we want to expose in any object, and then we have some kind of service object where we go to find the queries in the mutations, which we were just looking at a second ago. And then we use this long fragment of code here to go and have the GraphQL speaker annotation scanner go and find all those annotations and say, go find all the annotations, build resolvers out of them, go find all the operations, build them with this specific thing, value macro factory. This is just something for JSON. And then we say, go and generate the schema. So these lines go and scan all the annotations we just saw. They dynamically build up the schema from the annotations. And then we initialize the GraphQL Java low level library with the schema that we just built from the annotation scanner. And then the rest of this is just spring MVC stuff, post mapping. This is our GraphQL endpoint and go and grab the query. And you can see we do an execution. This execution is basically our entry point into our underlying GraphQL schema to go and execute stuff. But anyways, the point here is that it's super simple. You don't have to monkey with this once you've set this up because this will just go and scan everything. We create our entity objects. We annotate that with the fields that we specifically want to expose using this. And then in our service, we go and create the queries that we wish to expose and the mutations or the changes that we wish to expose through the API. So the question is, is this controller that I have here, is this application specific? It's up to you. Not necessarily. So basically, if you look at the actual endpoint here, you can see this post mapping is just a spring MVC annotation to say expose this. And of course, we're taking JSON in, returning JSON. And this is the GraphQL part right here where we say, go and grab the query, inject it into the GraphQL engine, grab the raw HTTP parameters, build it out, blah, blah, blah, and then go and run it against the GraphQL spec. And whether it's a query or a mutation or whatever, just go and execute it with the underlying stuff that you got. So you never need to touch this once you've done it once, unless you're building different services. In which case, you would just copy and paste this code or something. And of course, what you could do here is you could also expose multiple different GraphQL endpoints if you want. Questions on the code, is there anything that you want to dive into? This thing is relatively straightforward, but I just want to make sure that it really is this easy. This is the hardest part. And I actually just copied and pasted this, remember I'm lazy. So I just copied and pasted this part. And for my own projects, I go and build out the services, get the queries and the mutations that I want. And then I go and annotate my existing JPA objects and just sprinkling the Add GraphQL query to expose the specific fields that I want to expose. And I should have a demo of this somewhere, maybe not. Oh, here it is. Okay. So if you want to see that thing that we were just running in action, there it is. So one of the things, oh, there's one thing I want to talk about real quick. So, so far, I've only talked about exposing the actual JPA entity data objects. But I have this thing in here. And this is a demo I actually found online. I like so I just, we basically repurposed it and changed a few things around. But what this specific thing does is it goes and grabs a Giffy. Everyone knows what a Giffy is, right? A Giffy is essentially an animated GIF. And there's a service where you can say, give me an animated GIF of like a fire. And it returns you like, oh, here's a bunch of animated GIFs of fire or whatever. Right. But what this is doing in here is it's going and hitting the Giffy API. Okay. And then down here, it's making an HTTP call, reaching out to this API when we get the result back. We go and actually just include it as part of the data. So this is not something that's in a database. We're calling an external HTTP service. Say, hey, give me a Giffy of this thing. We're taking the first URL that gets back and including it as part of the data. Right. So it's not even our database. It's just an external HTTP service somewhere. So if I could go, if I go into our application or sorry, our editor here, I'll say, give me a Giffy URL. I hit enter. And this will take a second because it's actually reaching out over the Giffy API and populating it and returning it as part of the aggregate result that I'm seeing here. And so if we take this out and I hit run this, you'll see it comes back instantly. Right. But because this is actually reaching out to the Giffy HTTP endpoint, it takes a minute to go and grab all that stuff and then we're returning it. Okay. So again, we can wrap anything. You don't have to necessarily just wrap the database. That's what you typically do. But you can also wrap some underlying service that you have lying around or an in-memory data grid. We're using something like Terrapato or Hazelcaps. You can just reach into that and say, give me some data out of that as part of this GraphQL query. Okay. All right. Any questions on the code before we move on? We're near the end. Don't worry. The beers will be upon us soon. All right. So again, I like to use GraphQL speaker because I don't want to program Java like I did in 2002. All right. We use some annotations. So in this case, we said at GraphQL query for cars will get me all the cars or reach into the underlying thing. We went annotated our actual entity objects to expose the specific fields or properties and then car service. These slides are here twice. All right. So the demo that I just showed in Java, the GraphQL server demo I just showed, was using Sprint and Sprint Boot. It doesn't have to be that. You can write this in virtually anything. All right. So you can run. There are a few EE people in here. So you can actually just use the same thing with the Java EE project if you want. Okay. Or you could just write like a standalone server that speaks CCP or whatever. Because again, GraphQL does not necessarily specify the transport. It doesn't specify anything except for the specification. Like GraphQL is just a specification. How do we define the schema and the things around that? All right. So if you use something more exotic than an HTTP endpoint. So one thing that you could do, for example, is you could set up a message meeting. All right. If you're using message meetings or if you're just pulling off a RabbitMQ or something, you could just set up something that's reading off a RabbitMQ or off of a message queue that is implementing GraphQL server and somewhere on the other end can drop GraphQL as a payload inside of the JMS message. And you can have something over here that reads that GraphQL goes in one's queries and returns a response all over JMS. So it's transport agnostic. All right. So stuff that we did not talk about. We didn't talk about authorization or authentication. We didn't cover features like pagination or subscriptions. And we didn't really go into mutations much, but they basically look exactly like a query and other ways to like kind of do changes. And with that, I am at time a minute or two for questions. And if you follow me, you win a free life, by the way. So please do that. All right. Am I am I about on time? A few more minutes. Okay. Well, one thing I've learned is you don't keep people from free beer. It's a good way to get your ass kicked.