 Good morning Yeah, that works. So who is excited about the future who wants to learn something good. That's what we're here for So this session is about graphical react redux Apollo and our beloved Rupal. So To shortly introduce us. My name is Michael or people call me schnitzel. I'm the CTO of Amity labs and with me We have Brandon One of our developers from Amity labs Austin Amity labs does a lot of different things one of them is Drupal and recently We also do quite some react, but Actually, if we look a bit at the past Between 2013 when the whole idea of decoupled came up. We were actually a big big opponent of it Why there were a lot of different reasons and our lead developer in Zurich Sebastian or also called fooby. He actually wrote a blog post which you can see Let's fix that. Can you see it now? No? Yes. Okay, so he wrote a blog post about headless Drupal. The cake is a lie and So how he comes we never really implemented any decoupled sites because we saw a lot of issues if you want to read his blog post search for and headless Drupal the cake is lie. Basically, it's about accessibility Performance overheads that decoupled websites create so in October 2016 We had a client in the maze lap Zurich team that asked us We would like to build 12 Websites that look completely different from the front end But they want to use all the same back end Plus they're gonna be most probably 12 different teams that implement the different front ends But again, they still want to use the same Drupal back end So initially you think about okay Well, hmm, and then you maybe go into a phase of like what like why and like what the hell how could we even do that and Yeah, then we started thinking like it has to be possible, but we really thought like we don't just want to create 12 different themes for the same Drupal site because if you looked at the sites They were so vastly different and some of them worked completely different so We had an idea we had an idea to actually go back to the thing that we didn't like the decoupled Let's look at that again. Let's look what happened over the last three years and We did that and this morning Really this morning. I got up at 6 o'clock in the morning. We launched our first Fully decoupled react website with GraphQL Apollo and Redux that talks to a Drupal 8 and back end So what does it do? So we have a Drupal on the back end We have a react Apollo and Redux front end What all of them do we will go a bit deeper into and in between we have a GraphQL API That allows the front end react Apollo Redux talk to the back end in Drupal 8 So how do we feel today? Actually pretty happy It is right now for us the most exciting thing that's happening because we feel it is finally possible To do decoupled websites in a good way and I gonna show you together with Brandon today How we do that? What are the different components? How do they work? And yes, they're going to be quite some demos involved and we really hope that the demo God is Nice to us today that it works So the presentation is going to be about GraphQL What is it? GraphQL in Drupal Then we're going to talk about react as a front end and then we want to see all together working and We're going to do that But let's first go into GraphQL. What is GraphQL? So GraphQL has been introduced by Facebook and they are actually using it in all your mobile apps They're running with GraphQL since 2012 and they publicly Published the schema the idea that the specification behind it in 2015 and since then it has been Very vastly used by a lot of different people So let's look at that Who of you has seen the Star Wars API? Okay, so if you look at the Star Wars API You have an endpoint like here We have people one and we get back we get Luke Skywalker and we get whatever and the colors and we get the films But then we realize hmm like it now if I want to see the films I have to do another request and maybe in there There are all the directors and I want to have the birth date of the directors So let's say I want to show something which shows all the people plus their films with regular rest what that is We will end up in running a lot of different requests or I could go to the person that actually implemented me That back or that API endpoint and ask him Can you instead of like showing the URL or the the next endpoint? Can you just please and inject also the director's name? But then maybe Brandon wants to do something different and so you end up in a lot of different APIs So GraphQL fixes that GraphQL comes per default with a really nice UI that is called GraphQL and Idea is not only that you can write your queries in there You can actually learn how your API works There is no documentation that you have to read in order to understand how to query it So how does it work on the left side? I'm writing my query on the right side I have the output and You're gonna be a big fan of control space and comment space because if I press control space it shows me all The different fields I can request so I can say well, I want to have a person and I want to define the person so I just open and bracket and say okay person ID is one and I press comment enter and it gives me already an ID back while that ID is maybe not the cool stuff So I'm saying hmm. What can I get of that person? So it now shows me all the fields inside that person and I can say name and I press enter and I have school looks guy walker Not very fancy so far Everything we can do via REST API But now let's look at that So in there, I'm not only having fields, but I'm also having relationships to other objects there is a film connection relationship so I Can add film collect and add and now it auto completes me like you have to add some etches and some notes But GraphiQL does it automatically and I can see now if I control space here Now it shows me everything that is possible out of films and I can show the title or I can say show me the director and Now in here on the right side I have the person looks guy walker with their films when they the title and the director So the idea behind GraphiQL is that you're not just consuming API endpoints You are actually telling the API what you want and How it should be outputted if for example my My app and Expects the director to be let's say Something else I can just add Another name for that and now I'm getting back blah instead of the director So I can define to the endpoint what I really want and the best is it I can do multiple queries At the same time So right now I'm requesting the person and I'm crashing the films in there But I can just go down here and I can do another one and I can say By the way, and I would like to have all species as well So and of these species, please show me the language they're talking So on top I still have my request But at the bottom at the same time with one single API request I'm also getting all the species with all their languages So basically the idea is you give the power To the person that actually needs the data you're just exposing an API and The person that uses it can define what they need what they use how they use it So let's go back here. So GraphQL gives you exactly what you need You can run multiple resources at once you can query multiple things at once The graph and what I showed you it actually goes much further you have fragments You can inject variables that you can reuse. There's a lot of other things and The very interesting part is any schema is possible So all the fields we requested now You the person that writes the GraphQL API can define them completely your own You can create everything what you want there The next interesting part is we can not only request stuff. We can also create stuff We can change stuff you could use we have full mutation support and They were the very interesting part of it as well There is no version of a GraphQL API Because if you're adding another field You just add it and the person that is going to use it with their API can just request it and GraphQL is Based on a very strongly typed System if we actually go here and click on the right side on the documentations we can see all the different Queries we have and if we go into a person we can see that's typed person and we have different types But we also have like the regular types, but we also have a planets type So Who can tell me a CMS that is strongly typed? Drupal Drupal 8 the entity API is fully typed You have very strong types. You know exactly what was is so GraphQL Makes a lot of sense to run inside Drupal because we already do these things We already have relationships between objects. We call them entity references. You already have object with fields We see them again in GraphQL. So We said let's combine them. Let's try it and it works so we've built or the community built we were part of it a Drupal GraphQL module that gives you full GraphQL support and Because I said I want to actually see how somebody does I told Brandon roughly 48 hours ago or 24 hours ago You should try it and he did and he will show us now what he learned over using GraphQL in the roughly last 24 hours Thank you. So I Well, yeah, he gave me we have a talk to do you need to do some things So I've been using it for less than 24 hours. These are all the mistakes. I made aka New tips for you guys if you are interested in the stuff and you want to turn around and start using GraphQL in the next Hour or so this should help you out First of all the GraphQL module for Drupal. You should use Composer to install it Both branches require External PHP libraries. So just use Composer save yourself from trouble The second thing is which version should you use? There's a 2x branch and a 3x branch If you like all of the things that are said on the projects description page Use 2x it includes all of the default schema that will let you get all of the data out of Drupal and query all that stuff But it's the old version So if you want to experiment with GraphQL with a Drupal site that has data already and kind of see What queries can I run to get the data? I want the 2x branch is the best for that However, if you want to start building this for a production site or you think this is going to go live I would suggest using the 3x branch. It's the new stuff. It's been Re-architected has a much better object oriented style much easier to extend your own schema and Coming in May it will have full Drupal schema support just like the 2x branch So if you waited just just a little bit longer, you'll have everything that 2x has but it's a much better developer experience much more maintainable So usage basics This may seem obvious at first, but you should learn GraphQL first before you start using GraphQL Drupal if you think that you're going to install GraphQL and That gives you everything you need to know to start writing queries. That's not exactly correct, but the Syntax is simple. The concepts are simple. Just go to the graphql.org Slash learn you'll get all the basic concepts and that will give you all the necessary information you need to then Start using the GraphQL UI which Michael showed you in the demo the good news is this comes with both versions of the GraphQL module So if you install GraphQL module in Drupal, you will get the graphical user interface and with your basic understanding of queries You can use the autocomplete That the GraphQL module gives you to start autocompleting all of your Drupal stuff And that is a much better way to learn exactly how GraphQL module in Drupal works and what schema it provides So I have some examples if you use the 2x branch. This is the schema that The GraphQL module provides So one example is you can run node query type searches So on the left I'm saying give me all nodes with the title test article Return the node ID the status the rendered output and the user ID and on the right hand side It gives me all that information and that's just built in you install the module you go to GraphQL slash explore and You get your data and you can start querying that immediately for the 3x branch, it's much less out of the box friendly the Only things that are really easy to do is you can query an entity by ID and Then you can get the ID back and That's it So if you want more data than that from the 3x branch, you do have to actually write some code Fortunately like I said, it's being re-architected much better object-oriented programming style. It's actually Not that bad. There's a class for your schema There's a class for your fields and there's a class for your types You write a little bit of glue code. You extend all the base classes from GraphQL And all your autocomplete stuff starts working in the graphical and everything works well So my advice is in the 3x branch for a GraphQL module. There is a example Module it has if you also enable that you will get a lot more data out of your Drupal database by default, but it like replaces everything So you wouldn't want to use that example module in production You would just use it as an example for writing your own module. There's also a module in The deep Drupal decoupled app which Michael will demo a little bit later Called GraphQL underscore demo. It also has a lot more code to kind of tell you or give you an example Of how you should write your own stuff So for the 3x branch It's much nicer that you get this kind of base schema that the GraphQL module gives you But in your custom module you can extend the schema with anything you want So that gives you you can start writing your own custom GraphQL modules and stuff So I started writing the GraphQL back in for the Texas Camp website Which is built in React and we already had a Drupal site with Back in data in it. So this is the structure. It kind of looks like you first define the Root query field which here is sectioned by name That will return a type Which I have the section type and on the section type you define what fields are available And I said I want to return a body an image and a title so it's really just three classes a little schema glue and You've got data being returned out of your GraphQL API and So in just a couple hours After figuring out a few things which hopefully you now don't have to also I had a totally functioning GraphQL app In like 30 minutes I plugged in the Apollo stuff with react and I had react querying and getting data from Drupal And it's all up and running and I have a fully functional Drupal GraphQL and react app It's very easy Okay, you might wonder like okay. It's it looks or it sounds like not fully done Yeah things while we actually use it in production So the sites that you might be already queried is running that behind and and yes We will write a default schema for it So the idea is that when you download the GraphQL module there is a schema in there that you can enable It's going to be opinionated by us So based on like how the routes are called and things like that That's based on that if you don't like that or if you need a subset of it You can take it and you can disable parts of it But the idea is really that you can install a GraphQL module on the Drupal site and everything can be requested and I'm talking about everything. We're not only talking about config content entities We're also talking about config entities So everything that is within Drupal that is somehow accessible we will out we will be able to Do through GraphQL another thing is also we have full Drupal cache and cash tax support So everything that you load even though you go very deeply is using itself the Drupal caching in The cache interface with the cash tax. So if you if you make GraphQL requests with the Drupal module You see a huge amount of cash tax in there You can use them and stuff like that and we're also already supporting mutations So you can create entities via GraphQL. So basically you can do whatever you want directly and via GraphQL So let's now move from the back end and the GraphQL in between Let's move to the front end as I mentioned we're using react Apollo and Redux and So react is probably the thing that you already know That's the front-end library again by Facebook and that has is quite widely used right now Plus there is Apollo Apollo is a project of the GraphQL community and Apollo basically provides a very broad set of Liar tools that you can use GraphQL in almost every language. So there is a graph. There's a GraphQL for React, there's a GraphQL just for regular JavaScript, there's a GraphQL for Python for PHP things like that. So how do I communicate with a GraphQL endpoint? There's a GraphQL server implementation as well if you want to write your own GraphQL and all these things go to the Apollo and Website you will see there and we are using the GraphQL client for react that react can actually talk to the Drupal and Then for the people that already have used react Apollo uses Redux Redux is a state container which allows you to have different states of your react app So you can jump back and forward and you know exactly what happened. It makes it much easier for debugging and What exactly happens but also and for performance and things So if we go back to 2013 2016, I said Amazel apps was a big opponent of React or decoupled in general and one of the big problems that we saw was SEO and accessibility Why? Well, if you have a decoupled app and If you had one in the past all that was sent to the browser was an HTML structure with ten lines of code With maybe one JavaScript file in there that then loaded all the stuff And now please show that to a crawler that cannot run JavaScript Or show that to a screen reader that cannot show JavaScript run JavaScript So what happens is all these things cannot load it. So you had problems in SEO yet huge problem with accessibility Comes in isomorphic JavaScript So the idea behind isomorphic is your browser requests the first page and that request goes to a node.js server and that node.js server has the code That you run in the browser also running locally So the server pre-renders everything for you And inside the node.js So it makes like API requests to the Drupal and stuff like that and then it sends everything Renders the whole HTML with all the CSS like like it would not be a JavaScript app It sends it to the browser the browser displays it So that means a Crawler or something that cannot run JavaScript can display it. No problem. There's no JavaScript Then there is a tiny little piece of JavaScript in that response in that HTML and what happens the browser will execute that JavaScript and the JavaScript will slowly take over the whole site So every link gets like gets replaced by react links and things like that So it morphs into a full react app and After that every additional requests go to the API directly You're not talking to the node server anymore and the react app queries GraphQL directly and renders that Sounds complicated. It's actually not but let's look at it So we go to our website that we just launched today and it's www.meo.ch It's about food and it's German. Sorry, and but it will be translated to French and soon And but we also will have other languages. So and if I visit the website and the very first time and Actually, let me disable JavaScript because that's the best. So I'm disabling JavaScript in my browser right now And I'm refreshing the page and you can see that the whole page is loaded So everything is there that you would expect from a regular website And I can also click these things and it will load me another URL Still with JavaScript completely disabled. So what actually happens is on www.meo.ch is the node js server running and every request that goes in is Prerendered and sent back to the browser Now I enable JavaScript again and what we can actually see if we go to the network tab and Visit the site The page is loaded already and we do some additional GraphQL requests already to make sure that that is but we feel we go If I now let's say click on one of the articles and we look here in GraphQL It only makes two GraphQL requests The first one is actually a course check because we have different domains So do you not have to worry about that but the actual request happens in here? So we have a GraphQL request that tells the back end what we actually want and in the front end We have all the things the whole object everything given react gets that and will Render that and if I click now around if I go back to the star page if I go back in there You can see how fast it is and the reason is GraphQL or the react is actually caching all the requests So redux and comes into play and helps us caching all these things. So the site is Superfast after you have it done once on your and on your site And you can see they're not even any more graphical requests anymore So if I go if I'm on the side and go back to the star page There's no single graphical request because the react app already has that cash and will use it So the first request is completely non-htm and no JavaScript JavaScript will render will morph into a full react app and after that you have one if your browser does not support JavaScript it's never executed and the whole behavior is still the same so the site can be crawled It's accessibility wise. It can be read by screen readers and stuff like that So that was for us the first step that we really said, okay Now it gets interesting now we feel we can do decoupled apps because the problems of SEO and accessibility are addressed the next problem though that a lot of people said and Quite frankly correct was performance if you use a regular REST API to load stuff You will have a lot of different requests to the back end if we look at that site We have a menu with a with a flyout menu with a half a header. We have multiple Articles we have a footer down here. We have inject So usually these things are all separate end points and you would request them one by one Via REST so we could end up in having 10 this 10 to 15 different requests which takes very long as we learned though With GraphQL we can do multiple requests in a single one So react Apollo and Redux together keep an internal cache of everything that already has been loaded and Because GraphQL can do can request multiple resources in one single request Together they will figure out what do I still need and what do I not need? So let's look at that So we see here on the website We have a footer here and the footer is actually injected by Drupal So the the react has no idea what exactly is in that footer in there And we have another site that or another page that has a map. So the map allows you to like filter you can Sorry the map and you can filter for it You can you can scroll through it one of the things we will see if now my side loads The map does not have a footer. So right now. I'm visiting the whole site without never loading the footer and Because there is none like that design decides there is no footer there So if we now look at the inspector and see the network tab and we filter for GraphQL again Now I go to the star page The star page has a footer. So what happens and the star page obviously has also a lot of code about the star page itself So react will realize that the footer is missing and will also load the footer It will not though create a separate request for the footer It will request two resources at once once the star page and the footer together So I click here and you can see GraphQL loaded things and now we see in here We actually have within one GraphQL request. We have two replies one of them is the star page The other one is the footer here. So we see the footer primary menu. We see all the links in there And where do they link things like that all things given by Drupal and now let's say I'm visiting one of these articles and Now the footer is already loaded So I click on that and I can see the GraphQL response for that one does not have the footer anymore in there It's just some social feed stuff So that gives me the opportunity to really only load the things that I really need and if I need a lot of stuff I can put all of them in one single request Send them over Drupal can't generate all that stuff and send it back and you have only one single request that really happens So that was for us That's really took the decision that we said, okay We want to try it or we want to go forward We want to use it because the major two things as your next ability plus performance were fixed for us Interestingly after we started to implement and do some stuff we realized. Hey, we need to run node.js now And so you net not only like put some JavaScript files in Drupal and let Travis and let Drupal Output that you actually need a node server running and In your hosting environment. So how did we did that? Like that so the top part The top part is Drupal. It's as I said, there are multiple Drupal There are multiple frontends and there's one single Drupal site in there the Drupal itself And there is a GraphQL Drupal module in there So that's one and that's going to be the same at the bottom these orange things That's each of the sites as I mentioned they are completely separate So they are completely separate react apps that all talk by the same GraphQL API to the same Drupal and Of course, they share some libraries and we do some via npm or yarn We share libraries that we've built but at the end they're all separate So what happens is the browser at the front will make a single request to The node and as we learned before there and the node has to render that because the browser never visited the site So the browser makes a request and ends up on our docker hosting stack So the node.js is all hosted in docker and in there There is a node.js express server with the react everything running So that's the isomorphic part and what that thing will do it will actually make a GraphQL request to the Drupal So that's the pre-rendering part and after that is pre-rendered it sent back to the browser You can see in there. We have multiple CDNs and all these requests. They're all cached So and if the actual the star page is cached is also cached in a CDN So if somebody already visited that you're not even landing here You go directly to the CDN in the sense you the whole page back already cached and then the isomorphic happens and We are also caching the GraphQL requests because the GraphQL requests are very similar They have one URL and a lot of data in them. So we cached them as well There's a CDN in there as well that caches it and now the fun part comes if The browser can execute JavaScript and does isomorphic things and isomorphs itself in a full react and It actually makes now GraphQL requests directly to the Drupal the node part is completely Ignored from that point on because it's not necessary or it's runs in your browser now And but it goes still through the same CDN requests that that the that the node itself also goes through Now you might say well, that's a lot of CDN Yes, it is and and actually very interesting part is we have multiple cache layers in there So we're using cache tags to invalidate and so the Drupal here sends Cache tags back through GraphQL requests and the node itself will take these cache tags Add some more to them and send it back to the browser So the CDN that is in between will also cache them and if now like a node changes Drupal actually connects to all these CDNs and tells them hey Please remove that cache tag and remove that cache tag and at the same time all of the requests are fully Invalidated and the next person that goes in will request it The images itself they're completely bypassed by node and they're generated by Drupal They're cached as well. No big deal there and and if we now actually have multiple sites So let's say that is our Ugo Mio and we will launch 11 orders And we will just create just a front end will be replicated and so the front end can look completely different And then we actually do the same fun here as well If you have more questions about that and if you want to actually see I could talk two hours about that come and see me later And I can show you how exactly it works and But with that we have a really fast website that is completely cached and allows us to run node and Drupal in parallel And without needing to worry like I'm clearing too much things and stuff like that Okay, so now we only talked about GraphQL and we talked about react and Apollo and Redux and we talked about Drupal Wouldn't be cool to actually see everything running together So everything you need you will find on that github URL. I will tweet it later on Fubi he is the guy that actually wrote the blog post that the cake is a lie and he is one of our lead developers and he and Published that whole app and if you actually want to look at that thingy Let's go there So it is a full Drupal with GraphQL in there and it's also a full react and Redux and Apollo app. So we see here There is a back end and the front end and inside the front end We actually have in package chasen you can see that we are loading react react Apollo We are adding Redux and all these things And there is a read me that explained to you what to do you clone it you run composer install your run Yarn install or if you still want to use npm that also works And then the whole thing is actually hosted on the Maze EIO local development environment So you start the Docker containers you install the site and you enable the GraphQL module And that's here is the GraphQL demo module that Brandon before talked about that does some of the things that are currently Missing in the GraphQL. So if you want to see how that works go in there and then we run our front end So let's do that. I've already done it and so we're a bit faster here. So that is my Decobbled back end running on the Maze EIO Docker environment and and in here I created an article that is called hello Drupal con we can see it's node one and in there I've written hello in there and you can see that's a regular Drupal. There's nothing else. That's just and the whole thing and now if I Open the front end. So the front end is running inside the node.js express server And that is listening to port 3000. I started that with just yarn start So that automatically boots everything and if I now go to that URL local of 3000 node slash one So the react will actually see that the URL is a path that tells me which nodes should be loaded And if I go here, I can see it tells me hello Drupal con It gives me back. Hello. And if we actually look at the code here, we can see there's no server side rendering enabled right now So it is completely and that's the ten lines of code I talked before about and so it just sends you back the react the whole react is booted the react actually and Then queries Drupal We're using Apollo Apollo has an awesome Chrome extension that you can see the actual queries so I can click on there and I can see that It requests Drupal with a variable node slash one and here is the whole query string So this already does some fragments and it's a bit extended things and of GraphQL what is possible, but you can see that and all these requests and There is actually also a GraphQL inside of that thing so I can click here and I can see The request that happens to the GraphQL of Drupal and also the return and that is just rendered inside react Regular react components and nothing special there and if I now let's say add another Content hello react with Drupal Hello, and I publish that I go back to my notes to and I Have that as well and because it's fun and because we usually like to have node overviews There is also an overview here if I refresh that here I can see there is an article overview that renders me the article I can click on it if we want to look at that query here. We can see that it's an article overview query and It it does also GraphQL So you can take that thing download it and start it and you can play around you can learn react in it You can learn Apollo in it. You can learn Drupal in it. You can learn GraphQL in it. It's really should be here for anybody that is interested in using it to get a very fast start Well, we already did that So overall if we look back of what we have done in the last six months It was a very high initial investment and to be honest There were also multiple doubts in bit while we were on it if it was the right decision because we had to build a GraphQL module. We had to we had to learn everything about react We had to do a lot of different things But we are as a company were committed to open source everything that we've done for that So you will find things on foobies and Get up you will find and stuff on ours. We will buy Brock post about it We're gonna continue also talk about we really believe that is one possible future how in the future Drupal can work with decoupled We don't say that every Drupal side needs to be decoupled But there are some cases where it makes a lot of sense and right now It's very complicated to do that because you have to learn a lot of things That's why we have like these decoupled and starting and packages for you to start and play around with it And the developers are obviously very happy because they can now and Use decoupled front ends the client is very happy because he's not gonna pay a lot of money for just a lot of different Drupal sites He did we just have to implement the front ends and overall I feel we're very excited about the future So that's it we have more than 50 minutes time for questions. So if you have some please hit us So two questions number one is why did you choose? Apollo over relay for instance and number two is that in the with the future Be such that you can take away that no JS server and it's possible to just have not have that and just you know Okay, so we actually initially implemented it with relay the first and the first Five months after six months. We use relay and And then just Apollo basically took the whole graph kill parting storm and Right now. It's just the best tool to use graph kill almost everywhere, especially in react and There were it's just much bigger support like the The Apollo dev tools and things like that. So that we just like that much more also Apollo actually the Multiple requests in once is something that you don't have to worry about So you just make multiple end point requests inside of react and Apollo will realize that you need multiple resources Smoosh them all together in one graph kill and sends it out and comes back and it will also take them apart again So there's nothing that you have to worry about especially if you need a lot of stuff and in relay It's just not that easy. So we actually took the time to refactor the whole thing into Apollo The second question you had about the no chair stuff do I still need a no chairs and server if you want to have server side Rendering. Yes, there is probably not going to be another solution than actually running no chairs on there If you don't have a no chair server You have two possibilities either you hope you find a hosting company that does or you can also just all the JavaScript files You can bundle them or you can build them in JavaScript and host them on the Drupal Like they're at the end. They're just JavaScript the thing that we will lose then is all the isomorphic and the server side rendering So and you have to think about SEO and and accessibility again But from a technical point of view It's not necessary for any of the react stuff to run that actually if you run it on local development Most of the server side rendering is anybody disabled because you want to have all the deaf tools in your browser So about Cash in validation in the browser. So for example, what happens if your footer changes and you're still browsing the site as a user Of course you have to refresh the page, but this is different Yes, so per default because it's cached It means yeah, if somebody changes the footer and you go to just click on the star page and it goes back You're not there and well what we basically gonna do is we gonna It's not really decided yet, but the idea is to have some kind of validation check So that when you load the page or it's already there that GraphQL makes like a request back to the Drupal and asks like did anything change and if yes It will only request what exactly has changed another way would also be to actually have a web socket open and Drupal pushes it directly in there So like you could have the star page open and there's like breaking news I'm not sure if a restaurant website has breaking news But that can be this possible and then it's like it's ultimately injected without you do anything and that will definitely something We will implement for the first option. You would basically request the footer every time only Wouldn't return every time That's a possibility. Yes, and or you just actually ask Drupal back What has changed and then request again, but yeah, there was a lot of different architectural ways how we could do that. Yes I'm sorry if I missed this because I joined late, but you were speaking about graphql and the ability to Get like requests with several things at the same time within the same request So correct you are streaming back the response. Is it actually streamed? No, it's a regular gets request. Okay, so if I'm if I'm Asking for some personalized information that takes time to render it basically will be sitting there until all Objects are rendered and then send back. It's not like with big pipe. You get streaming and see you yes, correct So what will happen inside of Drupal the caching the Drupal internal caching will Will not load everything so an actual graphql request is quite fast, but it's correct If you have let's say a request or if you have a resource in there, which Drupal takes let's say three seconds to load and You could if the whole graphql request takes three seconds But we already talked about or we already looked at it and technically will be possible to say that like you just send back what you already have from Drupal and tell And do things like big pipe to just have to have an actual stream and just send additional stuff So they're already implementations out there where graphql could be used through something like big pipe or so So it's coming soon I'm not sure about the soon, but it's coming. Okay. Thank you. Good morning. I Have a bunch of questions about this house too. I guess why did you pick Drupal as the back-end? implementation for the site and What were the strengths and weaknesses of Drupal? And if you could speak at a very high level like how you're gonna implement the multilingual component So the decision for Drupal a good question, and I don't know and So one of the big things that we needed as Drupal Drupal has to play Like a content distribution hub because that is a media company and so they actually have their own and tools for writing content and stuff like that so Drupal we have a lot of different migrations inside of Drupal to Like for example, one of the site we're gonna launch next and is a type of three website And so we have to migrate that constantly and incrementally over because while we are developing and they're editing the site So so we're using the migrate framework for Drupal Very heavy and extensively and so that was one of the things that we needed that no other CMS right now has that Really strong migration stuff. We're also using Search API to index all the content and Currently in solar maybe future in elastic search that is also just in Drupal You just click it together and it's there and and then the Drupal Because we are running multiple sites. We are using the groups module to assign content to different groups That's also already there. So it was just from a Part that Drupal really brought what it brought already to the table. Yes, the were thinking is about just using symphony for example But at the end Drupal made a lot of sense because like yeah things like migrate search API. It's all already there and The second question I forgot now Multilingual well, it's Like you would expect it and so in the in the request to the GraphQL there is just a path or a Language thick prefix in there or a language code and based on that Drupal loads the multilingual stuff and whenever you call an entity Drupal does it thing with the entity API in multilingual and just returns back and Yeah, and you will see it actually in URL in the header things like that. So nothing special Yeah, thanks for sharing all of this. It's a pretty fascinating I was wondering if you could talk a bit more about the hosting component like everything was I was like, yeah Yeah, that sounds awesome And then it's like we've got CDNs everywhere like how much of that are established patterns that are you know well documented that you can just like spin up a container with all those needs or hosting environments that sort of provide those things out of the box and how much of that is stuff that you had to configure yourself like on a AWS or something like that So we are just using the regular and easy IO stuff So running like a Drupal in AWS and running Docker containers that are actually given by a Docker file So each of the frontends have their own Docker file that defines what should be built and When this is pushed into the git repository We have our web book handlers that look at different sites and they will building they are building the Docker images locally They test them and that is pushed then to an open shift So the whole infrastructure runs an open shift on AWS and the open shift will then deploy the Docker containers and stuff like that So from a developer point of view Yeah, they only have to write the git repositories and or the code Do some Docker files in their push it and then our platform as a service will take over all of that and In terms of the CDN part I've not really seen what we're doing right now anywhere else except maybe the Facebook itself and It's definitely very complex in terms of That you have like in key CDN what we're using right now We're having like each website has like four to five different URLs Because the API is different cash than the frontend and stuff like that and We have an extensive documentation that explains everybody how it works We have graphs but there is not like just a key turn solution that I could tell you like go there But at the end it's all get requests We actually had a problem in the beginning that we had post requests for GraphQL because the problem is that at one point The requests get so big that they're too big for an HTTP head or like a parameter So you have to send them by a post None of the key see none of the CDNs out there can can Cash post except with what we fastly we were possible to do that. So now we move switch to get requests So that's no problem anymore, but it's definitely an Yeah, a customized solution I would say but again, it's not necessary and It's really because we know that we're gonna build a platform that runs 12 different websites with millions of requests per day So we're we're building or we're investing in that right now. Hey, great doc. It's it's good that you're sharing this I've worked at a major league soccer and we we use Drupal react and GraphQL Yes, not all together though, right? Okay, the node and the the Drupal parts separate So my question to you is like we're investigating, you know possible decoupled approach so can you talk a little bit about how the templating layout and overall Editorial experience is affected by the decoupled approach Where where are those responsibilities held in your application? I'm guessing it's on the react node. Yes, and So you're asking about how does an editor edit content sure or like do lay out in a home page or move You know blocks around and things like that. So currently it's just a plain Drupal old school Ottoman back-end and there is no Editorial GraphQL react system yet The reason for it is that most of the content is actually not written on the Drupal side because it comes from an editorial Workflow tool and it's just pushed or migrated via Drupal and So the actual part on the Drupal side is only that there are Editors in there that build these landing pages So they take a lot of different stuff and pull them together and we're using paragraphs for it so a lot of the things are like she paragraphs that you just like reference existing notes or your reference paragraphs So we have nested paragraphs that you can create these layouts and From a usability point of view, I would not say that we're very proud of how it works right now and it's just something that we said it's the front-end first and And We might actually also implement the GraphQL or a react back-end and but right now it's just plain Drupal cool Thanks. No problem. Hey, thanks for the talk. I'm working on the project with similar architecture and I'm wondering how do you exactly proxy request from browser to Drupal How do we proxy? Yeah, I saw in the architecture diagram you you bypass node GS. Yes We use different URLs or different Domains, so and if we go here that www.go.meo is the node so everything that goes there The CDN forwards that to the node site and all the GraphQL requests Let's create one well It's cash so the GraphQL actually goes to api.go.meo.ch and That's another key scene in front of it But the upstream for that CDN is then the Drupal. So that's how we bypass the Drupal we thought about having Like a system that the CDN has like some routes and looks like at the paths and then has different upstreams It's unfortunately not possible in in some of the CDN solutions So we just said okay, let's just use different API API and points and at the end We're very happy that we did that because now I can look I can develop locally And I can just point my local react to api.go.meo.ch and I will get The same response on the production side, but I can test local stuff So and yeah, so we basically just have for all the different Environments we have different the API domain and points Thank you so much on this. Thank you for sharing all the code a couple of questions To provision all these responses the JSON. Did you have to write lots of back-end Drupal Custom modules, or you were just using the JSON API module or something like that. We're using the GraphQL module to provision all the JSON What is provision JSON? Responses the JSON responses. Yes, that's the GraphQL module that does it. Yes, and the other questions are a bunch of JavaScript modules JavaScript libraries to provision you know like this kind of architecture So what would you choose react versus Angular versus? We're using react with Apollo and Redux This one versus for example, can you speak a bit louder? I'm sorry Like react versus Angular versus You know ember those different libraries. Yes, so when would you make decision to choose one over the other? Oh The decision came just from the people that were involved in the project already had experience in react and we knew that Because we decided to use GraphQL for the Drupal part and at the time when we started the Implementation of react was the best with GraphQL together So that decision came like from there to say, okay, we want to use We want to use something that is very good Working with GraphQL and that's ended up being react and overall we just like the approach of the component-based Library of react. So that's the decision that we took there Hello. Hello. This is super cool. I'm wondering this might not have to do only with Reactor Redux, but these sites do they have stuff like commons or people that can log in? How do you handle all that? Yes? So We have two things right now that are a bit I would say complicated and so one of them is a comment functionality There's actually a whole forum for the next site. We're launching and that's completely done by GraphQL and and all implemented in In the react in the front end so unfortunately all the Drupal stuff that you're getting based on comments and all That thing we're throwing that completely away and we cannot use it That's one of the part of the high investments that we're talking about that's like everything that you usually have in the Drupal when you get into Like dynamic stuff you have to re-implement in In react, but we're using GraphQL mutations to create a comment and to display it and all that stuff and The other thing we're also doing is We want to do web forms so we want to have web forms on Drupal 8 on the back end that an editor can create their own web forms And that's why we need to expose config entities to the react So the react will have the GraphQL endpoint to the config entities of a web form look at the fields and based on the fields load they are mapped to react components and Then we'll do that and then the the submit handler of the form Then it actually goes back to GraphQL to the mutation to create a new web form submission. So That's the whole idea right now And we're working on it and it already looks like it But yeah, there is quite some things you have to do on the front end and but again We are really interested in in saying okay Like we maybe have a react component for Drupal web forms that we open source and then everybody can use it Thank you I've seen several GraphQL libraries Implementing complexity analysis on the queries so they can so no one can take your site down with a very complex GraphQL query that loads, I know 100,000 nodes at the same time is the GraphQL module for Drupal doing that as well So if you actually look at the query that GraphQL does here It's only a couple of only a couple of charts. So what we do there is a special thing in here that is called versions and There is another one that says ID and There is a path so one of the problems Yes, is that if you have the GraphQL API completely exposed to anybody and you don't like validate it Yes, you can take down a site with one single GraphQL request because you're just like you're loading it like let's say like If we go back to the Lou Skywalker like if you load the directors of a movie of the directors of a movie of the directors of a movie You will have a memory overflow at one point So what we're actually doing is and that's also done by Facebook. So we took their idea During the build process of the frontend There are scripts in there that look at all possible GraphQL requests that your react app can do and they hash them So instead and that hash table is sent to Drupal Via an endpoint So now and they saved inside of Drupal So now if the GraphQL or the react needs to do a request It actually does not tell Drupal which exactly query you want It just tells him give me the hash XYC because we already talked about that before So that's what the version is here and the ID and then Drupal looks at that sees which of the GraphQL requests does that actually refer to and Loads the whole thing in its own cache and then runs through the whole stuff. Oh, that's pretty amazing. Yeah so That gives you two advantages first of all you can use get requests again because it's just a couple of lines Plus it makes your GraphQL secure because all you can do is exactly that the request that you and Predefined before and the API itself is not fully open And that's a bit crazy and I would like to have something easier But right now that's the only way and we also see the other ones doing it and it works I think it's all fully automated. Okay, so we have like I think we can do you left and then we have to run out Well, yeah, one wonderful talk. Thank you and I guess I was just wanted to clarify our Y'all working on the GraphQL module Are y'all working on? Fubis yes repository. Yes, and that's where we should look in the future as As the module develops in May and three point X matures. Yes, so the development happens on here on Fubi and GraphQL something Where is it GraphQL Drupal? That's the module that is currently happening. That's mirror to Drupal.org and De-coupled app if you want to work on that and send us podcasts, please do so as well. Okay. Thanks Okay, I'm getting caked out. Sorry a quick one. Thank you for much for a presentation Thank you, Amanda Good question Not here, not here, but if you go down to the Amidst labs booth, you will find a car there Yes, and I also want to go Just like to here, but yeah, is this your dangle? What is your session about it's about Solving the same problem