 this URL when everyone apparently 250 but I can wait hi everyone so let's start with this presentation today we'll talk about push versus pull and we will discuss about a new module that we created it's called GraphQL in twig my name is Sasha Nikolich and I work as a software developer for amazing labs in Zurich Switzerland and I come from Slovenia which is not Slovakia but it's in Europe and you can find me on Drupal.org and on Twitter or on my email address so the agenda for today is first we discuss about the current push status in Drupal 8 how the data flow works then we'll define a problem that we as front-enders usually face then we'll talk about really quickly about decoupling Drupal about GraphQL the basic core module and then about GraphQL in twig we will show two examples one will be a gallery with simple images and one would be a simple block and at the end we'll talk a bit about the benefits and the things that we need to keep in mind while using this module so let me start by telling you a story that happened a couple of weeks ago I was at the dinner with a friend and he was asking me questions that he wants to get involved in the web development and he wants to build websites and he's trying different stuff he wants to either use Drupal or Joomla or WordPress and then he started asking me how is Drupal how is how is site building works how what is Drupal core what are modules and then we started getting into details and he was like oh but what are views what are blocks it's so different it's so difficult to grasp for beginners and then we went into even more details we started looking at our templates and we just saw these variables and we just like thought okay we see the variables like for example there's a content variable it's really hard to debug because if you just do dump content you just your site explodes and you face a white screen and the Drupal basically serves just to push data through the preprocessing and processing through the template layer and it's like a black box for us front-enders so and then we went in even into further details like how to actually build an image gallery where we just need thumbnails we need a big image and we need some description for the images so the creation steps would be as follows first we need to choose some modules that we want to use then some libraries or JavaScript libraries for example we chose sleek and some library for the pop-ups then we need to define some image styles for the thumbnail and for the big images we need to create views if you want to sort or filter our data we need to place the view into a block and either reference the view inside our node and all this kind of stuff and at the end we need to add classes to our view and style the view so it's complicated it's like seven eight steps just to create basic image gallery what is also really important that is that if we are using this kind of jQuery or JavaScript libraries we have a predefined HTML structure so in this example we are using the sleek library and here we can see that we are just we just need three kinds of data we need the URL for the big images we need the alt attribute and we need the URL for the thumbnails and that's it so we just need three data and if we want to get this data from the normal Drupal rendered array it's really difficult and we get all these extra div wrappers we get a lot of extra classes that we don't need and it's really hard to style so we got an idea like why don't why do we always need to push the data from Drupal to our templates why don't we just pull the data that we need so we just need URLs and alt attributes and that would be really easy to use so here is where the couple Drupal comes into play as we mostly most of us know that a couple Drupal works as follows so we have the Drupal as a content service in the back end and we expose our content either through REST API JSON API or GraphQL and then we just fetch the data that is provided through these APIs and the front end is totally up to us so we have this separation of concerns between back enders and front enders and and yeah we experimented with this at Amazelabs and we really love it like so we just jumped right on it and we are riding the wave yeah this is our scrum team but this is not always suitable so for example for some kind of projects we need to ask ourselves a lot of questions when we define what kind of results do we do we need or do we want to achieve do we need one or multiple experiences it is a Drupal just serving as a site or repository can we expose data through this for this site or what are the editorial needs what is the security what kind of performance do we want to achieve but at the end everything comes down to the budget you can read more about it in the Drupal in the Dries blog post in the link below so away in between the standard Drupal rendering and figuring out the data and the fully decoupled Drupal is the progressively decoupled Drupal which is a really cool balanced approach between fully decoupled full stack thingy and the Drupal approach where we can use any JavaScript framework in the front end and where we just serve the data that we need from the Drupal and we populate it all together so and this offers us good compromises either for editorial needs or for front-enders back-enders and it's a really cool experience for everyone I guess and this is also where GraphQL in tweak comes into play so the GraphQL if for you for those who don't know yet it's just a query language for APIs in a runtime for fulfilling these queries with your existing data this is the official statement that you can find on the GraphQL website and there is also already a stable version for Drupal so you can experiment with it and please provide any feedback for that what GraphQL brings is a really good and understandable data structure and description we can expose any data that we want and this will build our schema that we can easily fetch to our GraphQL queries what is really good is compared to the other APIs there is no over and under fetching so we don't have we don't get any extra data or any less data that we need so we specify what we want to what kind of data we want to get and we just fetch that data without any extra extra data or wrappers or anything it offers really powerful development tools like the GraphQL Explorer it has suggestions it has the documentation it has the help on the right side so it's really cool so let's go back to the gallery example as we said before why do we push data to this predefined HTML structure we just need to pull what we need and let's just jump right into it so the first step that we need to do when we are building the image gallery in this example is to include the GraphQL query at the top this is still a bit weird because it looks like a comment but it actually works so we need to wrap it in the hashes around and then here we are using fractal as the atomic design approach and we are calling at the bottom the gallery component and we are passing the whole data that we get from the GraphQL query directly down there and the three dots gallery this means that we are calling a fragment that is defined inside the gallery component so the next light shows the whole GraphQL query so we can see at the top we are calling the gallery fragment on the node itself the node ID is 54 as we see on the left bottom and then inside our gallery fragment we are querying the media image that we defined previously in our side building part so the media image has two image styles the thumbnails and the big images and we just fetch the URL and on these images we also fetch the alt attribute we get all the data back and it is really easy to put this data into our component so here we see we have two sections one is for the gallery for the big images and the second one is for the thumbnails so we are looping over all the items that we get through our GraphQL query and then we are setting the data as needed we are also calling a figure component here and we are passing down the caption and the image URL and this is our final product actually this is the gallery that we are that we saw in the previous slides so let's look at another block example so like the Drupal usually comes with a predefined block that is called powered by Drupal and we can actually overwrite this template and just output some other stuff in there so for example let's output the user name and put it in there this is really easy so we are querying the user by ID ID1 for example that would be an administrator and we can also query the current user and put that into our template this is really easy and we are actually overwriting the whole functionality of this block by just writing a GraphQL query at the top what are the benefits are you asking so there are quite a few actually the first one and the main reason that we are using it is the separation of concerns so the back enders and the front enders can work completely separately so the front enders can do can implement the design and the front end components and if the GraphQL schema is predefined we already know that we can mock that data beforehand and then just implement the front end part separately without any sidebuilding basically rapid product iterations that's also connected to the sidebuilding part so as we could as we could see with the gallery example we just totally skip the reviews configuration and the blocks and all these parts in between so we just got two part two or three steps actually and this provides us a really faster iterations and the customer can give us feedback much quicker yes we can get exactly what we need so no more extra wrappers we can get exactly the URL directly from the GraphQL query for example with a JSON API or REST API we would also get other data that is not needed for us for example the image width image height and things like that so this is a really good benefit it's a really strongly typed system so it provides us with the data like if it's if we are querying a string if we are getting an integer a boolean so we got we exactly know what we are getting and what we are querying for in the example before we could actually implement the gallery that extends that is a part of a superior part so for example we would have Flickr gallery or Instagram gallery or media gallery that also implements videos so this would be a part of a bigger interface actually we can have fully full control of our template structure so again in the gallery we saw that we had a predefined HTML structure and we can just put data in there yes for the front enders it's really easy to reason about the data flow so we are just querying what we need and we are getting that no more pre-processing and processing that's really cool the tooling is really good the GraphQL Explorer is really useful so we encourage to use that even if you don't know much about the HTML the Drupal website structure how the fields work how the media is nested in between inside and things like that you can easily figure that out through the suggestions in the GraphQL Explorer and last but not least it's well suited for atomic design so we are using it in conjunction with either Fractal or some other atomic design patterns either with React or not there are a couple of things that we need to keep in mind so the configuration logic moves to templates that means that all the sorting and filtering can be done inside our templates so this can be either a plus or a minus it depends if you want to click around or if you're familiar with the Drupal configurations and if you are more of a clicky guy or geeky guy if you want to write your logic inside your templates or not it's not fully covered yet so for for example for config entities this is not yet supported but we will find a way to do it we also saw that the syntax highlighting for example in VS code or in PHP storm is not does not yet work so it might be confusing at first if you see just a piece of GraphQL query at the top that is commented out so you would think it doesn't work but this works currently and this is how it is and yeah we would suggest that we don't mix that much the current Drupal workflow with the GraphQL and we would just use it when needed so when we have some static data or where we have some predefined structure that we just need to put some data in there so we are currently using it for the header for the footer for the image gallery for example for the menu which is which where the data usually doesn't change that much or the HTML structure so all the credits for this module and the GraphQL in general goes to Philip Mellop and Sebastian Simpson they are two of the main contributors and I would really like to thank them and if you have any questions I would be really happy to follow up on them. Please use the microphone. Using this approach have you had to create some kind of an isomorphic app maybe using React and if you haven't is it even possible to do that? I'm not sure I understand the question but this approach is not fully decoupled so we can basically just provide the data to our GraphQL to our tweak templates and then style it with normal CSS. What I'm asking is if you have the ability to you know use something like React right on the front end and you need to create isomorphically meaning that the React components render on the server side and on the client side right they hydrate to the client side is it something that can be accommodated with these approach? Not sure how to answer that. Hi thank you for presentation so one of the reasons I'm thinking out loud one of the reasons why we use Twig is to get rid of data manipulational code or queries from the template files. So just to make the template files clean so we don't ever go to the database and grab data because it's a template file and we should use it as a template file and what you're suggesting is really tempting for me as a front-end developer but isn't that exactly what we are doing? You're actually going to the database and doing a query in the Twig file and I would like to try it out in a dark room when nobody sees me but I wonder what kind of performance issues could this cause and did you ever find anything that would tell you not to do this because I would I would really really like to try it out? It currently works for us pretty well we had some caching issues at the beginning but we are just using the normal Drupal rendered array through the processing so that is actually fixed now. I didn't experience any any big bigger fallbacks or any bigger issues actually. It works straight out of the box. We just we just had some issues or we just needed to extend the functionality with responsive image styles. We wrote some custom code for that and we are actually testing it in one of our projects. There were a couple of missing things that we need to we needed to play around with. So the GraphQL language does that reach back to the database and get the data? No it actually queries the the schema. Okay then okay then I misunderstood what GraphQL did and I will try it out. Thank you very much. Yeah kind of a related question. You mentioned that in many cases you're not using I think you said you're not using views but you're directly doing the query. Is that the case for basically every kind of view you might have used otherwise or are you still using views for specific types of queries and this is a replacement for certain types of views? Yes we are we're using this just for simple views where we don't need much filtering or sorting or this kind of stuff. It works pretty pretty good and it's quite basic. Are you also using this with like these that have contextual filters? We are using contextual filters in this kind of stuff still with views. I just wanted to follow up on the question about the isomorphic JavaScript or being fully decoupled. This is something we have solved in other projects where we decided to fully decouple and we have on our GitHub we have some sample projects that help to to build an isomorphic React based application with the GraphQL module but in this case so we we really wanted to not do the heavy lifting which is a trade-off so we don't have the benefits of an isomorphic JavaScript app but we have still the benefits of leveraging React within or just like simplifying the template so there's there's a lot of different use cases where we see that GraphQL and React can be of benefit and this is yeah this is like a smaller approach to it. Thanks for the presentation. So one quick question is is it easy to apply this to the existing templates like if we are pulling in some variables from the pre-processing hooks and all is it just easy to replace those with the GraphQL and or are there any steps that we have to take? Yes it should work basically out of box you just need to install the GraphQL tweak module and write your GraphQL queries and play around with it. Is there an easy way to debug it where you can see what's inside of the basic query or sub-queries? Yes we implemented a custom feature for that so when we are in a node we have a overlay that says GraphQL query which basically if you click it it brings you to the GraphQL Explorer and then you get the data passed into it and you see exactly the GraphQL query that you are writing down and then you can debug that inside the GraphQL Explorer. Thanks. Have you tried to actually use this to fully decouple in the sense that you have one Drupal system that has the content repository and you have another Drupal system with doing rendering from GraphQL that's calling back to the repository site that would be an interesting use case. Yeah I didn't try that yet. It would be interesting if you do let us know on the issue. So you mentioned