 Hi again everyone, we are going to start the talk now and I just wanted to remind all of you to please post any questions or queries you may have either in the Q&A section or in the chat window. Also you can minimize the chat panel if you want to enlarge the screen as sometimes the video or the screen doesn't show in expanded way. With this, we'll start about in a minute. Let's take the eyes with Rob. So the agenda today, we will start off by explaining the use case for the example that I'm using in this talk. Then I'll show you the application example of an application as it's called with JSRS. I'm going to describe the problem I'm going to undertake with you and then we will convert that application to a ROKR application to show how ROKR solves this problem and then melt it in ROKR. So what we're going to build is an application called ROKR application. ROKR application or ROKR application. So think of 50 miles or something like that where you get points for doing services. So we have a personal objective which is to remember all of this program, this one's all about the ROKR application program. And that's quite a big objective and contains quite a lot of information about that person and that person has a score. And then you will obviously want to have some view on this from a web page or a cell phone or tablet or something. So let's start off with showing you the REST application as it's built already. A high level design is something like this where we have a person service which stores the person data in a database and it exposes the data with the REST API, personal REST API. And we have a score service that stores the score in a flat file and it exposes it with a score REST API. And then we have the model that model the person and the score and everything that goes with it. Okay, so the application is already running on my machine. Let's look at the REST API. So you'll see this is a normal API that exposes this on slash person. It injects the back-end service, which is the one fronting the database. And then we expose two operations on here, one that gets all the people back in one call and one that gets a person back by IV. Very basic. So if we look at that, so this runs Quarkus. So in Quarkus we have a QDef console that shows the dev console. And here you'll see you have a link to your swagger UI. And this was just a nice way to test out our REST APIs. So first of all, we can do a get all or get all the people. And you can see that we've got all the data back, but it is quite a lot of data. And if I'm only interested in the name and the surname, this is a lot of data that I bring back over the wire just to be filtered out. I can also do a person by IV. But again, you can see that it brings back the whole person object, which is quite a lot. So that's over fetching. It's fetching too much data. And I only want specific fields in there. And then somewhere in this set is a number, which is the score ID number, which I can now use to fetch the score because that call didn't include the score. So now I can get the score back. Right. So if we go back to here, the problem that we have is overfetching and underfetching where the overfetching is fetching way too much data that I don't want. And underfetching is that I couldn't get all the data in one call and I had to make a subsequent call to get more data. And then the worst part is the combination of the two, like I've shown here where both calls fetch too much data, but I had to do two calls to get everything that I want. So let's look at GraphQL and see how GraphQL can solve this for us. Before we do that, a quick history of GraphQL. Facebook developed it initially and then open sourced it. It's now hosted under the Linux Foundation as a specification. It's been positioned as an alternative to REST, even though you can use them together. It does declarative data fetching and Facebook specifically started doing this when they saw an increase of mobile usage. So suddenly the APIs that typically served the web now also serves mobile applications or websites. And the real estate on a mobile phone is obviously much less than a website, so they want less data. They've been doing it since 2012 and publicly since 2015, so this is not new anymore. So if we go back to our high level design, we're going to change and we're going to replace the two REST APIs with a GraphQL API. And that's it. We'll keep the model the same and the backing services the same. Okay, so let's get into that. So what I'm going to do is I'm going to copy this REST API and paste it here. And I'll call it person GraphQL API. Okay, let me make it bigger. So we now want to tell this is a GraphQL API. So all of this is either open API or Jax RS. So I'll replace this with GraphQL API. I'm still going to inject the backing service because that's where I get the data from. This I'm going to replace with ad query because in GraphQL, when I fetch data, it's called a query. I can also give it a description. I don't have to. This is for the schema. And similarly here, I'll make this a query. And that's it. So I've converted that API, the person API to a GraphQL API. So let's quickly look at what does that kill us. So if we go back here, you'll see that we also have a GraphQL UI, which is very similar to swag and UI. It's just the UI that allows you to test your inputs. So the first thing that I want to show you is that it comes with a query with a schema built in where with Jax RS, you have to add something like open API to get a schema. And the schema you can reverse and look at all the fields and what's available. And because it has a schema, I can also now also now have code inside. So I can do the same query as what we've done with REST. So let's call all the people. But the difference now is I can tell it I'm only interested in the names and the surname. And now you can see that my payload is much smaller. So that already solved the overfetching problem. Similarly, I can do person and I can say with the ID one, get me back that person. And again, solving the overfetching problem. So what we want to do next is see how we can solve the underfetching problem. And what I want is I want to have a scores field on here, which I don't have at the moment. So to do that, I'm going to go back to here. I'm going to copy the score service from the REST API and paste it in here. Okay, and then I'm going to modify this that used to be a REST endpoint. And the difference now is I'm not going to make it a query. What I will do is I'll say that I want to add a field called scores on to person. So here we'll make it a source field. And we'll say when the return type is a person, then add this field to it. And here we can say get ID number. So now if I refresh this, the new schema should contain a field called scores, which I can now traverse deeper into the graph. So I can say, yeah, I want the name and the value back. Now I get back the person details that I want. And I also get back the score, everything in one call. So I've solved the overfetching and underfetching problem because I can make one call and get back exactly what I want. And similarly, let's show this quickly. Right, so clear the log file, close this one. So similarly, if I do people, it will also return all the scores for the people. The problem when you do return a collection like this one is that the way in which this work is that we make a call to this method. And then we see that you also want this. So we make a call to this. But now if this is a collection like here, and there's 10 people, we will make 10 method calls to this, which is not necessarily efficient. So what you can do is you can actually say let's patch this up. And we will pause in a list of persons or people. And now this should be people. And now I can do something like this where I get all the IDs as a collection from the people. And then I'll make them into a list of IDs. And then I can pass the IDs to the backing service. So already this is the previous call you can see in the log file gets all people. And then every time that I find a person, I make a call. And now if I redo this, you can see that I'm getting all the people. And then I make one call to this course service passing in all the IDs. So it's a bit more efficient. And that's called batching in GraphQL. The other thing that I can do is I can actually do multiple requests. So if we go back to person here and we say, and we spell this correctly, we say ID equals one, right? So that will get me person one. But what I can do now is I can say person one. So I named this query and then let's say I also want person two back. But for person two, I only want the name of the surname. I don't care for the score. So now I can do person two and ID two. And now I get that back. So I can combine multiple queries into one, like in this example. And the return type doesn't have to be the same. So in my example now, I returned person in both queries. But let's say, and like I said, this is an application that does, let's say, frequent flyer miles. And as I added benefit, we will show you the exchange rate for the place that you are flying to. So we already have this exchange rate service. So all that we're going to do now is we're going to add the exchange rate here. And then we'll add another source field similar to scores, but for exchange rate. And now here you can see an example of where we not only pass in the source field, but other query parameters that can be passed in. Right. So now I can change this to be person one. And I also want to add the exchange rate. I must refresh. So now exchange rate will be here. And now I need to say against. So we've got it, let's say to the UK. So we want, yeah, we want down and we let's say we only want the right back. And now what we also want to do is we want to say that the weather in London, two will be whatever something. So let's add a weather API. And this is a brand new API. It's not a source field onto person. It's just a new GraphQL API that returns the weather. Okay. So let's refresh here. So rather than a person, we can now remove this. And here we can say we want to back. We can remove this and say we want the weather for London. And we want the minimum and the maximum and the description back. Okay. So now I've gotten the exact data that I want to get in one call. I've got the person, the score, the exchange rate and the weather. These are all different types that I'm returning. And I can combine that's many queries into one, basically exactly saying what I need to display my page. Next, I want to show asynchronous. So at the moment what happens here is that person gets called. And once I get the person back, we have enough information to call exchange rate. And then I get the full person back and then I only call weather. But there's no reason that person and weather needs to be sequential. They can be concurrent. So what you can do is you can do something like reverse. So let's just add that one, get weather, remove it here. And we now make it a completion stage. Right. And then the same with person. So here when we say get person, we will say we want a person back as a completion stage. And for now we'll just do that. And right. So now I should be able to call person and weather at the same time. Now, if you look at the previous call, you'll see that we called person and then we got the exchange rate. And only then we called the weather for London and got that weather back. Where now we can actually say call the person, get the weather, then the exchange rate, then got the weather. So I actually called weather and person at the same time. Now, similarly, I can, let's say I'm traveling to the UK and then to the US. So it's a multi-city. Then I can do something like this. So now this will be USD that I want back. I now have to name it because it's small and warm. So we'll say this is the UK and this is the US. And then I want the weather back for London and I also want the weather back for New York. Yes, that's now great. So now I can get person and both of these weathers concurrently. But I also want to get these two concurrently because once I have person, there's no reason that this exchange rate should wait for, you know, or this one should wait for that one. So to do that, we can just change exchange rate to also be a completion stage. And here I should be able to do that. Okay, if we now look at the log file, you will see that we get everything concurrently. We're getting the weather, the weather and the two exchange rates and now we start getting it back. So a much more efficient way to query in certain cases. Okay, the last thing that I want to show is partial responses or error handling in GraphQL. So as an example, let's say that the score system is down. So what we'll do, we'll just simulate that by saying throw a new runtime exception here. And we'll say that the score system down. Right. So now if we go back here and just remove this to make it simpler. So you can see that I got an error. It didn't say school system down. It said server error. And that is because I throw thrown a runtime exception and by default, runtime exceptions and hides the message mostly for security reasons. That's configurable. And then I got the data back that I could. So I could find the person, but because the score system is down, I couldn't get that. But I could give you partial results. And in terms of the error, you can throw your own exception like this one. And so rather than a runtime exception, we'll throw this and throw it. Right. And now because by default, this will actually show the message. And again, this is configurable. So if you don't want to show this message, you can in configuration say that that shouldn't happen. Okay. That was a very quick overview. So what we've done just to recap this, I've shown you how GraphQL solved over and under fetching by using queries and source fields and batches. I've shown multiple requests, which you can bundle requests into one. I've shown how you can use asynchronous to do stuff concurrently. And I've shown errors and parcel results. If we look at how batch works, if you return a collection, so multiple people, if you don't use batch, it will call the source field for every person on that result set where if you batch it, it can do it in one call. For asynchronous, you can not only call multiple queries concurrently like person and weather, but you can also call multiple source fields concurrently like the exchange rates. Now, what didn't I show you? What else can we do with GraphQL? I didn't show you how you can also transform data. So once the data comes back, it can be transformed and you can map it to a different type. You can do mutations, which is when data changed. So that is an update or delete or create. And that works exactly like query. You just annotate your method with mutation. You can do subscriptions, which also looks exactly the same way. You just annotate the subscription and then you get a stream back. Let's say every time a person gets created, you get a copy of that person. Then you can do introspection, which is quite interesting. It's a way to use GraphQL to query the schema, your own schema. And then we also have clients in Quarkus and soon in the spec. And they are very similar to the JAXA REST client. And it works very similar to that. And the type safe one is very similar to the REST client, the micro profile REST client. We have integration into JSONB, into security, into context propagation, into being validation, into metrics and tracing and generics. So it works well with all other specs, the related specs. And that's it. I think it's now time for questions. Thanks, Philip. It seems at the moment there are no questions, but let's give a few more minutes to our audience. And I just wanted to thank you for sharing such an awesome information with us. Also, it would be very great if you could have some time to upload the presentation to your abstract in the schedule, so that it would be available for other audience. I think that's what I need to say. Oh, okay. Then you're set. Thank you. Cool. I also share it here on the chat just for in case. Okay. And will this presentation be available to access for everyone? I think so. Yeah. If you have the link, you can access it. Yeah. Yeah. Because sometimes we might need an access, so I just wanted to make sure. But if you have already done it. Yeah, it was set to access, but I've changed it. Thank you.