 Thank you all for coming to hear the talk, thank you to our sponsors, our organizers of GX for the venue, Pyxelami, Platonus A, Chennai, Acquia, Zepalspa, and GoBev. I'm Pavlos, I work here at GX, the person responsible for taking care of our CMS we probably can guess is building Drupal. It can be found on drupal.org and the following Slack channels, the general Drupal Slack, the Vancouver Drupal user group, and the recently made Drupal SQ. It's my LinkedIn and Twitter if you want to connect. A few things about myself, I started doing Drupal about 80 years ago. I graduated right in the midst of the financial crisis, so what I graduated from and where I ended up is two very different things. At the time, someone suggested, as I was looking for a job, someone suggested why don't you build a website for yourself, try to promote yourself. That guy was into Drupal, so naturally he suggested Drupal, and I built one and the rest, as you say, is history. What we will go through today, we will briefly touch on chat-less Drupal. We will see how GraphQL compares versus normal rest. We will touch base on the GraphQL module. We will check out what the GraphQL explorer is, what are persisted queries, or in the Drupal easy that we have, what are query maps, and if we have time at the end, we will look at some examples. Practically everyone is here right now, shared of the couple Drupal and chat-less Drupal. Here at STX, we wanted to... We have a lot of web applications. All these web applications, one year ago, were drawing from their own systems for their content. So if an author had to write an article for the mobile application, they had to go to the application that supported our mobile app. If they wanted to write the same article for the website, they had to do it again through the website CMS. And there are other applications that wanted to use this content, but there was no way for them to do that. So naturally we wanted to consolidate all of these into one system. We didn't want the author to have to write the same article a lot of times, and maybe they would make errors, and we need to check that article over and over again. So we ended up with wanting to do a content repository system. The CMS of choice at that point was Drupal. We also wanted, as the slide says, free the front-end. Our front-end, there's a specialized in JavaScript. They have no idea what Tweak is. They are not interested in writing any Tweak templates. They know their JavaScript well. They can write their CSS and they're happy. So what we need to do is just provide them the JSON feed of our content. They can consume it. They can display however they want for whichever application they want. Also, this is future proof. If tomorrow our front-end developers decide they want to scrub the entire front-end framework that they use and go for React, we don't care. It's totally up to them to do whatever they want. So how does GraphQL compare with REST? Because we did explore initially various module spreadsheets. We went through the Drupal call REST. We went through JSON API without that point. At that point in time was then that fleshed out yet. We looked at exporting JSON through views. But we ended up in two GraphQL for two main reasons. One reason was that the front-end just wanted to do one query or one call to the endpoint and fetch the entire page. With a normal REST, especially with a pure REST tool, the API, we couldn't do that. We would have to fetch a page or the node, then go through all the references and fetch all of those one by one until we can build our page. With GraphQL, we can just do one query and fetch the entire page. That's particularly the case for us because we are using Paragraph extensively. And as you know, Paragraph are entity references. So that would be a lot of round chips to the server just to build a page. You can achieve the same thing with JSON API right now using the SAP REST module. But for us at the time, GraphQL was the way to go. What is GraphQL? GraphQL is based on a schema. It is self-documenting and it's meant to empower the consumer instead of rigidly defining on the back end what your API is. So we shouldn't, we don't worry about, oh, I built this API, but now the mobile applications need to consume it. But the mobile app doesn't need as many fields as the website does. Do I need to build an API? No. I just let my mobile app talk to my GraphQL endpoint and then request only the fields they want. They don't need to get any more than exactly what they need. So how does a GraphQL query look like? Let me know if that slide is not very visible. But the GraphQL query basically consists of fields like our title, our type. It consists of argument like in this case what type of node I want to bring in. It consists of operations like the node query. So in this example we have right here we're going through a building a node list basically consisting of the content type code page. It consists of directives which unfortunately I don't have an example of here. So a directive is a way to manipulate your query on the slide so you could have an if statement in the query where you could check one of the variables passed and then if that variable existed you could add more items to your query. We have our fragments which in this case is our page fragment at the bottom. These are used kind of like a switch statement would be used. So on our entities field there our entity can be a page, it can be a landing page, it can be an index if we show which any content type that you may have on the slide would fill in that place there. So we don't want to keep writing all these fields that we need to fetch every time we want to call the page content type. So we define our fragment and we just pass it in what else is special for this field. So the GraphQL module. Development is done on GitHub which is predominantly maintained by two guys working for Amazey. The current version is better than I believe. It could have been created. There is a very good example implementation on GitHub. Documentation is not the best, but it has come a long way since it started using the module. It's based on the Webonics library and it comes with two modules out of the box. The GraphQL module which provides the integration between local and Webonics. And the GraphQL core which is an automated schema generator for your Drupal website. When you install GraphQL core your entire Drupal site becomes available for your GraphQL endpoint basically. That may sound a bit scary, but don't worry because the module does adhere to the entire permissioning system of Drupal. So if you request the notes from the GraphQL endpoint as an anonymous user you will only see what you have permission to see. Nothing more, nothing less. And it uses Drupal core's type data API to define that schema. The GraphQL Explorer. This is where you will do most of your debugging for the queries. So this is a very simple query to fetch in my home page with its header. As you can see I am passing in the path, the language, the key things to note here is the empty URL fragment which basically tells the query if the path that I've given your results to an entity then catch me that entity. And through that we go and say is that entity a landing page? Yes, then bring me these exact fields. Nothing more, nothing less. Your documentation is right here on the right-hand side. As we said, our GraphQL is fully self-documented so anything that is available to you you can see and debug here. You can see your history, you can define the variables. And this is how you can test your queries quickly, prototype them and see how they work. A few notes here. This does post request to the GraphQL entity. GraphQL doesn't just do post, it can do get. So you could serialize this entire query and pass it in a get request in the query variable. Most people think that GraphQL has to post because of some either server limitations or browser limitations that impose a length limit to your get request. We can get around that by using persistent queries. So persistent queries not only allows you to execute as whatever get request you want without worrying about any variable links that the browser or the servers may have, but they also allow you to lock down your API. So a frontend client will never be able to do a query that you haven't allowed through your query map. So if we go back to our GraphQL module, there's two ways that GraphQL module discovers the query map. You could either define a directory somewhere on your server where all the query maps get uploaded, or you can upload them straight into Drupal as a configuration entity. I choose to do it this way because I can export it version-controlled through Drupal's config system. Also because even though the frontend likes the power of defining their own query map, we kind of restrict them on what they are able to do. So we still want to maintain some control and query maps is the way we do it. As you can see, these query maps are hashed. So the hash here is the version of each query map. What that means is that the module basically serializes the entire query map file. It hashes it, and that's your version. So anytime you do a change, your version gets updated. If I inspect my query map, I can see what operations these query map aligns. I can get, for example, my page. This query works for any page on the site. I have fragments in there that can be landing pages, basic pages, large devote pages. So we can't throw anything, no page and no path in this query module will return something. We can return the menus because we cache those in separate from the page. We have query tools in our taxonomy terms, our index list, and so on and so forth. So if an operation is not defined in this query map, they've thrown them, cannot execute it. They will get a photo field. If we didn't have that, honestly, our security team would have made it. Anyone out there, because our APIs are public APIs, could just issue query after query to the server with no limits or huge limits and basically do a denial of service attack on our website. So this is my way to avoid that. For the future, we want to move on to having authentication on our site. As I said, all our APIs right now are public, but we're bringing in applications that require privileged content. So we're looking about how to bring in all of us to our KW tokens to help us with that. And we will want to then try to start doing mutations. So mutations is how you do a post in GraphQL. If you want to create a node, you need to do your own mutation. Now out of the box, GraphQL, the GraphQL module just gives you the API to achieve that. You still need to write your own mutations for anything that you may want to bring in. Also, all those query maps I've shown so far, they're just consumed by the website. We want to move into a space where we have one query map per application. And for that, we're looking to contributing a module back to the Commodion to better manage that list of query maps and their aliases, let's say, because a hash doesn't really tell you which application this query map is for. So the ecosystem so far, we've already seen the GraphQL for module. There's GraphQL automated persisted queries module. What this does is it allows the prondent to define its own queries and when they get posted or sent to the... rather requested from Drupal, if they don't exist, they will get created. Basically, again, this is something you will want to protect. Otherwise, anyone can start generating query maps on your site. We have the GraphQL meta type module which provides the integration between Drupal GraphQL and the meta type module that we own. We have the GraphQL redirect module which allows for GraphQL the query we had before for paths. It would allow that query to follow every direct through to the node it will install. For the less adventurous of us, we have the GraphQL tweak, which just exposes the GraphQL and allows the GraphQL to be used through the tweak templating system if you want to do some progressive decoupling. And last but not least, we have the GraphQL use module which allows you to define new queries based on views. So these could be used, let's say, in a scenario where you want to integrate with search, API and solar but there's no GraphQL solar module yet but you can use the GraphQL because search API has a good integration with views, you could use GraphQL views to go through them. Some resources that I've drawn from for you are here. Feel free to check them out. Please download the module, test it out, find bugs, help us get it to a stable release and we'll make these slides available as well. Thank you. Do you have any questions? I don't know. The module does have its own cache mechanism and it's basically following the cache types of viewpoints. I'm sure you can do that. For now, we're just utilizing Drupal's internal cache with nothing externally. It's working pretty well for us. The moment you... because it's realized heavily on the cache tracks, the moment you publish something like a node or the common exchange of paragraph anywhere that cache track is used is expired and we have the... we have the cache right now set to the maximum and we haven't seen any issues yet. There's nothing else but all I have right now I realize it was a shorter talk than I am to speak. Sorry about that.