 Welcome everybody, this is a decoupled Drupal and Ember. And once again, this is a session that replaced the old session, this time slot. It's a real pleasure to be here and thank you so much for having me. My name is Preston, Kedmina Falcha here in Dublin. I work at Aquia, I'm part of the Office of the CTO, where I work on Drupal itself as well as other open source initiatives. You might have heard of Waterwheel, which is a SDK ecosystem that I've been working with. So here's what we're gonna cover today. I wanna talk a little bit about what Ember is, what decoupled Drupal is. How many people have heard of headless Drupal, decoupled Drupal? Pretty much everybody, okay good. So I'm gonna gloss over some of the sort of setup a little bit in terms of what decoupled Drupal is, just because pretty much all of us know what exactly we're talking about. I wanna delve into Ember architecture, what exactly does an Ember app look like? Talking about setting up Drupal, how do we get Drupal to talk to Ember? Writing an Ember application that talks to Drupal on the front end. And then finally, a little bit of a discussion or a little bit of a sort of rumination on what the future might hold. As you may recall from the keynote yesterday, Jerice mentioned, it was a bit of a surprise, actually. He mentioned that his favorite framework, or at least the one that he's been looking at for community reasons, is Ember. So anyways, what is decoupled Drupal? Just as a little bit of quick background. Well, decoupled Drupal is the use of Drupal as a data provider or a service provider. Using a RESTful API, although there are other solutions available, like GraphQL, which you'll hear about tomorrow. There's two types of architectures that use this kind of approach. There's fully decoupled Drupal and progressively decoupled Drupal. I've got plenty of content in the past about this if you're interested in learning more. There's obviously some risks of decoupled Drupal, which I do want to highlight here and make sure that you're aware of. But there are also some pretty big advantages, namely the fact that you can build applications that are fully decoupled, like Ember. So in Drupal 8, we have Core REST, the whiskey initiative, web services and context core, allowed for web services to be in core. And Views also supports REST export natively. And there's also a module called Relaxed, which you will hear about most likely this week, which works really well with offline enabled applications. But today we're gonna be talking about JSON API. How many people have heard of JSON API as a specification? Okay, cool. So JSON API is a specification that has really gained a lot of steam in the last 12 to 24 months. And the reason why is because a lot of people in the Rails community and a lot of people in the Ember community have really sort of worked a lot with JSON API. Its tagline is really to be an anti-bike-shitting tool. And it's really been very popular in the last couple of years. And actually the really compelling thing about JSON API is that Ember by default integrates with JSON API. And also if you were in the JSON API session that just happened this morning, we might have heard from Mattel who spoke about JSON API and some of the features there. And we now have a very robust JSON API module in Drupal. All right, so what is Ember? Well, you might have heard of Ember as being alongside these two other frameworks, Angular and React. But the history of Ember actually goes back of really long ways. Ember is a successor of the Sprout Core project, which was an application framework, but also a widget library. And basically what happened was the Sprout Core project actually split into an application framework on its own and a set of widgets. Ember is the successor of that application framework. So some of the design principles that Ember follows are a focus on ambitious web applications, more productive out of the box, which means more sort of a more guided approach. I remember when I first started doing these presentations, my first React application actually was a total disaster because it's really hard to kind of get your bearings around exactly how to build a React application the right way. Ember makes it very easy because it's very opinionated. It values convention over configuration, which is one of the big mantras of the Rails community. And it really focuses on making sure that things are stable while maintaining that foresight into future web standards. Ember has a large footprint, and that's something that you might have heard of is that it's got quite a large code size. It's very opinionated, which means that it's not so ideal for more small scale applications or application components that you might wanna stick into your Drupal site in an interpolated fashion. But the Ember framework is also not managed by corporate giants, unlike Angular and React, which are managed by Google and Facebook respectively. And Ember's real sort of aim and mission is to focus on making web applications as close to native applications in their user experience as possible. So some drawbacks of React, as I mentioned, are that it's opinionated, large file size, and of course, Ember applications that are in 1.0 will not work in the present version, which is 2.0. All right, so let's talk a little bit about Ember's architecture, and then we'll dive into some code. So an Ember application state is represented by routes, which is pretty common among these application frameworks, and it has a respective route object that controls what the user sees. There's a lot of ways in which you can set the URL in Ember. You can either modify the URL, you can have the index route, which is when you boot the app for the first time, and then obviously you have events in the application that modify the route, or someone clicks on a link. There's also route handlers in Ember, which is probably a familiar concept to many of you, which is a way to render templates and load data models, and we'll talk much more about that very soon. Ember templates do use handlebars, which is actually quite similar in a lot of ways to Twig. There are some substantial differences, but these templates are very powerful, and you'll see what they look like very soon. Ember models, so Ember has this kind of framework called Ember data, which handles persistent data, which means that you can have client-side storage of this data that can be persisted to a web server, but they can also save it anywhere else, like local storage and what have you. There's also components. One of the things that has really become a trend in JavaScript frameworks these days is nestable reusable components, and Ember is a very component-driven architecture. And the thing is though, Ember on its own is kind of something that is really good, but actually unlike React and unlike some of the other tools you might have used, Ember actually has a much larger surrounding ecosystem. There's a CLI, a command line interface called Ember CLI, which you can use to build your Ember applications very quickly, and there's also things like Ember data, of course, as well as Ember Inspector, which is a Chrome extension that you can use to debug your Ember applications. So here's just a couple of examples. Ember Fastboot, for instance, does server-side pre-rendering for applications that need to have that initial server-side render. Also, if you saw the session by Ed Faulkner at DrupalCon New Orleans that demoed some of the features of Ember, he was using a library called LiquidFire, which is an animation plugin for Ember. So Ember CLI is basically a tool that allows you to generate these things very quickly, and there's a lot of things that Ember CLI comes with. And I wanna sort of jump into code a little bit, so I'm gonna go through this a little bit more quickly. Ember data, in short, maps client-side models to server-side data, which means that you have a one-to-one correspondence between your models on the client side and the data that's available from the server side. If you're gonna be following along with me as I attempt to write an application live, I highly recommend that you download Ember Inspector because it's a very, very powerful tool, and it's very similar to things like Batarang for Angular or some of the other debug tools that are out there. Obviously, there are some other tools in the stack, as I mentioned. All right, so let's talk about setting up Drupal. And this is something that is very important because we're not actually gonna be using CoreRest. JSON API does build on top of CoreRest, but we're not gonna be using the CoreRest API as you might know it traditionally. By the way, this is Drupal 8.2, so what I'm gonna do is, I've got my Drupal site already set up, right? And what you wanna do is you wanna get the most recent version off of Drupal.org, off of the GitHub, if you so choose. And obviously, you wanna run composer install as you normally do. You can set up a Drupal site locally using Acquia Dev Desktop, and that's something I've done here actually, which is just set up a quick local site using Acquia Dev Desktop. So just to show you very quickly what that looks like, here's my site, and as you can see, it's a pretty standard Drupal site. Now, one of the things that you'll wanna do is to install Drupal, of course, and set up some dependencies that will help us get going really quickly. So if you know Drush, and you're able to very quickly generate some content. One of the things that Drush has, which is a really great feature, is the ability to generate content, generate taxonomy terms, and generate users very quickly using the shorthand that you can see. So I highly recommend that you get that set up. And one of the other things that we'll also need is JSON API. And JSON API will give you all of the things that you need to actually use Drupal as an ember optimized backend. And JSON API actually adds a new format, which is called API JSON. Alrighty, so with that in mind, let's go ahead and move a little forward here. So one of the things that's changed in 8.2 compared to 8.1, is that REST is no longer configured in the REST.settings.yaml file. It's actually now configured through configuration entities, which means that it's much more sort of close to the spirit of Drupal 8's config entity system. And so there's actually an example available within the REST module that you can use as a template. And what you'll see when you open this up, if you have a sort of vanilla installation of Drupal already handy, is you'll see this. You'll see a YAML file which has a whole bunch of stuff. And what you wanna do is we wanna make sure that Drupal is aware of the fact that we're gonna be using a new format called JSON API. And if you look, you can see we've got formats, API underscore JSON, and we're also dealing with nodes. So all of these nodes are going to be available to JSON API, sorry, available, exposed in the JSON API format. We wanna do the same thing as well with users, because ultimately what we wanna do here at the end of this presentation, I would really love to get us to build an application that begins to broach the kind of crud applications that you see often. We're gonna do, we're gonna read content entities through this application, and we're gonna also begin to scratch the surface of creating them as well. We're not gonna necessarily have time, I think, for deleting and updating them. So one of the things that you'll notice now is that if you've gone through all of these steps, and if you've managed to import these configurations, and I'll show you actually where that screen is just so you see it, oops, let's see here, here we go. So this screen right here is one of the ways that you can import configuration entities into Drupal. And so if you paste what I just showed you into this field and submit, you can, oops, sorry, yep, absolutely, is that better? There. So that way you can see all of these things. And let me go back so you can see the URL again in case, oops, in case you would like to note that down. I'll have these slides available as well at the end. So now what you might notice is how many people have worked with Core REST before? So if you've worked with Core REST before, one of the things that is really distinctive about Core REST is that when you make get queries against Core REST, you're not using a namespace usually unless you declare one yourself, unless you define one yourself. JSON API actually assumes that you do this. And what you'll notice is that all of these sort of end points that you see here are actually very different from those in Core REST. But what you'll notice is that when I go over and I look at exactly what those look like, you'll notice that I've got all of my data here in a nice formatted JSON output here. And as you can see, one of the nice things about a JSON API is that it gives it to me in a nice array, which means that I can call all of them at the same time. So that's very useful. One of the last things I wanna note is that if you're building a fully decoupled application with Ember, you wanna make sure to set up cross-origin resource sharing because if not, you're not gonna be able to access the Drupal data through your Ember application. There's opt-in core support in Drupal 8.2. I like to use Sally Young's Core's module, which is a really powerful tool. And if you go into the UI, you'll see that there's a field for you to insert what is available, what paths on the site are available to this decoupled application as well as what that path is. So just to show you what that is, just so for completeness' sake, if you go to configuration and you scroll down to cores, you'll notice that I've already got my domain inserted there. And I've already put in localhost with the port 4200 because that is where our Ember application is going to be located. Alrighty, so don't forget to clear cache, obviously, after you've done all of this setup and gotten things going just in case. All right, how's everybody feeling? Good, good, all right, cool. Are you ready to get into Ember? Yeah, all right, cool. So, writing an Ember application. Let's talk about setting up Ember. One of the things that's really nice about Ember is the CLI. The command line interface is really sweet. It gives you a whole lot of really nice functionality. And I'm gonna actually show you what that looks like right now. So what I'm gonna do right here is I'm gonna actually exit out and let me zoom way in here so you can see this. What I'm gonna do is I'm gonna go ahead and get out of here and create a new project. And I'm gonna call it, let's call it Ember Aclea, which is the Gaelic name for Dublin. Now, if we go into this project, what you'll notice is that we want to go ahead and install a new Ember application. So what we're gonna do is we're actually going to use the Ember CLI and use Ember commands with arguments to actually give us a really nice Ember application. So what I'm gonna do is I'm gonna go ahead and do Ember new, oh wait, I'm sorry, this is, what I should do is this. I should use, so what this'll do actually is this Ember command will actually create a new directory for you right away. So if I'm gonna call my application this, what you'll see is that Ember's gonna generate all of these things and download all these packages. And all of these things are gonna come through and once they come through, you'll see a lot of really cool stuff happen. So while this is going, any questions really quickly about setting up Drupal with JSON API? Questions about JSON API itself while I get going here? Alrighty, any questions about Drupal on the back end side? Any questions about me? Yes. Are you doing this in the thing though? No, so yes, so that's a good question. Normally a lot of people would do the progressively decoupled route, which is where you interpolate a JavaScript framework into an existing Drupal site. What we're doing here is we're gonna be using, we're gonna be going more in the fully decoupled direction and the reason why is because one of the things that's really unique about Ember is that it's really optimized for full page applications. Whereas applications like React, or sorry, frameworks like React, frameworks like Angular are somewhat more well suited, let's say, to using those frameworks in very sort of limited components. You can use Ember in a progressively decoupled setting and actually there are examples of that and I'll show you that towards the end here. But that is one of the things that is flexible about these frameworks, is you can do sort of either direction. This is not happening at the theme level though, I've got two separate domains, one of which is my Drupal site and one of which is my Ember server. So I've got this going now and now let me go ahead and get inside here. And what I'm gonna do is I'm gonna go ahead and boot up this application and it's as simple as saying Ember server. And as you can see what's gonna happen is I'm gonna get a very nice little message that says, hey, go to this port and if I open up a new tab, what you'll see is a very friendly Tomster which is the mascot of Ember saying congratulations, you made it, we're done, we're done. All right, presentation's over, no, just kidding. We've got a long ways to go before we can get stuff going here. So the next step of course is for us to go ahead and begin to do some generation of the components that we'll need for this application. One of the things that Ember does really well is the idea of making things as easy as possible for you to get going quickly which means that if I want to go ahead and really quickly get my application template, all I have to do is type ember generate template application and what that'll do is that'll give me an initial template. So if I go ahead and open up a new window in Adam with this directory in place and I go ahead and zoom in here, right? And I go ahead and open up my app. No, that doesn't zoom in. But if I open up my template and I open this up, right? What you'll see is you'll see this very empty looking thing here which doesn't really have anything but it's given me already the scaffolding for my application on the left side here. And what I'm gonna do now is I'm gonna just give a little bit of a thing that you can see here. So I'm gonna call this doublet Ember and I'm gonna type outlet. Now, outlet is a very important concept in Ember. What outlet does is that if you have templates and you know that you're gonna have templates that are nested within those templates, outlet is where those templates that are nested within will fall. Now I'm gonna save this and if I go back you'll see that, oh, I need to start my server again. Once I start my server again, if I reload this you'll see that my welcome message has been replaced by some HTML. So, okay, I'll get to go but we've got a lot more work to do because ultimately what we wanna do is we wanna get Drupal data to show up on the screen. And the way we're gonna do that is to go ahead and generate a route and a route is one of the sort of quintessential units of Ember. So what I'm gonna do is I'm gonna use the shorthand. You can do Ember G which is the shorthand. I'm gonna say articles because one of the things I wanna do first is get a list of articles from Drupal. Now if I go ahead and just say that, what you'll see is it's created a route.js file. It's created the handlebars template that I'm gonna need. It's added the route to the router and then finally it's created a test. I'm not gonna be covering tests today but what you'll see now is if I go in here I've got all of a sudden this additional template that just showed up magically and all I had to do was type one command. Now what I'm gonna do here is I'm gonna go ahead and replace this just with some filler text. Let's just say list of articles. Now if I save that and I go ahead and restart my server what you'll see is that the outlet concept makes sense. Because if I go back to my browser and I refresh you've got this homepage. When I navigate to the route you'll see that I have the header which is the main template and underneath that template I now have an additional header from my articles route. Does that make sense? Alrighty, now the other important concept here is that now I need to give it some data but the thing is I'm not quite ready to connect this to Drupal quite yet. So what I'm gonna do is I'm gonna go ahead and open up one of these routes. And as you can see Ember makes a very strong use of ES6, ES6 is the sort of emerging new standard of JavaScript, it uses ES6 modules, it uses ES6 things of that nature. And I'll actually show you some syntax that you might find unfamiliar. How many people have written ES6? Okay, wow, awesome, this is good then. But JavaScript people have written, right? Okay, good, just checking. So what I'm gonna do now is I'm gonna go ahead and provide a model to this route. What that means is that I have now a template for my route, I have my articles page. But I don't have anything that's on there, I don't have any data there, right? I need to provide it some data. So what I'm gonna do is I'm gonna actually do this. And what you'll notice is that this might be unfamiliar to you because this syntax is actually the same thing as saying this in regular JavaScript. ES6 has actually gotten rid of the need to do this and you no longer need to have an additional anonymous function when you declare a method like this. It's called a model hook. And model hooks in Ember are very important because anytime you have a route, the model hook is gonna be what provides the data to that route. So what I'm gonna do here is I'm gonna provide just some filler data here. So I'm gonna go ahead and say article number one, article number two, and article number three. And as you can see, I've just created an array within JavaScript, which is just gonna give me just a little set of data that I can work with, right? Now, the next thing that I wanna do is to talk a little bit about components. Components, as I mentioned before, are nestable, reusable items that you can put into templates, right? And what you'll see is if I go ahead and I exit out of my server, shut down my server, and I generate a component. And in this case, I'm gonna call it entity lists. Now, I do wanna make a couple of notes here. Ember components by rule must have a hyphen. And the reason why is because the HTML custom elements standard states that all custom elements must be namespaced with a hyphen as well. So that's one of the ways that Ember is forward looking and anticipating the trends of where HTML is headed. I've called it entity lists because we're not just talking about nodes here. We're talking about content entities in general. As you may know in Drupal 8, rest, you are able to perform product operations on all content entities, which means nodes, users, and taxonomy terms. So I called it entity lists because I want it to be something generic. Now, what I'm gonna do is I'm gonna go back, and as you can see, already, I've got an additional components file here. If I open that up, once again, I've got this shell. And this is the really powerful thing about Ember CLI, it gives you this nice shell that you can really quickly work with. What I'm gonna do is I'm gonna use the components template over here. And I'm gonna go ahead and put in some information. So what I'm gonna do is I'm gonna say, well, if I go back to my articles template, you can see that I've got my list of articles here. And what I'm gonna do very quickly just to show you what's happening here is I'm gonna put in a loop here. And what this does is it gives you each of the articles in that list. Come on, Adam. Sometimes Adam is great, sometimes it's not so great. And just bear with me here because what you'll see once I reboot the server is, let me go back to the previous screen here. And what you'll see is when I actually navigate to slash articles, you'll see that array that I provided through that model hook is being iterated over and now gives me a list of articles. Now you're probably thinking to yourself, this is really, this is so simple, this is so crummy. Well, what's powerful here is that I wanna generalize this template to be usable with all different content entities. So what I'm gonna do is I'm gonna actually copy this template and I'm gonna put it over here. What I'm gonna do is I'm gonna say, well, let's give it a title. And I'll explain very shortly what this means when I say title in these double curly braces. Finally, what I'm gonna do is I'm gonna say, well, this has to be a bit more generic. So I'm gonna say, let me call it entities and entity and I'll show you exactly what's going on here. Right, oops, entity. Now, what you'll see is that when I actually go back to my article template, I'm going to actually invoke this component. And the way I'm gonna do it is I'm going to refer to it in much the same way that you would refer to an HTML custom element. Meaning, I'm gonna say, give me an entity list and I'm gonna provide it some arguments. I'm gonna say title, list of articles, and I'm gonna say entities equals model. Now, what I'm doing here is that within this indication of this component, I'm actually providing information to it. So if I go back to the screen, you'll see that entities is actually referring back to the argument that I provided here. Title is also referring back to the argument that I provided here. And this is the way that I've been able to generalize this and what'll happen is when I actually refresh this, nothing changes because what I've done is I've just abstracted out that component. And so what I can do now actually is I can do some really cool stuff. What I can do is I can generate a couple new nodes. But just before that, let me go ahead and make this a little bit more pretty. We wanna make sure that there's a little bit more of stuff that you can see here. So I'm just gonna add a couple of things just for us. Just so it's a little bit better. And what'll happen is this will be providing more of an application shell for us. And I wanna provide a navigation bar as well. So the link to handlebars element is something that you can use very easily. And what I'm gonna do is I'm gonna go ahead and shell out my application like this. I'm gonna say I wanna have links to not only articles, but I wanna have links to pages too. You know, the basic page, content type and Drupal. So let's say pages. And then I'm also gonna get a list of users. Now, the thing is what's important to realize is that we haven't actually created these routes yet. So when I try to click on these links, it's gonna give me an error. But what I can do now, right, is if, oops, I'm sorry, I just opened up Safari. Okay, good. Now I wanna go back to the homepage. You'll see, I should have, let's see here. I should be getting here. So I'm just gonna show you very quickly what Ember Inspector looks like. What you can see here is there's some really cool, and nice little features. You can do things like track your promises. Let me see if I can zoom in on this actually. There we go. You can have a view tree. You've got your routes all recorded there. You can have all of your data. You can browse through your data. You can also track all of your promises. And then also do things like performance tracking as well. So that's very cool. Now, one of the things that I wanna make sure to do now is to create some routes, right? Because we wanna make sure that there's some availability in these routes. And also make sure to provide the outlet for those templates that are nested within. So what I'm gonna do is I'm gonna very quickly generate a couple of routes here. I'm gonna say ember generate route pages, right? To match the route, the link that we've just added. And so ember's gonna give me that new route. I'm gonna say give me a page for the users as well, right? And what'll happen now is you'll see that I've got some new handlebars templates. Now what I'm gonna do is I'm gonna go ahead and take this, right? I'm gonna take all of this, and I'm just gonna put it over here. And instead of saying outlet because there's no further templates that are lower, right? I'm gonna say, okay, let me make these pages, this list of pages here using that same component and the same thing with the users as well, right? Now what's gonna happen next is I need to provide some data now as well, right? So I really wish there was a way to zoom in on this left side here. Gosh, that's really bad. But what'll happen is if I go to my routes, right? What you'll remember is back in my article route, right? You'll see that I've got my three, those three items there. I'm just gonna take this same stuff and I'm gonna go ahead and go to my already generated, my pre-generated route and replace these model hooks with something different, right? So I've got that. Now let me do the same thing with users. And you can see how this becomes very quick. This kind of development is actually very easy and very quick. Now if I go ahead and boot up my server again, what you'll see is I've got my Ember application here. And what'll happen is if I zoom out just a little bit, when I click on articles, there's my three articles. When I click on pages, there's my three pages. And when I click on users, there's my three users. Now the thing that's important to keep in mind here is all of this is happening dynamically, right? The route in the top URL bar is changing to slash articles, slash pages and slash users automatically. And these changes in the DOM are also happening dynamically, which means that there is never a full page refresh happening while I'm doing this. So no matter where I click, no matter what I do, I'm never ever getting a full page refresh, right? Okay, so that's cool. But what's next? What's missing? Well, now we gotta get some data in there, right? And we gotta get some real data, because this dummy data isn't really helpful. So what I'm gonna do now is I'm gonna go ahead and generate a model. And as you can see, Ember CLI does a lot of generation. And what I'm gonna do is I'm gonna say model, node hyphen hyphen page, and you're probably wondering, what exactly do you mean by node hyphen hyphen page? Well, if you go back, if you remember, if we go back all the way to the JSON output, what you might remember here is that we have a type that's declared with each resource. And this type is actually what the JSON API adapter, which I'll cover shortly in Ember, uses to know what type of data it's dealing with in the model. And so what'll happen is when I create, when I generate these three models, right, I'm gonna go ahead and create one for article. So this is entity type and bundle. Now I've got that. And then finally one for users. And one note to make about users is that users don't have bundles. And in the JSON API module in Drupal 8 currently, what you do is you just use the same entity type name when you're referring to the bundle as well. All right, so now if I open up my models folder, you'll see I've got some three different models here. Now if I go back to this JSON output again, what you might notice is you might notice this attributes section here. And I might wanna get some data out of there that I wanna display in my Ember application. Like things like the node ID, maybe the UID, definitely the title for sure. And maybe the change timestamp, right? And perhaps the body. So what I'm gonna do is I'm gonna scaffold this out within my model. I'm gonna go back to my articles model, sorry, my articles route, right? And I'm gonna think about what exactly is the data that I want. Now if I go to my article model, and once again it's been generated for me in this nice modular format, what I can do is within here I can say, well what I want is I want the node ID, I want the UID, I want the title, I want the created timestamp, and finally I want the body. Now you might be wondering to yourself, okay, well what about the fact that if you go back, the value of the body is actually nested within. What JSON API adapter in Ember does is really smart. It actually goes ahead and goes down into the tree and digs up all of those nested attributes, and actually makes them available to you automatically. Now you might be wondering what this .attr method is. The attr method is helpful for you if you wanna potentially serialize something differently. So let's say you have an NID, but you actually want that to be a string instead of an integer or vice versa, then you can put in here a string and it'll be converted into a string. So that's one use for this, and if you check the documentation on Ember, you'll see this actually take form. Now I'm gonna go ahead and copy this over to my page as well. Oops, so I've got my page now. Now the users however are gonna be a little different, right? Now if I go back and I go ahead and look up the correct resource here, you'll see that there's different information, right? I don't have a body, I have all of my information here. I've got also my hashed password here and my email. Now what I'm gonna do is I'm gonna go ahead and just get the UID, and once again this is very easy, because I'm gonna get the UID as well. I'm gonna go ahead and get the name of the user. I'm gonna get the email of the user. Now, oops, now what's gonna happen now is we've got some models, right? But this doesn't help because right now this model is not able to see what's on the Drupal site. So we need to connect these models to Drupal, and Ember has a concept called an adapter, and what an adapter basically is, is an abstraction that helps you make XHRs, XAML HTTP requests, against the back end of your choice. And there's different kinds of adapters available. There's a REST adapter that's more generic, and of course there's the default adapter, which is the JSON API adapter. Now, once again, I'm gonna generate an adapter. And what I'm gonna do is I'm gonna go ahead and say, give me an adapter that's gonna just stretch across my entire application rather than just a single portion, because you can actually differentiate adapters based on what route, what component, it's very flexible. But for the purposes of this, I'm gonna go ahead and just stick with one single adapter for my entire application. Now, what's gonna happen here is if I open that up, you'll see that once again I've got a generated modular output here, which is really nice. And the JSON API adapter with an Ember data actually gives you some options that you can set. One of them, for instance, is the host. So this is where we finally connect our Drupal back end to our Ember front end. What I'm gonna do is I'm gonna go ahead and say that this is the host, and the namespace is under API. Now, if I save this, right, what'll happen is you'll see that there's stuff happening. You'll see that this is now connected. But when I actually go back and refresh, I'm still gonna get the same data that you see here. And I'll explain why, right? So if I refresh here and I refresh the user's page, I'm still getting the same ones, right? There's something missing, and that's the model hook. I haven't actually gone back into my routes and changed this model hook, right? What I need to do is I need to access the data store, which in turn accesses the adapter in Ember. What I'm gonna do here is I'm gonna say, return this.get from the store in Ember. I'm gonna just get all of the data of this type. And what I'm doing here is I'm specifically looking for those entities that have this type. And what'll happen is you'll see that all of these things are working, right? And then I'll go over to pages and do the same thing. So I'll go over here and say, find all of my page, and then finally, I'll go to my users and do the same thing there. And you can see how this is something that you can repeat pretty easily. All right, now, we should be good to go, right? I think we're good to go. I think we're good, right? I think we're good, right? Oh, well, well, maybe not, huh? Oh, oh no, there's something missing. Well, believe it or not, the problem here is that Ember actually assumes almost too much. Ember assumes that you want a particular kind of path that your JSON API is built in a particular way. So if you look here, you can see that it's assuming that my user type and bundle pair is actually the name of the resource and actually the way that you get to it. And what's really funny is that if I go back to my recent log here and I refresh the page, what you'll see is there's actually a 404 error because Ember has assumed too much. So there's a problem here. Our app isn't working. We have the models, we have everything in place, but our app's not working. So what we have to do is we actually have to customize our adapter. And what that does is it helps us to connect much more seamlessly with our Drupal site. Now the way I'm gonna do that is I'm gonna go back to my adapter. And as you can see, there's really limited options. I've got the host, I've got the namespace, but nothing else. And what I'm gonna do here is I'm gonna go ahead and actually change the way that the type information gets passed on to the backend in terms of the request. What I'm gonna do is I'm gonna say path for type, which is a property that helps you override some of these things. And I've got the type argument that comes in. So this is the user of dash dash user node dash dash type. I'm gonna go in here and I'm gonna go ahead and actually do a little bit of quick changing around of these things. So I'm gonna use the let keyword, which is a new keyword in ES6. And the difference between var and let is that let will actually limit it, limit the scope of that variable to the block that it's in. Which means that it's scoped tightly and won't escape. Whereas var is just scoped to the surrounding function. So what I'm gonna do now is I'm gonna go ahead and do a detection of this type. And I'm gonna say, hey, if it's user hyphen hyphen user, well, the thing is, right, what actually needs to happen is that if I go back to my path and I look at where it's coming from, it's user slash user, it's not user dash dash user, it's user slash user, right? So I'm gonna do a little bit of rewriting here. And what I'm gonna do is I'm gonna say, okay, well, if that's the case, let me go ahead and say entity type, instead it's gonna be user slash user, right? Do the same thing with node page, node slash page. And you'll see this if you actually look at the, and I'm gonna actually go ahead and just make this a default. Now, okay, so that's all good, that's all good to go. And the thing that's missing now is to go ahead and return the correct path. Now, one thing that you might have noticed is that Drupal 8's REST uses a query parameter string to dictate the format. Unfortunately, Ember doesn't necessarily know that, right? And this is one of the cases where we have to bring Drupal and Ember closer together. So what I'm gonna do is I'm gonna actually append this to the end of the string. And so the way I'm gonna do that is I'm gonna say, well, when you actually return the correct type that the adapter's gonna use to fetch this information, I'm gonna go ahead and get the entity type, which is one of these things, plus the format that we're using here, right? Now, that's our adapter. We've customized it to recognize Drupal. And what'll happen is if I go ahead and make sure that this is now back to normal, you'll see that I now have a nice list of all my users. I've got my UID showing up. I've got all of these things showing up. Now, you might be wondering, why does it look so weird? Well, the reason why it looks so weird is because we haven't actually accessed any of the attributes within. And that's our next step. So as you can see, we've got data coming in now. And this data is coming from Drupal. Pretty awesome, right? That's pretty cool. All right, so now what I'm gonna do is I'm gonna go back to my templates and I'm gonna go ahead and replace these templates with things that are actually going to work. So what I'm gonna do is I'm gonna go back to my components, sorry, to my templates here. And I'm gonna replace this component with this, which is a list of articles, right? I'm gonna say, go through and iterate over the model, right? Which we declared in that model hook. And make the name of this, of each iteration, article. I'm gonna say, give me the article title. And those of you who have worked with Twig might be seeing some familiar stuff here. I'm gonna say, give me the node ID. Oops. I'm gonna say, give me the UID. Give me the created timestamp. And finally, go ahead and give me the body. Now remember what I said earlier about the fact that the value of the body is nested within the body, right? Well, we can just do that. And Ember already knows what to do. All right, in the interest of time, I'm going to go ahead and show you what this looks like right now. And if I go ahead and refresh, you can see I've got a nice list of all of my articles that have been exposed through Drupal and have been ingested by Ember. And I can do the same exact thing, right? When it comes to my other templates here. So I can do the same thing with pages, right? So I say pages, page, page, page, page, page. And then also for users. But users obviously is a little different, right? Because we decided to actually use name instead and we're actually gonna be calling it, we're actually gonna be using UID. We're gonna be using, oh sorry, we're gonna be using UID here, user here. And then we're gonna be using the email, right? All right, and nothing else. Now, what you'll see is when I actually go back and I've rewritten my templates. Oh, I missed one thing, which is this. There you go. Now, nice, right? Let me zoom out just one little step here so you can see. Now if I go through and I look, I've got every single user recorded. I've got every single page from my Drupal site now available. I've got every single article from my Drupal site coming out into my Ember application. So that's awesome, right? It's pretty cool. Now, because we only have nine minutes left, I don't think I'm gonna be able to get to the creation aspect just because I think that it's important that I save some time for questions. But what I will do is in the slides at the end, and all of this information by the way is recorded in the slides. I'm gonna have all of that information there. But what I wanna do is I wanna sort of take a step back. I've shown you some very nitty-gritty stuff. And I've shown you just a little bit of how you can do crowd operations, create, read, update, delete. We didn't get to creation, but you'll see that once the slides are up. I wanna actually get a little bit into the big picture here, right? Why is this model so compelling, right? Why are people so enamored with JavaScript frameworks? And why is it that we have these kinds of interactions here are very compelling, right? And you'll notice that I didn't style it. But if I had styled it, you'll see that it's a very nice, fluid, seamless experience. So there's a blog post that Dries recently wrote called, can Drupal outdo native applications? And it's a very interesting blog post in my opinion because it really digs into what do we want Drupal to be? What do we want the user experience of Drupal to look like? And if you've been following along with any of the sort of presentations I've given lately or more of the decouple talks I've given, you'll know that I've been talking a lot about how our front end and our back end can work together in a way that may not be traditional, may not be monolithic. One of the things that we saw recently is at DrupalCon, New Orleans, Ed Faulkner, who's one of the core maintainers of the Ember framework, visited DrupalCon and gave a presentation about how we can actually make Drupal more native and actually make Drupal and Ember work in tandem to provide a really interesting user experience. What you're seeing here is Drupal.com, which is our sort of our commercial site. And this is using the liquid fire plugin in Ember. And what you'll notice is that the route here is changing. The path in the URL bar is changing, but there's no full page refresh, right? And when you click on the thumbnail here for Red Hat, it actually takes you to that page in a very seamless animation, which isn't currently possible in Drupal. What's more? Well, there's also this idea of editorial experiences which have a very similar user experience as well. This is the card stack editor, which is something that Ed has been working on for a client that is using Drupal on the back end, but solely Ember on the front end. What's unique about this approach is that this is Ember fully decoupled from Drupal, which means that there's no Drupal front end logic happening here, no twig, no PHP template, none of that. It's all handlebars, it's all Ember. And what you'll notice here is that this editorial interface that they've written, which uses JSON API by the way, and connects with Drupal and makes all of these interactions with Drupal, it's something that's fully integrated into the context and into the preview of the site. Now, the difference here is that the editorial interface and the site are both rendered in Ember. And they're also both rendered together here. So as we think about some of these outside end improvements that have been happening in Drupal, and we think about some of the new improvements that have been happening, one of the things that I've always thought about is how quickly can we advance our user experience? And one of the ways that we can, just to go back to the presentation here, is through what's called inversion of control. Inversion of control is a very important concept in which rather than the server side dictating application state, right? Early in the 90s, mid 90s, even up to the early 2000s, all application state was driven through full page refreshes, right? You would fetch a new page from the server and that would be the new state of your application. With the JavaScript Renaissance, that's really changed and that paradigm has been completely overturned. What we now see is inversion of control, where the client side actually controls all of the state. The client side is what initiates all of the actions. And the client side is what actually manages all the communication with the server. So I wanna end here briefly with just a little bit of my own perspective. And some of you may have heard of the work I've been doing around JavaScript frameworks in Drupal. Some of you might have also heard of some of the debate that's been going on about Node.js. Our world is changing very quickly and one of the things that we've seen in Drupal 8 is a wholesale revolution in the back end. Symphony, composer, these things are really amazing for the future of Drupal. What we haven't really seen is a concomitant revolution in the front end. We're still using our Ajax framework that we've had for years. We're still using our behavior system that we've had for years. We're still using Backbone, which we've had for quite some time, and we're still using jQuery. And if you're thinking to yourself, how can I make these same interactions happen in a Drupal site? The short answer is it's not so easy. And what I'm about to say is gonna be a bit controversial. But in my opinion, I believe that the way that we can move Drupal forward in terms of attracting new developers, improving our user experience to a phenomenal degree, and improving our developer experience as well on the front end. Because I mean, how many of us have used the Ajax framework in Drupal and the behavior system? It can be kind of a pain, right? Right, I mean, so as you can see, the developer experience of Ember is great, right? But one of the things that you might have noticed is that Ember is really well suited to these kind of full scale applications, these full page applications, right? Rather than sort of small components on the front end. It's my opinion that what kind of future I would like to see for Drupal is a future where Drupal is decoupled out of the box. It's a future where you have the backend of Drupal managing all of the data, the exposure of that data, you have a great API for CMS. And on the front end, you have a very powerful, very powerful UI, admin UI, and end user experience coupled together. How many people have heard of WordPress Calypso? So WordPress Calypso is a fully decoupled, single page React application that was made by WordPress to improve their user experience in a very interesting way. But I think that, in this case, the WordPress, the automatic folks, they've done a really good job with Calypso. It's very impressive, but they've made a really big miscalculation. If you open up WordPress Calypso and you begin to interact with it, what you'll notice is that it's just another series of forms. It's just another series of fields, you know? You're not actually able to get the preview and the context, because that's all still in WordPress PHP land. The difference with CartStack Editor and the difference with the approach that I'm recommending to you guys all today is that if we compare the admin UI with the end user experience, what the end user sees, and we provide that context to the user, provide those outside and improvements in a way that makes a lot of sense, that will actually advance things very rapidly and the user experience will be great because we all know clients, we all know editors who want to be able to see their headlines as they're typing them in the context of the site as they're typing it into the field. And that's something that we can't necessarily do today. That's something that outside end points toward. And I just wanna end here with one brief comment, which is that someone said to me, I was at mid-camp last year and I had a conversation about some of these things, some of these issues. And I mentioned that I had a lot of qualms about this. There's a lot of issues here. If we decouple Drupal out of the box, if we have a JavaScript front end and a Drupal back end, we have two separate stacks. We have Node.js, we have Lamp, we have all sorts of problems. And we also have a community, which thrives on this very close relationship between the front end and the back end. And he said something very interesting to me, which I've kept in mind up to this day and I've still really thought about a lot, which is Drupal isn't a software project. Drupal isn't a single software project. Drupal is a community. Drupal is an ecosystem. And it's my conviction, and it's my job over the next year or so to convince all of you that we can still be Drupal, even with Ember on the front and Node.js powering that UI. We can still be Drupal with just an API-first repository on the back end in PHP and in a Lamp stack. We can be all of that and still call that Drupal. And what'll happen is we'll get a whole new interesting set of ideas, a whole new interesting set of interesting get-off-the-island techniques that we can think about. And I think that that's the way that we'll guarantee a really long-term and exciting, amazing future for Drupal. Thank you. I think I have time for maybe a couple of questions. Yes. And there's a mic over here, by the way, as well, if you'd like to. But I'll also repeat. Yeah, sure. Sure, that's a great question. So the question was, where is SEO right now? These client-side libraries are really great for those interactions, but SEO is a big issue. So what's the current state? Right now, SEO is actually in a very interesting state when it comes to JavaScript, because in the past, about two or three years ago, you used to have services such as pre-render.io, which would spit out a server-side pre-rendered version of your page or of your site for indexing by search engines. In the last 12 to 18 months, I'm not sure exactly what the time frame was, but Google recently announced that they will execute JavaScript on all pages that they come across while indexing, which means that even if you have a page that is entirely driven by JavaScript, Google, while it's indexing your site, will access all of that content because it will execute that JavaScript before actually crawling. Well, so there's a couple of solutions. Well, there's one big answer to that question, and that is that Ember and all of the other major JavaScript frameworks have server-side pre-rendering available. Ember has Fastboot, Angular has that built in as well, React obviously has, the name escapes me right now, but React also has a pre-rendering service as well. What that means is that you can mitigate that, even if let's say DuckDuckGo or Yahoo or what have you doesn't actually execute JavaScript, it will actually give you that initial server-side render such that you're not gonna have a blank page when you search for that term. Now, on the other side of it, I think that it's still kind of in flux. Google has really bought into, I would say, the JavaScript execution pattern of indexing. I'm not really aware of what's happening on the other search engines, but my sort of initial conviction right now is that I'm a strong believer in the notion that pretty much it will not be something that is a problem in the near future, yes. Two questions, would you please share the code as well, not only the slides, but also the code? Yes, absolutely, I'll have a repository available on my GitHub account. Thanks, second question is, what is your experience with this technology related to accessibility, for example, screen readers? Sure, that's a great question. So accessibility is a major concern. I actually, you know, I come from a UX background originally, and one of my passions has long been accessibility. So what I will say about accessibility is that all of the major frameworks, and I'm gonna talk generally about all these frameworks, all of them actually do have solutions for accessibility. Angular, for instance, has the ability to, you know, declare different versions of content, for example. I know that Ember and React also have the same within their ecosystem. The interesting thing about this, though, is that, honestly, accessibility has to come from the ground up, in my opinion. Accessibility is something that's not, that you don't get for free, right? Drupal, with Drupal, you do get it for free, but that's only because of years upon years of this, you know, phenomenal experience that we've had, phenomenal advocates of accessibility that we've had in the community. But, you know, these JavaScript frameworks are still a little bit immature in that realm, but I think more importantly, you know, a lot of the people that you see building these applications aren't necessarily the best at writing markup. And, you know, obviously this presentation that I gave and the code that I've written, you know, is very rough and is not, you know, nothing that I would say would pass the WCAG guidelines by any means. But what I think is more important is actually a paradigm shift in how we think about markup. You know, one of my biggest fears about the JavaScript Renaissance and the way things have been moving is that we're entering a period of another wild west, you know, like just like the browser wars, where we had all sorts of crazy markup, you know, we were using really disgusting CSS properties and really disgusting ways of doing layout. I think that we're almost, we're close to entering that once again, because a lot of these people that I, you know, that are building these applications don't necessarily have a good grasp on alt tags, for instance, which is, you know, which is really obvious, or, you know, don't have those kinds of problems. However, what I will say is that every framework, if you go to the sites of all the frameworks, they do have an entire section dedicated in their documentation to accessibility and making sure that Tab Index still works, making sure that, you know, screen readers can still read content. And I know that there's a lot of people who are working on that. One of my friends actually is at Facebook working on accessibility and has done work on React. So, I think that's something that is evolving, but is coming very well. Yep. Hello, yeah, just a kind of few points to lead on. One is, like you say, with components abstracted, you get the same with content, images, all kinds of things. The way we're working at the moment, inline editing, inline dashboards don't work so well, because you edit one thing, it will have a ripple effect throughout the site. And I guess that kind of leads on to, there are quite a lot of group or modules, panels out there, as Drew showed yesterday, the sidebar, whatever you call it. The setting stray. The setting stray. All of which are kind of moving in this direction, but you kind of have a lot of editors still who will need a full admin separated UI. Yeah. And the idea of building that completely in Ember as well would be quite a challenge, I guess. Sure, yeah, and by the way, this is meant to be, this is like what I just expressed is long term. I mean, I'm not saying that we're gonna, that we should do this in the next six months, but that's a really good point. And I think what's important to keep in mind is that we have different content needs, right? We have different places that content is going to, different touch points, we have IoT applications, we have native mobile applications, we have Roku applications, set top boxes, where you don't even have access to a visual interface, right? So in my personal opinion is that you should have both. You should have both the option to, if you're gonna build a web experience for your end user, then yes, absolutely, you can use that setting stray. But you should also have the option not to, because there's so many other experiences of content which aren't gonna have that benefit of that in context in preview advantage. So that's my thinking around the topic. I think that Drupal has always prided itself on flexibility, Drupal has always prided itself on versatility, and I think that discarding, let's say the paradigm that we've been working with all the way up until now is a big mistake, right? We have to have both, so, yes. So the question was, is there a Drupal Ember boilerplate? So I've noticed actually that there are fewer people in the Drupal community who've played around with Ember than with Angular and React. There is one GitHub project that I can highlight right now because it's up here right now. Ed Faulkner, in the process of writing this presentation that you saw at New Orleans, has written this sort of module for Drupal, which will interpolate Ember into your module, sorry, into your Drupal site. What I haven't seen so much of actually is Ember Drupal boilerplates. A lot of the ones I've seen are reliant on Ember 1.0 rather than 2.0, which is the current version of Ember. But it's my hope that with this code that I'm gonna put up, that'll be a good start. Because I think what's now missing is the fully decoupled element. We've got a great module that you can use thanks to add for progressive decoupling and what about for those fully decoupled experiences. Anyways, so I just wanna say one last thing, which is that I think that user experience is a field that's moving very rapidly. And it's my firm belief that in the next 12 months, in the next 12 months, the next 12 to 24 months, it's gonna be kind of anathema. It's gonna be kind of ridiculous for good use experience to have full page refreshes. And that's really where this stuff comes in. And I highly encourage you to think about these issues. If you'd like to email me and get in touch, I'm more than happy to talk about these issues and think about solutions moving forward. And together we can make sure that Drupal is a great UX, a great DX, a great everything X for the next 20, 50, 100, 200 years. Thank you.