 Good morning, everyone. This is No Compromises, React, Relay, and GraphQL on Drupal 8. I'm Sebastian, also known as Fubi. I'm Campbell, also known as Oh, the Huge Manatee. And Moshe Weitzman, going by Moshe Weitzman. Hi, everyone. Right, so why No Compromises? We three and a couple of other people have been working on a very interesting project recently where we were able to reuse lots of interesting technologies that we have been introducing slowly into the Drupal community over the past year. And it's No Compromises because we have finally made it onto a project where we can use the full stack. We are using GraphQL for the data layer, Relay for communicating with the Drupal backend through GraphQL, and we're using React for a fully-decoupled front-end. So we have a very complete stack of different technologies. This is just an excerpt. I'm going to quickly introduce you to a couple of these logos so we will see them across the presentation later. It might make sense so that you understand what we are talking about. So for authentication, we are using R0. For data fetching and for communicating with the backend, we are using GraphQL, which is the top left logo. And we're using Relay to communicate between GraphQL and React. We are using React for the view layer for rendering our front-end application. And we are using Redux for the local state in our application. And we're using Express.js on a node server to pre-render our HTML through React so that you can get a pre-rendered representation of the full page before even having the JavaScript on your client side and so that Google search engines or other search engines can index the site without having to worry about rendering the JavaScript. For building our JavaScript or the front-end in general, we are using Webpack. And we are using various plugins in the Webpack build chain like CSS modules to be able to fully use the component-based approach that React is popular for. So we'll begin by talking a little bit about the GraphQL stack that we have in the backend. And for that, Moosh, go ahead. OK, I'm going to start by just demonstrating GraphQL and how it interacts with your Drupal backend. OK, hopefully that looks all right. OK, so what did I just do there? Where we are right now in the URL bar, I went to my development site. And I went to a URL called GraphQL slash explorer. This is a page that is brought to you by the GraphQL module for Drupal. And what we're seeing at this page is a pretty special feature of GraphQL called GraphIQL. This is a in-browser IDE that Facebook made for the GraphQL community. So what you can do at this page is you can browse your whole GraphQL schema. You can write queries. While you're writing queries, there's real-time autocomplete for the fields that are available. And there's real-time validation for the query that you're authoring. And it's really easy to iteratively build a query and run the results and make sure it's coming back just the way you want. So the actual query that you're seeing here starts with the word node. And that's just an unfortunate overlap with the Drupal concept of a node. Basically, that's the entry point to load a single entity. So this particular query that I wrote is loading a single entity. And you can see the parameter to the node entry point is ID2. So we're loading the second entity in the system. And then inside these curly braces, we're telling GraphQL what fields from that entity we want returned. So this is one of the main benefits of GraphQL is that there's one entry point. In this case, the Drupal module exposes slash GraphQL. And the query author, meaning the client side, is the one who says exactly what the shape of the response is that they want back. The caller is saying, in this case, entity number 2 and only the title back. And if you look on the left-hand side, this is the query section of GraphQL. On the right-hand side is the response. And let's say I want more than just title. I clicked Enter there. And then I click Control Space. Control Space is the way that you trigger the autocomplete for GraphQL. So these are all of the fields that are common to all entities. So if I care to also see the type of entity number 2, I just autocomplete it to type. I press Control, Enter. And I issued a new GraphQL query. And I'm going to see the results on the right-hand side. You'll notice that in my JSON response on the right-hand side, there's a type field that just arrived. And inside of that, there's the target ID, which is Article. The reason why it has that nesting is because Article is actually a configuration entity. Going forward, there are more fields that I could choose to put in here. I want to put in the UID. All entities have a user ID that is the owner of the entity. And furthermore, I can do more here around the UID. I can actually say I want the whole entity. So what you're seeing here is that you can write GraphQL queries that do more than just return one entity. Here in the response, not only are we getting the UID's number, the reference to the author, which is itself an entity, we are getting the full entity. So this is everything that Drupal knows about the user ID, in this case, number one. The name, the mail, the time zone for user number one, and so forth. So GraphQL can easily follow entity references. And the awesome byproduct of being able to get all of this in one query is that your client-side application is much faster than having to make multiple round-trip HTTP queries. So the core REST API out of the box would require multiple HTTP requests for the sort of data that you're seeing in the response here. GraphQL doesn't require multiple, and neither does the JSON API. Those are kind of the three popular ways to do web services in Drupal 8. And this is a real big benefit for GraphQL. I guess I made a tangential reference to the GraphQL schema when I started. The Drupal module does something pretty awesome that I want you guys to know about. The Drupal entity API can have any number of entity types and fields associated with those entities. So the site that we're working on right now, here we are at the article manage fields page. So this is pretty typical for Drupal. We have an article content type, and we have a bunch of fields associated with it. And the fields have their settings and so forth. So the GraphQL module reads all of this entity definition data and builds a GraphQL schema out of it. And so we really are taking advantage of all the hard work that has done an entity API. And below that, the type data API. And we're building a proper schema out of it. And once we have a proper schema, we just have awesome tools that can be built on top of it like this graphical browser that has type ahead knowledge of all of the fields that are available to you. So I just want to show you a different kind of query. Here, our entry point was node. Another one is called node query. And this one, node query type article, I think is how this works. Node query is used for getting listings. So the first one was just a single entity load. Node query is for getting multiple back. So you can see the response just came in. There's actually two responses here. Two titles might be more clear what's going on if I actually show their IDs. Their NID node ID, you'll see that it's like article number one and article number two on the site or two and three. So we have an entry point to request listings as well. So this is analogous to views that we use in site building. The GraphQL module builds upon the entity query API in Drupal. So the module translates these incoming queries from the React front end and runs entity query in the background. So entity query is a great API in Drupal if you haven't used it. It's storage agnostic. So if you decide to store your entities in Mongo or you decide to do something optimized there, all of this is just going to work because of the entity query abstraction. If you decide to change your schema while you're site building, you decide to add a new field. The GraphQL module is smart enough to rebuild its GraphQL schema any time there's entity definition changes. We use the cache tags API. It's super simple to do that. Other thing I want to say is that we respect the entity access control that the Drupal entity API provides, both at the listing layer and at the field layer. So I have an access protected field. I want to show you how that works here. So I've enhanced the query a little bit here. And I used a new syntax that we haven't seen before with triple dots coming in front. What we have said here is that for the entities that are coming down, if they are of type article, we're going to show the bundle fields. What's available to me are the bundle fields that are attached to articles. In this case, I created a gender field really quickly. And it's a true-false field, which is pretty weird for gender. But gender is a little weird in general. So that seemed like the safest thing to do. And we see for these two entities that are getting returned, one has gender true and one has gender false. So I'm logged into GraphQL and issuing queries as UID number one. So I clearly have access to everything. I have access to the gender field. If we look over here, this is our structure page and now the detail on the gender field, you can see that I've used the field permissions module to make this a private field. So only the author and administrators can view the gender field. So how GraphQL handles this, I've switched browsers. I'm now over in Firefox. And am I issuing a let's do let's just copy the query that I ran over here into Firefox. Firefox is logged in as a regular user, not as a privileged user. So the same two articles came back with three fields, just like I requested them. The only difference is the value of gender is null now. So this person who issued the query doesn't have access to gender fields, so it doesn't get the value for genders. So the GraphQL module maintainers have been very careful to respect entity access control and field access control. At the same time, we're respectful of the caller. The caller said they wanted gender back. So we're going to give gender back. We're not going to give them JavaScript errors because the shape of their response is unexpected. So we return the gender field in our response, but we don't give the value. All right, so just moving on to the actual benefits, I want to summarize those. How does that look? Not perfect. That's better, almost better. The benefits of GraphQL, we minimize the number of HTTP requests. Okay, that's the biggest one. Our calling applications are faster. Specifically so you don't get stuck at a loading screen like that. Right. The size of the HTTP response is quite a bit smaller. And it's smaller because you recall that only the fields that were requested are returned in a GraphQL response. So if you compare that with the core REST API, your responses are everything. You get all the fields. If you were to not want all the fields, you have to do server-side work to make a new REST plugin that only returns some of them or perhaps do an alter to server-side alter to remove some fields. In other case, you have now created some burden on the backend team in order to fulfill what the front-end team wants. So the number and size of the HTTP responses and requests is different. I talked about the shape of the response being exactly what the client wants, okay? Another huge benefit of the GraphQL web services is that you no longer have versioned APIs. It's common in REST to have an endpoint that is version one and endpoint that's version two, that sort of thing. You don't need that in GraphQL because really the client is responsible for dictating what they want in their requests and their response. And they do that within the parameters of what the server is offering, which is to say the JSON schema that the server has published, all right? There is a way to deprecate formally your properties in a GraphQL schema. So you let the clients know what's going on. And I talked about this rich schema that's built out of the Drupal entity API. It's kept up-to-date and auto-generated whenever there's changes. Because we have a rich schema in GraphQL, we can build cool features like graphical. And for example, our front-end, our React front-end likes to validate that the queries are valid during build time, during JavaScript build time. They compare against the published GraphQL schema. And flag any client-side queries that are no longer valid during build time. A little bit about the momentum behind GraphQL. There was a huge announcement recently that GitHub is gonna provide all of their API over GraphQL. Traditionally, that's been a REST API that many of us have used. They decided that that was insufficient for their internal uses and they thought it was probably insufficient for some of their clients. And so they're also providing all of their great data over GraphQL. The spec finally has reached 1.0. It's something that everyone can rely on and build upon. And since we're at Drupalcon, the Drupal module is in really good shape and has had recent development this week. We would love if people joined us at the Sprint tomorrow and helped push it even further. Some of the new advancements in the module are listed there. Okay, we have relay compliance. We have an OOP approach to schema generation and we support config entities in addition to content entities, which is also the REST API doesn't yet do. Okay, so you wanna switch laptops? Yeah, if we could switch to number two, please. I mean, theoretically, we'll be looking at the same slide so I won't know. All right, so one important piece of context for this project that we've been working on is this is not about building a single site. All right, actually, the objective is building a framework where you can have an almost entirely independent front-end team that is building tens and tens of sites, something around 100, 200 sites. You don't wanna have to be changing back-end support for all of them. That makes something like GraphQL really important, where the client gets to dictate the schema. It also means that there's a real problem around authentication, because we don't know what you're going to be building your front-end application in. We wanna make sure that whatever authentication system we have supports everything. And what's more, because the client gets to ask for whatever it wants, that we have a great way to send queries, being able to authenticate the user who is gonna be receiving the data is important. It's also actually worth mentioning these are not brochure ware sites. A lot of the time when we do decoupled demos, you see a relatively simple site. These are front-end sites that have real interaction. The first one we're doing has user forums, for example. We have editors on the back-end that want to be able to jump into the front-end and see their drafts and see how that layout works. Obviously, we don't wanna be showing that to anonymous users. On top of that, this same authentication method has to be able to be supported in Drupal for people to get into the back-end and do their content editing there. That's probably the lowest bar. We know how that system works. So no matter what, we need an authentication system that's shared between front and back-end, and it has to be available to the front-end developers really early in the build. So we abstract authentication out to Auth0, which is a software-as-a-service authentication provider. Auth0 gives us, well, first of all, gives us a really easy interface for the client to do their user management tasks and their login attempt audit tasks. That's wonderful that I don't have to worry about that. It also supports a variety of identity providers on the back-end, makes it quite easy to integrate them, so whatever you want, from Active Directory to your own custom database structure to who knows what in any combination. It also will use social login providers, if you like. So Facebook, Google, Microsoft, again, you name it, and in whatever combination you name it. That gives us a lot of flexibility for the front-end website to determine what social logins or what methods of login are appropriate for their user base. It does single sign-on as well. It takes care of a lot of these relatively complex problems. And it gives us a lot of flexibility on the implementation side. Actually, Auth0 brags at the top of the documentation if you can make an HTTP request, you can support Auth0 logins. I apologize for the pun at the bottom of this slide. We're not even using LDAP Bind, but I just couldn't resist. Oh man, how many people got the joke with LDAP Bind? Hands up. Okay, that makes me feel much better. So it's important to note and bear in mind the distinction between authentication and authorization. We're abstracting authentication out to Auth0, but the entire permissioning structure remains in Drupal. Once we know who a user is, Drupal handles authorization for their specific field level access. So if you're not familiar with the general Auth problem, you can shorthand this as thinking about Auth0 providing the login form Drupal provides the permissions. So this means that we can build even complicated authenticated user functionality into the front end pretty easily, just like I mentioned in the last slide, preview draft content, web forums, whatever you're used to being able to control in Drupal's permission system, you can now control in the front end no matter what they're building it with. So this is the stack, and it looks a little tricky, so we're gonna walk through it one piece at a time. At the very back, we have our identity providers. Auth0 gives us total free control over this. So these are the systems that hold various kinds of account data at a minimum, some kind of username and password system. So Auth0 has its own list of users. It is actually the canonical data store for user information, so that's on there. The client's interested in connecting their administrative AD to decide who are the back end editors, no problem. And they have a legacy typo3 database that has a bunch of user content in it as well that's relevant to the forum. So they have a custom plugin. It's, I think it's eight lines that lets them do their user authentication based on whatever typo3 is doing. Auth0 provides basic authentication through username and passwords. They're talking about including some social logins, Google, Facebook in particular. But basically, I don't have to care as the back end developer. Authentication is handled with a JavaScript embedded login box. It's exactly the same on front-end. It's the same for content admins on Drupal. We'll have a quick look at how easy that one was to implement. And once a user authenticates against Auth0, they get a JSON web token in their browser. How many people here have worked with JWTs before? Okay, only a few people less than have worked with LDAP bind. Good to know. Well, we'll talk about that in a little bit more detail in a moment. Oh yeah, well, that's the Auth0 authentication part. Drupal is our data provider, obviously. So on the first request, it validates the JWT. Authenticated users have accounts automatically generated for them in Drupal. So we do normal Drupal access checks with no fancy source required. And when we create the user accounts, they have invalid password sets. So the only way you can authenticate is through Auth0. The presentation layer is react relay here. Well, GraphQL relay react. I guess if I'm gonna be specific about it. It could be anything at all. All it needs to be able to do is make the HTTP request, show the Auth0 login form, and pass the JWTs along with GraphQL queries. So I'm gonna quickly... Oh, I see the problem now. So I'm gonna quickly show off how straightforward the backend is for the administrators that I don't really need to worry about their problems anymore. Oh, it didn't save my metadata. So this is the administrative interface for Auth0. I guess I should zoom this in a bit so I can read it and so you can. Adding different kinds of connections, different kinds of IDPs, identity providers is nice and easy through a GraphQL UI. Turning on various social plugins. Super easy. Nothing magic. Do you have some enterprise identification provider? Great. It even provides a handful of passwordless options for authenticating people through Touch ID is a pretty cool one that I want to get to use. It has a nice and simple user management interface. And this is where you start to see how extensible this is and what kind of information you get. Remember, we're talking about building 100 or so websites. We want single sign on across all of them. And ideally, I'd like to know that it's the same person who authenticated with GitHub on site A and Google on site B and username and password on site C. So you can see that because it stores my primary identity provider, it'll actually also store what are the other identity providers I use. That's right, I'm not using refresh tokens. And we have audits, except it's been a long time since I've logged in. More interesting is that you have a completely flexible metadata that you can attach onto here. So this is just simple JSON format. We're using this as a place to store user roles and user roles as related to the specific front end domains. All of this information is available to me in the back end or in the front end if you choose to request it as a result of the login operation. They are quite full service. We can go through the long list of functionality here, but what I wanted to show you is that this is a fantastic, easy to use interface that I didn't even have to train the client on. They were already very comfortable using it. So now we're gonna switch back to presentation mode, ideally. Do you guys mind seeing my browser along the top there? Because I don't know that I know how to get rid of it. Yeah, but now I'm missing my other thing. All right, so this is how we... This is how easy it was for us to include the Othcio login form in Drupal. This is just a twig template that we massage into the login form. And you can see this is a really simple JavaScript. We pass it the client ID domain and special callback URL from settings.php. Done. The login callback, I mentioned we passed it in from settings.php, so this is what actually gets executed. So we give away for the user to disable it because that's just nice, or for the administrator anyway, to disable it. And we use the Othcio SDK. They offer SDKs for every language that I could think of, and the PHP one is extremely easy to use. So as long as we can manage Othcio getUser, we know that it was a valid login attempt. It also returns specific information on the same request, depending on what we had put... What we had put into our Othparams here on the JavaScript. So we can use that information. Obviously, what we care about here is email because of the way they're setting it up. We don't have a unique username. We also provide an event to respond on this, and this is actually where we do our more custom synchronization. We looked at that metadata JSON, easy enough to pass it into Drupal roles. We map the Othcio user accounts to Drupal user accounts with the external auth module. Does anybody here remember user external login register from D7? I'm happy that you remember Dress. Right. I think a lot of us in the consulting field were doing a lot of unnecessary work because we didn't realize that this was in 7. Now it's called out in a module and somehow it's a little bit easier to find. So it provides the convenience functions for mapping an external authentication system to Drupal user accounts. It's set up as a service, so it's very easy to include in whatever you're doing on the Drupal 8th side. And it's too bad I didn't include the code line for this. And it means it also provides methods like login and register all in one line or separately login finalize if you just want to set the session. Very, very easy to use, very, very handy. Right, so this was extremely easy doing the Drupal part of this. I think we expected a lot more work involved. I mentioned briefly that when Auth0 authenticates you, it sets JSON web token. So JSON web tokens are hot stuff and you read about it a bunch on Hacker News and people debate about what you're supposed to be doing with it and what you're not. And here's a brief idea about what it is. It's just three 64 encoded strings. The first one is a header that says this is how it is signed. This is how we validate the authenticity of this particular token. The second part is the payload. That's actually, I know for those of you who don't read base 64, it's a bit hard to tell, but that's actually just absolutely any JSON that you want to pass in. And the third one is the signature. So that's how we actually get to validate that this is issued by who we think it's issued by. Actually, I'll stay on this for a bit. It's a pity I don't have my speaker notes because that makes it a lot easier. It's all right. So because you can do arbitrary JSON, there's a lot of people that like JWTs as a way to have actually zero knowledge front ends. Why not just include the whole user profile in there? You can put their user profile picture in there. Their favorite MP3. You can store absolutely anything that you like. Part of the point about JWT is that it ends up in a relatively short string. This is a small amount of data. This should be able to be put into an HTTP header. You don't have to put it there. You can transfer it through whatever you want and you can store it as a cookie. You can store it in local storage again, whatever you want. But the point is that it's simple and it's light. Also, it's signed, which helps. It gives you the sense that this is something that you can really count on for privileged data. And that's true. But because this is a little more complicated than what we're used to with session cookies because it's newer, there are a lot of gaps in how people implement. So one big gap that came up recently was when you have that first section, that header, you get to declare how was this signed? Is this with RSA? Is this just an SHA signature? Or is it none? None is valid. And it turns out that most of the libraries for JWT accepted none as a valid value and didn't throw any kind of a notice that actually this could be issued by anyone at all. This kind of mistake seems to come up more and more with JWTs. The point is you don't want to pass around a ton of information with it. You actually really want to set a low expiry time on them. This is one of the things that's very common to put into the payload and in fact it's in a reserved namespace in the payload. You can set an expiry. Note that that is an expiry that you don't have any way of controlling from the back end. You set it once and then it's done so you can't revoke a token. That's also a little problematic. If we have the entire user object in the token, what happens when I want to change the role and remove admin rights? I'm just going to wait for it to expire. It's really designed to be used with short expiry times as a way of passing claims from one place to another. Claims, not the entire object, claims. In fact, in their documentation, they use claims for all the top-level keys in the JSON array. It seems like they're doing it just to confuse you. They're not. They're doing it to remind you exactly how this is supposed to be used. So that means that it doesn't replace a session cookie. If you are using it to replace a session cookie, you are doing it wrong. You use it to set the session. You use it to accept the information from Auth0 that yes, this person is valid and within this three-second time window, they have the admin role and we use that to set the session, just like normal. So this is the code that we're using. Again, we're using the Auth0 SDK to decode the token. It's pretty simple, but they have the convenience function, so we might as well use it. All we're grabbing out of it is mail and we use that to set mail and name. And then you can see right at the very bottom, external Auth service, we're using login register. And that actually runs, that actually also runs login finalize, which sets the session, just like normal. So we really expected that authentication was going to be a difficult problem for us. Right, 100 websites in the front end shared between the front and the back and God knows what custom IDPs and in what order and what custom rules we needed for them. Actually what it turned out is that we selected a provider and it's a somebody else's problem field. I think we have a total of 30 lines of code plus 400 lines of tests for this. Much, much easier than we expected and very easy for a client to use. Back to you. I wasn't sure if I was going to get my part. So our front end stack, which was actually supposed to be the biggest part of the presentation. Yeah, I've got 20 minutes left, it's fine. So we're building on React and the stack itself is a little bit more complex on that, but let's talk about React first. It's a JavaScript library for rendering. It's a view library. It is all the key factors that make it so famous and so nice to use. It's reactive, so you don't have to worry about state transitions. It is declarative, it has a very nice API. It is component-based. We're talking about componentizing our seam layer right now, so React, if you use the right approaches, we already have that for free. And it's super fast in the browser because it's based on a virtual DOM. What's most important for our project, however, is that it pairs extremely well with GraphQL and Relay. So this is what a modern React component with ES6-7 looks like. So you have this module file and you define a component, and the component is defined in JSX, which is very similar to HTML and is compiled by the bundler. We're using Webpack and Babel to simple method calls on React to create HTML elements, which are written into the virtual DOM and then passed onto the browser. So you don't have to worry about the browser API. You're just doing JSX and React handles the rest for you. What you see here is very interesting. So as I said, we are trying to make standalone components, things that are very much self-contained. So we are importing the styles. We are importing the CSS into the JavaScript. The style is weird, right? I'm sure, who has seen that before here? So this is possible with Webpack. It allows the styles CSS resolver in the Webpack configuration to pick up the CSS file and instead of loading the actual CSS file content, it will take the class names out of the CSS file and create a map out of it. A hash map, where the keys to the map are the class names and the values are base64 encoded strings, which are unique across the entire application. They are guaranteed to be unique. So you don't have to come up with weirdly shaped class names with a lot of hyphens to make sure that they are really unique. And this is how you get true componentization inside of your React components. You write a single file and everything inside of that file should be enough to cater for the entire needs of that component. And not only do we do that for CSS, we also have relay. Normally when we are writing twig templates in Drupal and we are rendering HTML to those twig templates, we have to do a lot of preprocessing. We have to load stuff up front and then pass it into the template, right? So it's bottom to top, top to bottom. And in React with relay and the graph back end, we turn that upside down. So instead of the preprocessing or the rendering step, first loading the data and then passing it into the template, the template itself specifies what data requirements it has in order to render all of the fields. And that looks like this. So as you can see here, we have this component, which is trying to render the article ID, the article teaser image, title, lead text, and the creation time. And the way that that information flows into the React component is by using the create container function from relay and then specifying the data requirements for the component. This is a fragment of a GraphQL query. Every component that is enhanced with a relay container can specify data requirements. And those data requirements are picked up in the rendering process of your React application. So when you do routing with React and relay and the new rendering tree becomes active because you click the link, it will first figure out which components are going to be rendered on that page. And then from each of those components, if they are relay containers, it will pick up the data requirements and those components merge them into a single query. That single GraphQL query is sent to the back end and GraphQL responds in a single payload and at which point the data is, again, picked apart and sent down the tree to each component that requested the data. So if you want to show additional information in your component, you don't have to worry about changing your view in the back end. You don't have to configure anything. You don't have to adapt any data layer stuff. You just need to add the required, the desired field to the query and you have to render it in the component. And then it's done. So this is a very nice stack and the separate components, GraphQL, Relay and React, all from Facebook, by the way, they can be really nicely combined into a very powerful application data fetching layer. And I'd like to switch to monitor 3 now, please. So we can look at the prototype. I'm sadly not allowed to tell you the name of the company that we are building this for. But I hope that we can come back to Drupalcon in Baltimore and give a case study. The project is supposed to be scheduled for release end of this year and at which point we can show the full sites. But first of all, let's look at how we resolve routing and how we do data fetching with Relay. Can we switch to monitor 3? I wouldn't want to do that on a Mac, I'm sorry. See, we are going through all this hassle of switching the monitors just because I don't like Macs. Okay. Thanks. Okay, so what do we have here? This is, as you can see, I had to replace the logo and change some colors and change some of the text that we are showing. But if I refresh the page now, you will first see that the JavaScript files we are loading, they are chunked. And this is something that Webpack does for us. We are bundling our application and based on our route configuration, which you can see right here. So we have an articles route, for instance, and it says, okay, for the article route, the component from React that we are supposed to render is the component. And by defining the routing in this way, Webpack can figure out which files are required and what route, and it will intelligently build a dependency tree of all of those files in your stack and build separate chunks, separate JavaScript bundles. So the frontend, the client browser, really only receives the code that it needs in order to render the page that you are currently looking at. So this is what we have here, right? The JavaScript file, this is the common ground for all of the routes that we have. That's why it's also the biggest file, with 287 kilobytes. And that file contains React, for instance, the router, it contains Relay, and all of the common dependency that we have across all of these files. And then we have a couple of chunks. Those are separate JavaScript files that have been generated by Webpack, which are only required for the front page. And then if we switch to a different page, let me clear this up, you will see that it first loads another chunk that is required for fetching or for rendering the second route that we add now. And what you also see is that instead of doing a full re-render, it doesn't hit the server for retrieving the HTML from scratch. Instead, it does a GraphQL request, which responds with the data that we have that we require for rendering this page. So the GraphQL query, as I said, is generated automatically from all of the components that we see on this page. And each of the components can specify its data requirements. So the GraphQL query looks like this. It's a gigantic generated query, and it's obfuscated, so it's very hard to read. But it contains all of the fields from the different components that are displayed here. So this is a single item from the request. And it's all there. So what happens if we go to another route? Again, we get another chunk. And now it's on this new route. And you can see it's very performant because we're not hitting the server. We're only asking for data from the server. We're not rendering on the server anymore. However, if you look at the source code, you will see that this is a very large payload, a very large chunk of HTML and JSON. And that is the first page that we requested. So if we disable JavaScript now, it would still work because we are doing servers at rendering at the same time. So if we go to the front page again, you'll see it's rendering the front page. And that's because the first request always comes through the noted JS and ExpressJS server. This is a huge benefit also for performance, not only for Google. If you're on a slow machine and on a slow connection, the JavaScript files don't have to be rendered for you to interact with the website. You can see the site. The CSS will be there. Maybe the CSS is loaded faster. And you can already interact with the site. You can even click links even before the JavaScript is done because then it's just a normal HRF and the server answers with the second route again. Right. So if we look at this component here, this is an article. You see these data requirements here. Article is passed in as a property. Oh, I'm sorry. This is the wrong component. So this is an article on media article. And we have data requirements that are specified down here. And if you look up here, this is where we render them. It's very simple. And you don't need to do anything on the backend. Okay. So we have nine minutes left. So what we find exciting in this is not just that we get to use a bunch of really cool technologies that you read about all the time. Okay, though, to be fair, that is also pretty fun. What's interesting, at least for me, is this is a very different way of looking at Drupal's role in your website. And most of us are used to Drupal playing a central role, if not the defining role in your website and having to really fulfill all needs. And it's just not the case anymore. It's one of the greatest strengths that we get with Drupal 8 is that now you consider Drupal a piece of your architecture and not even necessarily the defining piece. In fact, one of the most powerful things that we're doing with this is that the data layer now, that the front-end can be actually really agnostic to what's going on in the backend. It doesn't need to care that it's Drupal underneath the hood. And we get to choose Drupal because it's so good at the data manipulation and data consumption from the various back-end sources. I think that's about it. There's seven minutes left for questions if people have them. No questions? You're all already React Relay experts? Yep. Hi, my name is Buagek and I wanted to ask about the status of the Drupal module. So, is it like ready to connect to Relay and are mutations supported? So, most quickly talked about it in the beginning. We have a new branch in the module which is based on a new library that supports Relay. So the fundamental, the crucial part of the module is actually the PHP library that does the parsing and handling of the GraphQL request. And we are using a library now that does that and it's capable of supporting Relay. The schema that we are writing right now is Relay compliant and that's what we are working on right now in this week. So we are making a Relay compliant as we speak, essentially. Frederick, who is sitting right behind you, is also working on that with us together. So if you want to join us for that, feel free to come by at Spring's launch and find me. Oh, you asked about mutations as well? So mutations is another thing. It's on the roadmap. But for this sprint in this week, we are going to focus on Relay and config entities and generating the schema with the new library that we are using now. But mutations is definitely possible as well, also with the library. If you use the module right now in the 3x version, you can already use mutations, but you have to create them yourself. You have to create the schema for the mutations yourself. It's very simple, though. Yeah, so I had a question about the dynamically generated JSON schema. One of the interesting things about the project that you're presenting is that potentially you have to set off the front end and the back end at the same time if you've got a well-defined schema. So do you just have to set good ground rules about what you'll call your field names within Drupal to ensure that the schema is achieved or is there any way that you can kind of bridge that gap? So that you could actually define the schema ahead of time and then have Drupal achieve that? Yes. So that's actually the way that we work. We not only decoupled the front end from the back end, but we also decoupled both teams that were working on this project. So we have a front end team and we have a back end team. The back end team is currently largely working on migrations from those systems, and the front end team is working on the front end. Obviously. What the hell? And the way that they work is we have a separate MongoDB-driven schema, which they create as they write their features in the front end, and it's very simple. They are using Mongo's and NPM library for interacting with the MongoDB storage, and they are using the GraphQL JS library to create a GraphQL schema out of that. It's very simple to create schemas with the JavaScript library. So they are not blocked by the back end at all, and they will create the schema telling us essentially what features they need, what data model they need in the back end. So we have first build in the front end and then we are doing the back end afterwards. It's a very good approach because then we are really catering for the requirements of our applications. For a company that... I'd like this very much, all these new developments on the front end, and for a company that would consider using React or GraphQL on the combination. How future-proof do you think it is? What's the chance that, let's say, you build a site now three years after you have to still maintain it? What's the chance that there will be people or even a future for this technology? Yes, that's a very good question. We have seen a wide adoption of React. Many, many great big companies use it now. Same with GraphQL. GraphQL has been released in the 1.0 version now. The spec is production ready now. It's considered production ready. And it's used by GitHub. It's used by Facebook. It's used by Instagram, Netflix, React as well. So I see that GraphQL actually, although it is less popular than React at this point, has a much brighter future because I think that it's a very nice approach to solving the HTTP API problem. React is a solution to the problem that we have right now with our DOM tree and the browser. It's a solution to the performance problem, essentially. And I see that at some point React will again fade from existence, but that doesn't mean it's not going to be maintained anymore. Too many big players are relying on it at this point. So, yeah. Does that answer your question? Yes, thank you. Hi. About the GraphQL queries, is the entity reference also taken care of? So I can go deep in getting the information. And also, when you show the access for a field, how can we distinguish between no access and undefined or no data in that field? I'm not sure that you can distinguish right now that case. We could add that distinction. I don't think that's hard to do, but right now the schema we generate doesn't do that. Before that, you asked about entity references. I showed an example during the presentation when I retrieved the UID field from an entity at a typed data layer. That's an entity reference. And I traversed into that entity reference and showed you the time zone and language for that user. How deep can... So imagine you have... You can go like 10 levels deep. It's really... As far as you would need to go, you can keep traversing. Thank you. Hello. I'm just wondering in terms of hiring developers for the front-end stuff, do you hire specialist React developers or do you kind of try to upskill current Dribble themas and front-end devs? Yeah, so for this project, the client originally wanted to go with Angular and then we told them that's not going to happen. So... No, no, so what we did was we took an existing starter kit for React, built a prototype and convinced the client, and then we educated the client on React and Relay and GraphQL. So they have a... Yeah, a nicely sized team at 5, 6 developers maybe. And we did some workshops in the beginning and they were very smart and so they quickly picked it up. And so the client is mostly providing the front-end team. But we educated them on the React stack now. Any more questions? All right, so that's perfect. We have 20 seconds. Thanks for your time. Thanks. Thank you very much.