DrupalCon Dublin 2016: No compromises – React, Relay and GraphQL on Drupal 8

good morning everyone this is no compromises react really and graphed here on Drupal 8 I'm Sebastian also known as foobie I'm Campbell also known as all the huge manatee and most Weitzman going by most 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 but we can use the full stack we are using graph care for the data layer relay for communicating with the Drupal back end through graph care 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 gonna quickly introduce you to a couple of these logos so we you 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 our 0 for data fetching and for communicating with the backend we are using graph here which is the top left logo and we're using relay to communicate between graphic 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 are using express to s 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 web pack build chain like CSS modules to be able to full used a component based approach that react is popular for so we'll begin by talking a bit about the graph ki step that we have in the back end and for that motion go ahead okay I'm gonna start by just demonstrating graph QL and how it interacts with your Drupal back-end okay hopefully that looks all right okay so what did I just do there where we are right now in the title in the URL bar I went to my development site and I went to a URL called graph QL slash Explorer alright this is a page that is brought to you by the graph QL module for Drupal and what we're seeing at this page is a pretty special feature of graph QL called graph iql this is a in browser IDE that Facebook made for the graph QL community so what you can do at this page is you can browse your whole graph QL 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 unfortunate overlap with the Drupal concept of a node basically that's the entry point to load a single entity okay so this particular query that I wrote is loading a single entity and you can see the parameter to the node entry point is ID 2 so we're loading the second entity in the system and then inside these curly braces we're telling graph QL what fields from that entity we want returned ok so this is one of the main benefits of graph QL is that there is one entry point in this case the Drupal module exposes / graphic UL 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 all right the caller is saying he in this case entity number two and only the title back and if you look on the left hand side this is the query section of graph iql on the right hand side is the response okay 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 graph iql 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 two I just auto-completed to type I press control enter and I issued a new graph QL 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 configuration entity okay going forward there are more fields that I could choose to put in here I want to put in the UID write 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 graph QL queries that do more than just return one entity all right here in the response not only are we getting the you IDs 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 okay the name the mail the time zone for user are number one and so forth so graph QL can easily follow entity references and the you know 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 graph QL 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 graph QL I guess I made a tangential reference to this the graph QL schema when I started the Drupal module does something pretty awesome that I want you guys to know about the Drupal entity API right 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 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 graphical module reads all of this entity definition data and builds a graphical schema out of it and you know so we 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 note queries use forgetting listings okay 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 mid 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 graph QL 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 alright so entity query is a great API and terpil if you haven't used it it's storage agnostic so if you decide to store your entities in or you try to 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 your site building you decide to add a new field the graph QL module is smart enough to rebuild its graph QL schema anytime there's entity definition changes okay 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 n API provides both at the listing layer and at the field layer alright so I have an access protected field I want to show you how that works here okay 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 we have what we have said here is that for the entities that are coming down if they are of type article we're gonna show the bundle fields that what's available to me are their bundle fields that are attached to articles in this case I created a gender field really quickly and it's a true/false quit you know field which is pretty weird for gender but genders 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 Jenner true and one has gender false okay so I'm logged in to graph QL and issuing queries as you ID 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 graph QL 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 okay 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 okay so this person who issued the query doesn't have access to gender fields so doesn't get the value for genders so you know the graph QL module maintainer z-- have been very careful to respect entity access control and field access control all right at the same time we're respectful of the caller the caller said they want a 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 okay 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 graph QL we minimize the number of HTTP requests okay that's the biggest one arc 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 our risks are returned in a graph QL 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 to make a new rest plug-in that only returns some of them or perhaps do an alter to server-side alter to remove some fields in either case you have now created some burden on the back-end team in order to fulfill what the front-end team wants so the number and size of the HTTP responses and request is different I talked about the shape of the response being exactly what the client wants okay another huge benefit of the graph QL web services is that you no longer have version 2 ap is its common and rest to have an endpoint that is version 1 and end point that's version 2 that sort of thing you don't need that in graph QL because really the client is responsible for dictating what they want in their request in the 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 in a graph QL 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 API the Drupal entity API it's kept up to date and auto-generated whenever there's changes because we have a rich schema in graph QL 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 graph QL schema and flag any client-side queries that are no longer valid during build time a little bit about the momentum behind graph QL there was a huge announcement recently that github is gonna provide all of their API over graph QL 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 graph QL the spec finally has reached 1.0 it's something that everyone can rely on and build upon and you know since we're at Rubicon 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 Opie approach the schema generation and we support config entities in addition to continent ease which is also the REST API doesn't yet do okay so you want to switch laptops yeah if we can 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 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 a 100 200 sites you don't want to have to be changing back-end support for all of them that makes something like graph QL 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 and we want to make sure that whatever authentication system we have supports everything and what's more because the client gets to ask for whatever it wants we have a great way to send queries being able to authenticate the user who is going to be receiving the data is important it's also actually worth mentioning these are not brochure aware sites a lot of the time when we did a couple 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 backend 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 want to be really we don't want to 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 backend and do their content editing there that's probably the lowest bar we know what 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 off zero which is a software-as-a-service authentication provider auth0 gives us well first of all it gives us 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 backend gives it makes it quite easy to integrate them so whatever you want from Active Directory to your own custom database structure - 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 are 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 kind of relatively complex problems and it gives us a lot of flexibility on the implementation side actually off Xero 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 know got the joke with LDAP bind hands up okay that makes me feel much better so it's important to note and and bear in mind the distinction between authentication and authorization we're abstracting authentication out to our zero 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 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 off indicated user functionality into the front-end pretty easily just like I mentioned in the last slide right 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 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 right now zero 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 user name and password system so off zero has its own list of users it is actually the canonical data store for user information so that's on them the client is interested in connecting their administrative ad to decide who are the 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 let them do their user authentication based on whatever typo3 is doing Ozzie row 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 was handled with JavaScript embedded login box it's exactly the same on front ends it's the same on four continents on Drupal we'll have a quick look at how easy that one was to implement and once a user authenticates against Accio they get a JSON web token in their browser how many people here have worked with JWT is before okay only a few people less then 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 opposite authentication part Drupal is our data provider obviously so on so on the first requests it validates the JWT authenticated users have accounts automatically generated for them in Drupal so we do normal Drupal access checks with no fancy sauce required and when we create the user accounts they have invalid password sets so the only way you can authenticate is through r0 the presentation layer is react relay here well graph QL 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 osteo login form and pass the JWT s along with graph QL queries so I'm gonna quickly oh I see it now so I'm gonna quickly show off how straightforward that back-end is for for the administrators that I don't really need to worry about their problems anymore no it didn't save my metadata that's fine so this is the administrative interface for auth0 I guess I should assume 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 graphical UI turning on various social plugins super easy nothing magic do you have some enterprise authentication identification provider great it even provides a handful of password list options 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 a hundred 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 I'll accept 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 from Europe as a result of the login operation they are quite full-service we can go throughout 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 ideally you guys mind seeing my browser along the top there cuz 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 osteo login form in Drupal this is just a twig template that we massaged into the login form and you can see this is a really simple Java Script we passed the client ID domain and special callback URL from settings dot PHP done the login callback I mentioned we passed it in from setting up PHP so this is what actually gets executed so we give away to this for the user to disable it because that's just nice for the administrator anyway to disable it and we use the auth zero 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 auth0 get user we know that it was a valid login attempt it also returns it also returns specific information on the same request depending on what we had put what we had put into our off params here on the JavaScript so we can use that information obviously what we care about here is email because of the way there's they're setting it up we don't have a unique username we also provide we also provide an event to respond on this and this is actually where we do our more custom synchronisation right we looked at that metadata JSON easy enough to pass it into Drupal roles we map the auth0 user accounts to Drupal user accounts with the external off module does anybody here remember user external user external login register from d7 I'm happy that you remembered race right I think a lot of us in the consulting field we're doing a lot of unnecessary work because we didn't realize that this was in seven 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 and 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 site on that Drupal 8 side and it's too bad I didn't include the code line for this and it means this will provides methods like login and register all in one all in one line or separately log in 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 our zero 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 364 encoded strings the first one is a header that says this is how 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 base64 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 alright so because you can do arbitrary JSON there's a lot of people that like JW T's is 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 and they're 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 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 how did it how was this signed is this with RSA is this just an SH 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 J WTS 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 the reserved namespace in the tip 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 the role and remove admin rights just gonna wait for it to expire right so it's really designed to be used with short expiry times as a way of passing claims from one place to another write 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's 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 r0 that yes this person is valid and within this three-second time window they have admin they have the admin role and we use that to set the toke this to set the session just like normal so this is this is the code that we're using again we're using the are 0 the r0 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 male and we use that to set male a name and then you can see right at the very bottom external off service we're using login register and that actually runs that actually also runs log and finalize which sets the second session just like normal so we really expected that authentication was going to be a difficult problem for us right a hundred websites in the front end shared between the front and the back and God knows what custom ID pees and in what order and what custom rules we needed for them actually what it turned out is that we selected 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 gonna get my part so our front end stick which was actually supposed to be the biggest part of the presentations well yeah I've got 20 minutes left it's fine so we are building on react and the deck itself is a little bit more complex than that but let's talk about react first react is a JavaScript library for rendering it's a view library it is or the key factors that make it so famous and so nice to use is there 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 right we're talking about component component izing our seam layer right now so react 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 graph care and relay so this is what a react component and more on react component of es6 7 looks like so you have this module file and you define a component and the component is special it's defined in JSX which is very similar to HTML and it's compiled by the bundler we're using webpack and Bob to simple method cause on the react to create HTML elements which have written into the virtual DOM and then passed on to 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 was 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 important to CSS into the JavaScript that's weird right um I'm sure who has seen that before here right so this is possible with web pack it allows the style.css resolver or the this resolver in the web 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 and create a map out of it a hash map where the keys to the map are the class names and the values 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 read components you've 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 TWIC templates in drupal and we are rendering HTML those two templates we have to do a lot of pre-processing we have to load stuff upfront and then pass it into the template right so it's bottom to top at top to bottom and in reaction with relay and the graphical backend we turn that upside down so instead of the pre-processing 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 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 graph care 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 reactor so when you do routing with reactant relay and you and the new rendering tree becomes active 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 from those components merge them into a single query that single graph care query is sent to the back end and grout care 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 are if you are if you want to show additional information in your component you don't have to worry about changing your view in the backend you don't have to configure anything you don't need 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 right so this is a very nice stack and the separate components graph clear really and react or 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 three 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 Drupal con in Baltimore and give a case study the project is supposed to be release or scheduled for release end of this year and at which point we can show the full sides but first of all let's look at how we resolve routing and how we do data fetching with reading can we switch to a micro screen I wouldn't want to do that on a Mac I'm sorry see we are going through all this hassle of switching mini monitors just because I don't like medicines Thanks okay so what do we have here this is as you can see I had to replace the logo and change some 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're loading they are chunked and this is something that web pack does to 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 articles component and by defining the routing in this way webpack can figure out which files are required to what what route and it will intelligently build a dependency tree of all of those files in your stacks and build separate chunks separate JavaScript bundles so the front end the client browser really only receives the code that it not needs an order to render the page of your account is currently looking at so this is what we have here right so the main javascript file this is the common ground for all of the routes that we have that's why it's also the biggest fight with 287 kilobytes and that file contains react for instance the route 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 web pack 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 tongue that is required for fetching the or for rendering the second route that we add now and what you also see is that instead of doing a full we render it doesn't hit the server for retrieving the HTML from spirit instead it doesn't graph KL request which responds with the data that we have that we require for rendering this page so the graph kata query as I said is generated automatically from all of the components that we see on this page on this page and each of the components can specify its data requirements so the graph care 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 from the request and it's all there so what happens if we go to another route again you 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 Jason and that is the first page that we requested so if we disable JavaScript now it would still work because we're doing server-side 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 nodejs and xpress to a server this is a huge benefit also for performance not only for google if you are 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 side the CSS will be there maybe the CSS is faster it's 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 age href and the server answers was the second the second route again right okay 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 back end okay so we have nine minutes left the conclusion 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 be 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 that we're doing with this is that the data layer now are 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 where there's seven minutes left for questions if people have them no questions you're all already react really experts and our 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 fundament of the crucial part of the module is actually the PHP library that does the parsing and handling of the graphical 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 real compliant as we speak essentially Frederick who is sitting right behind you is also working on us on that with us together so if you want to join us for that feel free to come by at Springs lunch 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 of the new library that we are using now but config you tations is definitely possible as well also the library if you use the module right now and the 3 X version you can already use mutations but you have to create them yourself you have to create a schema for the mutations yourself it's very simple though yes 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 could kick 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 like 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 bridge that gap do you know what I mean so that you could actually define the schema ahead of time yeah and then have Drupal achieve that yes so that's actually the way that we work we not only decouple front end from the back end we also dicovered both teams that were working on this project so we have a front-end team and we have a back-end team the backend team is currently largely working on migrations from the old systems and the front-end team is working on the front end obviously and the way that they work is we have a separate MongoDB driven schema which they create as they've write their features in the front-end and it's very simple they're using Mongoose and NPM and npm larvae for interacting with the MongoDB storage and they are using the graph Jas library to create a graph care schema out of that it's very simple to create create schemas with the JavaScript library so they are not blocked by the backend at all and they'll create the schema telling us essentially what features they need what data model they need in the backend so we have first built in the front-end and then we're doing the back end afterwards and that's a very good approach because then we're really catering for the requirements of our applications for a company that I'd like this very much all this all these new developments on the front end and for a company that would consider using react or graph queue and the combination how future-proof do you think this what's the chance that let's say you build a site now and three years after you have to still maintain it what's the chance that there will be people or even a future for 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 of graph graph kit has been released and the one Overson of the spec is like production already now is considered production ready and it's used by github is used by Facebook is used by Instagram Netflix react as well so I see that graph here actually although it is less popular than react at this point has a much more has a much brighter future because I think that it's a very 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 in the browser right it's a solution to performance problem essentially and I see that at some point react will again fade from from existence but it doesn't mean it's not gonna be maintained anymore too many big players are relying on it at this point so yeah does that answer your question yes thank you okay I about the graphic you'll queries is the entity reference also taken care of so I can go deep in getting the information and also when you show the the access for a field how can we distinguish between no access and undefined or no data in that field I'm not surely 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 retrieve the UID field from an entity at a type data that will taped data layer that's an entity reference and I Traverse 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 because it's really as far as you would need to go you can keep traversing okay thank you hello I'm just wondering in terms of hiring developers for the front-end stuff did you try and I do hire from specialist react developers or do you kind of try and help skill have you tried to upskill current Drupal Famers 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 gonna happen so no no so what we did was we took an existing starter kit for react build a prototype and convince the client and then we educated the client on react and relay and graph care so they have a yeah nicely sized team at five six 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 we educated them on the rear deck now any more questions alright so that's perfect we have 20 seconds thanks for your time thanks

Channel: Drupal Association

Views: 3,380

Rating: 4.8333335 out of 5

Keywords: drupalcon, drupal, 2016, Dublin

Id: yhyoQwuSUWo

Length: 58min 56sec (3536 seconds)

Published: Thu Sep 29 2016