 Welcome to the improving the developer experience using GraphQL. Actually, we should improve the experience using, you know, presenting us, I mean, doing a session on a really live room. And, so my name, it's kind of blurry. So my name is Susmano Olivas. You can find me as J.M. or like as Oliver Place. And I'm a founder of agencies, Opti-Hydrate. We are, you know, there's agencies, we focus on modern front-end tools and CMS integrations. We also do a lot of automation and self-managing architectures. We all started running away from Drupal. I was getting back to Drupal some time. I think that's the story of my life. Left Drupal at some point, then Drupal announced Symphony. At that point, I was hooked to Symphony and I figured out, you know, now I can probably go back and then I created the Drupal Console project and yeah, that bring me back to Drupal and Drupal 8. And then I was like, I used to have another company and then I decided to start a new company and we're gonna focus in like front-end, you know, modern-end tools and automation and all that. Jumping into the jazz.world, trying to like fully decouple using different CMSs and then we'll just get back to Drupal. That's for a reason, because it's great of doing structured content and it's great for building websites. We have tried like all the other headless CMSs and we'll see them getting back to Drupal at some point. And what we'll learn from the other project system, they just draft QL to expose to their API and this is something we want to bring into Drupal because then a Drupal has JSON API on the core and it's great. With the developer experience with PDFQL, we think it's better and we really focus on developer experience. You know, same thing happened on Drupal console. You know, Drupal 8, it was created, it was released and it was really, really hard to create something, to create a module, create a controller, a routing, everything in that form was so complicated so we decided to start this. And also the reason was the developer experience. We want to have providing great developer experience for other things and for other people using Drupal. And same thing with this, which we're trying to do the same thing right now, but now with GraphQL, you know. It's like, again, there's nothing with JSON API, it's great tool, but we think the developer experience is kind of better. And before jumping into the topics, what's developer experience here? So developer experience describes the experience people have when using a product. In this case, the product is Drupal, right? And it really, really matters and really matters the same way that user experience is, and not Drupal, it's also not the best on user experience or editorial experiences. It's always, it's great for doing all the, again, data structure, and it's there for extending and the protruding spaces and the ecosystem is great, but then the editorial experience is kind of, you lack something, even if you compare it with other projects, for a little more than that. But again, as I mentioned, I've been jumping into using all the others, intentful, sanity, grassy MS, all the others. And those tools provide a great editorial experience and great developer experience, but they lack a lot of the features that you can have out of the box. Out of the box, or adding custom modules. And finally, when your users are happy with your product, guess what? They're going to use that. They're going to, and in this case, your clients are going to use that and ask for more Drupal sites. And yep, then, so what in why? What about GraphQL? Well, what is it? GraphQL is a query language for your API. What couple of the benefits of GraphQL is you can ask only for what you need. Think about this. When you have a resource on Drupal, you know, I've known with gazillions of files, but it happens when you request or on a REST, you know, REST, NPO, negotiation API, NPO. You ask for that research and all of the fields came on the response, right? You know, like 20, 50, whatever fields. And not only that, if you need to ask for references, then you need to start like, you know, having the includes and all that. So it's like, it's either you have that whole of the research, all of the properties from the root entity or model. And then if you want to, then you need to like do something different, you know, like include this, that, that, and having the writing loss queries is a little complicated probably. And with GraphQL, it's a little different. So whenever you have a resource or a model or a type that you only want a couple of fields, you just type those and that's what you get. If you need a reference, you can use reference name, you know, that something or your curly bracket something and that came out of the box. Obviously that depends on how your GraphQL was created. But in the end, you can ask for what you want and only that and get exactly that. And finally, you can describe the shape of the data that you are querying. I want this type or I want this property for this type, get a Yeta. It also provides you with a great introspection. So I mean, you can ask the API, you know, what, how is this built? All the types, what the types are, what the definition of those types are. You can ask to that, you know, which queries do you have? Which mutations do you have? And basically there's something called exploder on the GraphQL set of things. I want to show you how this looks like. We can see it. And it tells you all of the fields, again, properties and queries and mutations. And there's also something called docs, which is documenting self-documenting API. So it's pretty cool that, you know, because probably we like to write code. Probably we're not that great at writing documentation. That helps a lot in the GraphQL set of things. And what about the GraphQL ecosystem? What is this developer experience? I mean, it gets better with this. There is something called, there are a couple of projects that I'm going to mention, three of them. GraphQL, which is like an IDE for your GraphQL. You can jump into that and start typing your, you know, types, your queries and all that and everything you will be able to query your endpoints. There's another, probably like more like, like GraphQL on improve a little more advanced which is called GraphQL Plagra, which is a similar thing. Funny thing about those two projects and GraphQL, you can start typing and auto-complete is out of the box. So you don't need to know which properties you are looking for. You start something like title of T and then auto-complete for that. And that's great. That gives you a lot of like speed while you're working or starting to work with an API. And if you want to have all the auto-complete, auto-completion, and if you want to have all those queries in your code base, you can do that. There's a project called GraphQL code generator is to see a lot that you run that CLI reads the metadata definition or do the GraphQL introspection on your API and downloads all that on your system. So you can have all that in your BS code project and you can have all the auto-completion there on your code base. So basically you don't need to guess how the queries are named, how the types are named. That allow you to download all of the objects as type objects. You can say either TypeScript or JavaScript. So basically you can get all the data, all the definition in your code base without doing nothing other than running a CLI. So basically all that is in your code base. So you can start using that right away. And how about the Drupal and GraphQL system? And this is where things are getting a little not fun. Gonna put a Drupal and how about this? So getting a little back in the past, the version tree of GraphQL in Drupal out of the box exposed with queries and mutations and all that, but probably was exposing way too much that you really needed, right? So every single content type field and property was there. The naming convention was kind of clunky because you know Drupal field underscores something, right? And then it's kind of like whenever you need to do something on JSON API, something relation, something else, relation again and then something else and relation again. Think about that, but mostly on the GraphQL set of things, it was also the way the relation were generated was little, then it wasn't really, really attached to the GraphQL spec and that was really stopping us from, at least as a company, us like using that version. It was like, it was doing the job but probably wasn't doing like properly attached to the GraphQL spec. It doesn't include the UUID, things like that that really, really, you need it if you really wanna take advantage of GraphQL. It doesn't have like queries per content type. It wasn't like node queries or something where you say type, article, type page so you don't have this like idiomatic queries that can help you to build things easily. But it was, it works right out of the box. And then once version G was released, you know the code base, it's great. It's more like a foundation of core of tools. Basically allow you to build things in top of that. But unfortunately, none of the automatic queries, typing, mutation was there. So basically you'll install the GraphQL module and as usual in Drupal, congratulations, you have nothing. But then, you know, we take a look at the code base. We really like the way it was built. It'll provide you with something they call data producers which allow you to pull data from the CMS and have that exposed on your system. But again, unfortunately, you have to write a lot of code. And then we get to the point like, should we write code generators for this? Do we really want to get back to, you know, the Drupal console thing like 10 years ago? And like, probably, or probably not. Probably we only want to focus on a universe of people who's like really confident on the CLI which is happy running into the terminal and typing things because we all love like mechanical keyboards, right? And we like to type in things, but not everyone is like that. And then at that point, if we work on that, because we would think about it, it's like, they need to run a command that is gonna read, you know, the data, you know, Drupal, introspect Drupal definition, context types, whatever, and then create files and now you need to commit those files in your repo and you don't create a pull request and send to a project then having a continuous integration, continuous delivery of the system that run on the build and deploy to you. Lucky if you have that, because most of the people doesn't have a lot of that. I mean, unless you are using something like canteens or whatever, those kind of systems or you have your own created, you know, get your actions or whatever. But then we decided, you know, that is gonna, we're going to limit the amount of people that really can take advantage of this. And we really want to make this a product that people really, really embrace and use there. So we decided to go in the other direction, kind of follow what version three was doing, enabling the module and boom, everything is there. So this is where the GraphQL Compose module was created. The reason is, is really take advantage of the GraphQL for core foundations and allow you to expose all the typing and queries and all that. And really important note here, when we started working on this project, it was a lot of work that need to be done because, you know, there's a lot of code to write. And then I find out there's an excellent project called OpenSocial. I don't have any of you aware of that. It's a distribution or, I don't know if that's called same in Drupal like distributions or profiles or whatever. And that project, it was exposed in GraphQL. And they have a great API. So I contact them, I contact Alexander, which is, I don't know if you have meetings. He was, he's one of the retainers and I contact him and you know where I'm working on this, you guys are happy if I can use somehow steel, most of your code. You know, this is open source and have it in our module. And then we only write the wrappers and the data introspection of Drupal and make that, obviously we make changes on that code to make like more, you know, friendly to interact with. And again, instead of writing code generators and creating files on the fly and all that, we do that all that on boot time. We understand Drupal very well. So we introspect content types, paragraphs, taxonomy, we extract field definitions. We know the types of that. And then we use that code as, you know, as Drupal plugins, yada, yada, yada. And we expose and create this schema and all those type definitions and expose this GraphQL API. So again, a lot of the code on this project, it's base is fire, inspire and copy paste it from that project, but they are very happy to. And we can define the Drupal GraphQL Compose as a tool to generate GraphQL schemas and also the name, it's GraphQL Compose. The name is also inspired on a JavaScript project that it's called GraphQL Compose and I like to do the same thing. You know, like it allows you to create a schemas and type definitions. So basically, this project's inspiration of all the projects because this is how open source works and we love, you know, how other people take advantage of what other people work. And again, the main goal of this project is provide you with the GraphQL API, which is basically GraphQL spec compliant. We really wanna make sure they got compliant. The reason for that, it's why we have this spec compliant. Then we can have this work with other systems. You know, we can have this use with other projects. We can like easily work and having since we have a single UGU ID, we can implement ways to approaching caching and all that. So again, we really wanna make sure that was GraphQL spec compliant. And so this is what we got. And then one of the main goals was to improve that developer experience in Drupal. That's why, you know, provide you with the right tools to do the job, make your life easy and enjoyable. Right? And how this project works. So this project provide or create a new GraphQL for matter plugin. So basically, you create this plugin and this plugin contains the definition of the data producers that can take advantage of the pooling data from Drupal. So basically, it provide you with the plugin or allow you to have great plugins that, you know, I wanna use this data producer, these other data producers and those data producers are contain the code to pull data from Drupal. Basically like the resolvers. This is how you, you know, if you wanna talk about GraphQL lingo, this is the resolvers. Which is, and that's already there. So basically, again, it's respect all the data, Drupal definition of content types, currently supported content types, paragraphs, taxonomies, we're working on having views and other things. But again, this is there. But unfortunately, it exposed probably way too much data. Right? And you don't want to do that, you know? And even if you don't have to query that, that you can save obviously all those, I mean, all those like back and forth from your server, but it's still exposing that data. So there are things that you can do, like put your API behind a simple URL, which is heavily recommended. You don't have to have your API totally clear of a little bit. You don't want to. But again, it also exposed way too much data. And then in convention, it's kind of clunky and Drupal. So we are working on a graphical interface for this. And that graphical interface, think about us. Again, we're using inspiration, JSON API extras. You know, you can go to a content type, you know, click, click, click thing, you know, enable, disable fields, rename fields. Out of the box, it just named things like node, article, node something, or paragraph something else. We decided to go that route to avoid naming collision, but it will be up to you. You will be able to go through one page and said, you know, I want to name this article. I want to like remove the Drupal lingo from here and just rename article. And we get rid of the field underscore, something where the fields are only named as the field name, pretty. Again, but you will be able to go there and change that. And out of the box, it detect the field type, the field type of your, you know, content type definitions and default to a particular data producer, but you will be able to go there and change that. So I mean, you will be able to bring your own data producers. You want to format data differently. You want to change how things are presented. You will be able to do that. Kind of like JSON API and handlers, handlers or handlers, I don't know what the name is, something like that. Again, you will be able to change how you expose it. Kind of think about those graphical formatters, like your, you know, like field formatters, but in this case, at the API level. And again, we'll be able, and also under development, it's the capability to support that, you know. We provide, I mean, using any other data providers. When you have the graphical interface, it's, you will be able to do that, bring your own data provider. So I might be using an external module, you know, like maybe you have your own country module that provide those data providers. You have a graphical interface and change that and that's it. And, but what, what is plan already? Again, what I mentioned, currently, it just introspect all the Drupal data, expose that, get a yada yada, and what is plan support for views, because your views is a really heavily module and allow you to query it, you know, using this drag and drop clicking thing. So we want to provide support for that. We want support for custom field by using those custom plugins for data providers. And then finally, support for write actions are also known as mutations. Currently, it's only queries are supported. So you only can create data and fetch data from Drupal, but you will be able to have mutations. It means you will be able to write back to Drupal. So it means allow you to write your own system application, not only, because most of the ways we use, or people use like Drupal as a CMS, all the new data manipulation happens at the Drupal, you know, entry form, and then expose the data and use like, either Nex or Gaffee or whatever to pull data and show those pages. But what if you want to really build like fully decoupled application, not only a side that shows data, then that's why mutations will be there so you will be able to use those to push back data to Drupal. How to use that? Well, Composer, Required, Drupal GraphQL Compose, Establishing Beta, you need to make sure, even if you cannot see on screen, you need to change the minimum stability to that on your Composer JSON file because the module is on Beta. But you know, it's Ripple Beta, it's kind of like, you know, there, and there it's kind of like prod on Drupal there. We all know that it's only worth, I think it worked with Drupal 9 and up because I think 8 is already in a fly for something, but because of the dependencies we have in the project, I think we're forcing to have 9 on that. And if you are on Drupal 8, you need to make sure you move to migrate to Drupal 9. It's not a nightmare anymore, you know, like moving from 6 to 7. You know, it's like, whenever you need to move to 6 to 7, by the time you finish moving migrating to 7, now 8 was out and you need to migrate to 8, you know, remember that, last time you just see 5 to 6, 6 to 7, it was kind of like a little complicated. But now, fortunately from 8 to 9 and 9 to 10, it shouldn't be that hard. It's more like code deprecations, things like you shouldn't be doing, like not injecting, you know, dependencies on your code, like using this static, you know, Drupal something, something, yeah, okay. Obviously, ideally you shouldn't be doing that, but if you are still doing that, well, a lot of that code should be deprecated the way some services are named on the, you know, on the Drupal or are changing, but yeah, shouldn't be that a big of a problem. So yeah, Drupal 9. And let's see this video, this is how it looks like. So I'm gonna play the video. So basically this is Graphic URL. So this is the code where you can start typing queries on the slaughter side of things. You can see all of the queries and types already listed on the system. So I can go to this, yeah, the GraphQL query thing, and start typing like no articles, you know, first 10 typing ID, title, and then if you run, and the result is right here, like right away. Again, I have to do nothing other than start typing and other completion is here. But then, you know, this can start getting complicated. In this case, I go, I, you know, type author and then give, get the name from the nested property without doing nothing other than type author, curly bracket, and then start typing the properties within that nested object. So again, all that, it's already out of the box from here. Like no includes or nothing. But it is kind of hard, you know, it's typing things, it's kind of hard. And then what we end up doing here, so we provide with this tap at the very bottom, you know, where the exploder and server are on the GraphQL screen, where it's called fragments. If you go there, and it's gonna happen in a few minutes, in a few seconds, it's gonna happen. Well, again, what is showing here are the documentation is telling you which sites are in a node, which fields, which sites are there. Again, remember what I told you about, like sales documented API, so everything is there. I get out of the box, you have to do nothing other than enabling the module. But again, might be typing things a little harder. So what's gonna happen next, yes. Instead of typing every single property, because might be you are lazy, or might be you want to have a better developer experience, what's gonna happen, the module provide you with a tab that is called fragments. And basically fragments are like snippets of code, which is basically snippets of your type definitions of the type on your system that you can go, copy, paste it, instead of again typing again, like node articles, or node pages, and know what's typing. It's node pages, so it's pulling all of the pages on the system, node articles, first, whatever, I think first 10 or something, I cannot see the screen. I'm close, and I cannot see it. So this is not a great developer experience. This is not a great conference experience. But if you don't want to type all those things by hand, again, you can go fragments. Yeah, fragments, and in this page, every single type definition is registered, every single type definition on the system. So you can go here, copy, so every single type definition, paragraph definition, like node definition, taxonomy, whatever user, whatever like media, lane, all of the types on the system, so you go here, copy, paste it back on the GraphQL, just load it in the GraphQL Playground, and use that, you know, you're gonna paste it at the very top of the screen, you're gonna scroll down, get a Yana, and then instead of typing field by field, I will use the dot, dot, dot fragment name notation, and boom, all the data is gonna come, and all the data that is already on the system, so I didn't have to do anything other than using the fragments already generated by the module, and it's all here, and all the data, all the nested properties, again, you can remove from those fragments what you don't need it, what you don't want it, or you can create like user something fragment, instead of having a single user with all the fields, you can have like user, you know, like view modes, you know, like node teaser, like node pool, or node whatever, yeah? So you can think about that, like so again, we're trying to get the same ideas and inspiration, like teaser, you can create that, and again, this is like a little explanation on how those fragments are set, you can see there is like language fragment, or language field, which is pointing to a language fragment, so instead of having all the field definition here, you have it on the fragment, and you can reuse that code, or the play, you can create fragments, or reuse all of your application, and you can have author, you can have all these, you know, like paragraphs, in the case of paragraphs, you have a field that is called components that contain all those paragraphs, that field definition is created as a graph field union, it means to be, can expose data from different types, it's not like it's only this type, it will be like, you know, hero, CTA, hero tags, image, whatever, or like code snippet, whatever. I will have a train tomorrow, got me in GraphQL, but you can see how this works. Hopefully, we have a more darker room, and well, a little more example of how this works, like, you know, language property is pointing to that language, which is meaning it's calling a fragment, and the fragment definition is defined here, so, okay, fragment contains the type definition, and as I mentioned, you can have different fragment types as view modes that you can reuse across your system, and decide what you want to expose. Another benefit of GraphQL is data introspection that allow you to query things, you know, like, and understand what's happening and what's on the system that we're registering, but during that data, it's kinda complicated because the way it's shown on the system, it's in a way that a machine can understand that because, you know, computer code should be understandable by computers in the other than in the end, you know, we want to have something like simple, and we decided to expose a new query called GraphQL compose information that expose data, expose data from your content tab, you know, the content tab, it's called, you know, and it is known, the bundle is article or it's page, and it tells you what the type definition on the system, you know, article is of type no article. Article has this query plural that's called no article, so it means it's exposing you data from the, or meta data from the GraphQL, so you can have, you can take advantage of this data and build applications, so it means, I think query is this, and then programmatically create a query application because I already know which query do I need to use for plural, you mean for getting multiple elements. I know which query I need to use for single, like no article, it's a single one, so it means we've received a UUID, so again, I can take advantage of all this definition and use other tools, what? Now it's not refreshing, really? Yeah, so you can take advantage of that meta data and use that to create something like this code, there's something called SOP, it's a project, C-O-T, and allow you to create SOP objects, so you can use that data data, create those objects, which is basically like TypeScript objects that you can use on your application, so you can take advantage of that meta data, this is a article which contains these fields, those fields are of this particular type, so you can basically iterate that data and create your objects on the fly in your system, and you can save you for a lot of time of writing and typing all that, and similar to what I was mentioning about the GraphQL, you know, code generator, but in this case, you can define the shape of the objects, which, how do you want to generate those, and benefit of using something like SOP is you can interact with other tooling, you know, like React to forms or remix form, we do a lot of remix work lately, so you can do that, you can use remix forms and use pass this object that you just created, and you will be able to render, you will be able to render those forms and fields, when we have the mutations ready, you will be able to have those mutations as actions, actions on your forms and post data back to Drupal, so you know, it feels like we are revealing form in PI and JavaScript, but at some points, I have seen a lot of projects going into the GraphQL route, trying to do the same thing, because people is like not really happy with some editorial experiences in Drupal, so again, some customers are asking for that, so we're trying to figure out the details of the other way. And finally, you can also download the GraphQL fragments, you know, the one that I show you on the screen, so you don't have to go to that screen and copy paste it, you can run this query, copy from it, or just implement something on your CLI that execute this query and pull that data and just put it in your system so you don't have to write things, you know, sometimes it's easier to automate something, it's spending like a day, automating something that takes like five minutes to do. And well, the module, it's called Drupal GraphQL Compose, a stable release, hopefully it's gonna happen on Q1, 2000 in the next year. We were trying to accomplish something like by the end of this year, unfortunately, life, you know, happened, and there's, I mean, we have some other projects in Word to do, so we are unable to allocate enough resources. If you are interested to contribute to the project, think me, let me know. Again, it's not refreshing. Okay, so, and once we build the GraphQL module, we decided, why don't we just try this ourselves? So we decided to work, and we go out of Gatsby work, and all of the Gatsby projects are working with JSON API, you know, the GraphQL source, Drupal, Gatsby source, Drupal, Gatsby source, Drupal, plugin from Gatsby, it uses JSON API, so we decided, why don't we just create a new source plugin? So we decided to create this Gatsby source Drupal GraphQL plugin that pulls data from Drupal of data and media, images, all that. You know exactly what JSON API do? And pull data from Drupal alongside, use the GraphQL Compose module, and it also supports like incremental changes in your code base, and this plugin allowed you to build Gatsby sites in top of Drupal, using GraphQL, obviously NPM install, Gatsby source, Drupal GraphQL, Gatsby source, Drupal GraphQL plugin, and unfortunately you cannot see here, but this is the plugin configuration, and currently the module supports simple or out authentication, so you don't have to like, expose your API openly, publicly, so you can put that behind an authentication used by enabling the simple or out module. If you do that, you have your credentials, you have your credentials as EMB variables on your build system, and that will be logging into your system, getting a token back, it will use that token for upcoming all the every single request during the build process. It also supports token authentication, so you can generate that token yourself and just pass it instead of doing that, but again the problem with that is you end up generating a token with no expiration date, and that's not totally secure, you should be doing that probably, and obviously the token that you generate is based on a user, password, it means you need to be careful about which access, about which role that user have access to, so again, basically just create a new role, something like Editor, Role, Enable, whatever have access to and access to the executing GraphQL queries, and they use those credentials, that's the simple way to do that, and have another video, let's see if you can see that, so again, this is a Gatsby site, as you can see, I will wanna see how the incremental changes works, like the Drupal site has the build hooks module installed, so it means I'm gonna go to my Drupal site, change something on a paragraph, this is a Drupal site, that's a Drupal site, changing things, noteporn editing something, changing something on different fields from different paragraphs, then it's gonna hit save, nothing happens because it's not rebuilding on every site, and on every saving, it's not configured like that, at this very moment I'm gonna see I can go to the build hooks page and then trigger the build by clicking the action at the very bottom, and it's gonna happen, it's showing me which changes, what changes are in the system, it's on the right side of the Gatsby site, so once I click the build, this is picking back Gatsby and you will see any change, so Gatsby can see those changes immediately, so again, you don't have to reveal your site or having your site fetching all the data over again because you have those incremental changes enabled, again, in order to do that, you need to have the build hooks module on Drupal and then just enable incremental changes through option on your Gatsby plugin, only know how the module was built, remember what I mentioned about this query that we exposed content types and fields and all that type of definition, well, we take advantage of that on these Gatsby plugins, basically the plugin needs to use a few lines of code because it's taking advantage of all the metadata coming from the Drupal site, so it is basically like iteration of those types definition and that creates the proper Gatsby code to register those types in Gatsby and all that, like again, out of the box, again, we're really taking advantage of that developer experience that we are providing by using the GraphQL module. Mm-hmm, same thing for the plugin idea to have this plugin somehow stable by early next year and remember I've been thinking, talking about, you know, how we really focus on developer experience, something, another topic that we really care, it's editorial experiences because on Drupal that's kind of hard and then we're working on a module that is called Drupal Composable, it's also taking advantage of this GraphQL thing and yada, yada, yada, but a lot of you have this drag and drop react components on the node that it paste, right? So basically you can take advantage of your react components and embed those on the node edit page so you can see them immediately while you are editing a node, mm-hmm. It means you can reuse your react component, you can reuse your mapping from your data to react components as well and this looks something like this. This very moment is using GraphQL Compos, paragraph, it supports paragraph or custom block types. It also supports, it's really providing with a graphical interface to do that. It's taking advantage of layout paragraphs, I don't know if you are familiar with the module. We are somehow taking advantage of the module but we don't use that for layout purposes, we don't use that for stacking components like full components, one, and stacking each other. We don't really want to use paragraphs to define layout, we really want to use paragraphs for define data and structure and that paragraph itself contains all the definitions they need to in that full stackable component, kind of like building blocks, you know, like Lego blocks, you can do that. We're also thinking about might be we can fully decouple and get rid of layout paragraph and use a full react application on node edit and that's why we're working with mutations on the GraphQL side of things and that looks like this. So basically you have go to a Drupal site, edit node and you can see this, this is rendering react components so we're not using tweak here. So you edit content and what you have it's this little, you know, like drag and drop component so you can go and drop things all over the place, you know, like get this one, move up or move down and you can edit those. Once you edit those, the off canvas screen show up on the right side of the screen here and you can start adding and typing, changing the content on that particular paragraph and what you hit save, it's going to refresh the react component that you have on the left. Again, it providing you with this, you know, live interaction and immediate, like, you can see immediately, you see, you change the image on the form and it gets immediately refresh on your react component. So again, you can get a full benefit of this, you can really take advantage of reusing your react components inside your Drupal node edit page. And that module, some point again, next year, I don't think Q1 is realistic at this point. Q2, Q3 is something like that. It will depend, it will depends. And well, we're all, again, refreshing again, yeah. As I mentioned, we do a lot of remix work. We do a lot of remix work for building like batch wars and apps and, you know, systems. So we really want to take advantage of Drupal to expose the GraphQL thing and having mutations and then using remix for building apps to dop of Drupal and we're working on a remixing, I mean, again, remix integration. You know, initial release will be Q1. Won't be stable at all. It's stable with like Q3, Q1 next year. We hope so. But again, you will be able to really take full advantage of remixing a node JavaScript framework that allows you to do like server side rendering, really take full advantage of react, but none of the way that we are used to with react, like everything is client-signed and this is like full like server side thing, you know, like fully posting things to your server and processing things server side. So at that server side, they have some like, action and this is where you use GraphQL to create data, provide that to your, you know, as a response and then build your pages. Again, you can build fully like HTML pages. You don't have to, you can even, you can minimize the usage of JavaScript because almost all of the rendering happens server side. So you just provide like HTML pages back to the browser. So you don't have, you don't end up with this like a single, you know, like huge like bundle, JavaScript bundles. That's it. And just finally, how to integrate GraphQL with our services? One big benefit of GraphQL is that it allows you to interact with different systems. So think about this. What if you can have something like a multiple GraphQL endpoints and you want to have a single entry point, like single GraphQL API call for your different GraphQL API systems? Well, this is something called GraphQL API. I don't know if you are here about this or GraphQL Gateway API. This allows you to have like multiple GraphQL endpoints meshing them into a single GraphQL and exposing them. There's something called a call federation that allow you to do that, but you are attached to do every single of your endpoints as a federated endpoint. So enable federation on them so you can federate them. It means if you try to get an external API that is not federated, then you are in trouble because you cannot mesh using federation on a non-federated API. So again, you can build that yourself. Yep, definitely you can do that. It's kind of hard and it's kind of complicated because now you need to take care of authentication, authorization, caching and purging that. Should be a, there's a better way. Yes, there are better. We are working on a product. It's called GraphiBase, which is basically will allow you to do that. Will allow you to query different GraphQL endpoints, but not only that, you also will be able to query data from AirTable, Google Spreadsheets, any MySQL, Hotspot, MongoDB, whatever, any other GraphQL endpoint or REST endpoint. Think about this. You can build an application that is using your own dashboard for your data from your employees. Think about this. Then you have some like form submissions on AirTable or from your customers and you have form submissions on AirTable and whenever someone reports out via those AirTable form submissions, you create a GARID ticket and you know all the data get into islands. So you can use a tool like this one, this GraphQL API gateway, to match all the data together and provide a single API endpoint to query all the data and you're having all the data. You will be able to like create your own custom queries there, but long story short, it allows you to match data from all different sources, like AirTable, spreadsheet or any GraphQL API endpoint and provide you with out of the box, purging and caching using your UIDs. You'll be caching at the CDN level. It will provide integration with Outsero. So you don't have to worry about user management. You just delegate to a tool that it's great for doing that. And again, you will be able to have access control. You can work with great users and then this user has access to this query on this AirTable to either read or write on AirTable or read or write from this GraphQL. You will be able to go to that ACL control and turn off mutations. You don't want people to have access to mutate data on your external systems. Or maybe your external system doesn't allow do that. So again, if you want to allow read from that particular system, you will be able to go there. Since everything, we can introspect all that. We can expose you to all that for you on the GraphQL base dashboard. You will be able to go to enable this query to this user or to this particular user role. And again, we can do this because again, GraphQL is great to expose in data. It's easy to introspect, provide you with a great developer experience. You can build products on top of that. And that's about it. We have a landing page. There's a form you can register. The idea is having an alpha for the Jamstack conference next month. We will see how far we can get on that. So if you're not aware, Jamstack conference happening in San Francisco in a month. There's a lot of like, Jamstack, the Jamstack world is changing a lot. Jamstack used to think about like, JavaScript, APIs, markup, whatever, whatever, whatever. And now they're going back to server side rendering because you know, life go full cycle, perhaps, you know. Like we haven't seen that. And I was like, going back to server side rendering. But again, it's server side rendering with taking advantage of APIs, like GraphQL endpoints or you know, GraphQL gateways. Okay, it go full circle, but we'll learn some things in the process by going full JavaScript and decoupling things. So now that we get back to the original point, we are better because we'll learn. And then we're going back to server side already taking advantage of this new GraphQL APIs and yadda yadda yadda. I mean, I really take advantage of this decouple but now in server side rendering, which is, it's pretty cool. And that's it. Questions, we have climates. You were able to see those lights on there. Ambedious, I mean on your computer? Yeah, yeah. You know what, and again, if you wanna know more about Drupal and GraphQL, we're doing a training tomorrow to graph GraphQL training something. Yeah, tomorrow. Now again, we'll be looking at it. Probably, you know, because, how are yous enough to buy this? But yeah, that's it. And I don't know if you have any question. Yeah, go ahead. So for the first iteration, do you have rights to? Permit? Communications. On the... You're all right back. That GraphQL composed module is already released. It's always based beta. It doesn't provide mutations, but those will be ready by the end of the year, the latest, but it's probably coming sooner than that. Because we really want to take advantage of building apps, not only like pulling data and building sites, we also want to expose mutations to be able to write applications like mobile applications or any other web applications. But the mutations are really, really close too. GraphQL interface is also really close. Unfortunately, you know, a big benefit of Drupal is that it's built on Drupal and Form API, but in the same way, a big problem of Drupal is built on Drupal and Form API. And you know, formatting that and making it look nice and build things. Like user friendly is hard. So that's why traveling with the GraphQL interface, we really want to make it easier. We don't want to like just have a huge problem with gasoline in the field. We're trying to figure out a better way to do that. It's hard because it's Drupal, but it's easy to build, hard to like make it nicer. Again, I mean, let me know. If you grew up thinking during the event, if you have any questions or comments or if you want to try the module, let me know and I can probably help you on that. So thank you.