 Alright, good morning everyone, so we're here to talk about AngularJS with Drupal 8. First of all, yeah, I know, I'm excited too. So let me introduce myself. My name is Travis Tidwell. I've been working with Drupal for almost 10 years now, so back when it was like Drupal 4. I have a lot of community modules that I've offered, one of them was Media Front, so that's probably one of the bigger modules that I have. Lately I've really been getting into AngularJS and I felt like it's extremely relevant to Drupal's future, so that's why I'd like to talk about it. So thank you guys for coming. Just to give a little bit of introductions, I've already introduced myself, Travis Tidwell. I'm the CTO of a new company that I'll talk a little bit over called FormIO. My Twitter handle is SoftwareNome. Where I spend, I don't spend much time on Twitter, so don't expect much out of me. I'll tweet every now and then. Where I really spend most of my time is on GitHub, and so you guys can see my GitHub name there. It's Travis T at GitHub, and I've got a lot of open source contributions that some of you guys may have found valuable and you're welcome to use them. So before we begin, I would like to just give a little bit of an introduction as to the company I started, and we have a team of people working on it now. This is FormIO, and essentially what we're trying to accomplish here is we are providing developers this easy drag and drop interface that allows you to create both forms and RESTful APIs at the same time. So the whole idea is you can create APIs using forms, and so we try to make it real easy to build the forms and then provide an AngularJS directive to immediately embed those forms into your application, and they just come alive. It's form plus IO, that's where we get the name, FormIO. You build the app, we handle the FormIO. Another thing I will let you know is we're in private beta right now, which means you can try it out, but you have to have these beta codes. So we're handing out these thumb drives that has the beta code on it, and it also has a walk through tutorial on how to use it. So if this sounds like something that you guys may be interested in, come see me after the presentation and we'd be happy to give you guys some beta codes. So let's jump into AngularJS. Oh, actually before, another thing I also like to do is I like to give all the presentation materials online. So you guys, if you wanted to, you could follow through on your laptop. This projector is not the brightest projector in the world, so if you have a hard time reading it, it may actually be beneficial to just load up the presentation on your local browser and you can kind of walk along with me. So that's travestidwell.com forward slash presentations, forward slash Drupal dash Angular if you guys want to follow along with me. You can also look at it on GitHub. I have a presentations repo and this is inside the Drupal Angular folder inside the presentations. Also, the AngularJS app is the app folder inside of that. So whenever I show you guys the app that we're going to build, all of the source code is provided for you guys, so you guys can try it out. So before we begin, I'd kind of like to get a little philosophical and talk about why would you want to use AngularJS? And AngularJS is one of those things where, you know, and I know a lot of developers do it. I do it myself. You always want to use the technology like what all the cool kids are doing, right? AngularJS has that feel, you know, you learn it, you buy some skinny jeans and thick rim glasses afterward because now you're one of the cool kids. And a lot of people use it for that reason, it's just because, hey, this is cool and I want to use it, so therefore I'm going to. But the way I like to see AngularJS, in fact what I'd like to talk about is I believe Angular represents something way more to Drupal than a lot of people realize. And not necessarily just AngularJS, there's a lot of technologies like it. There's AngularJS, there's React, which is a fantastic front-end framework, EmberJS. All of these frameworks represent something that is new to Drupal. And in my opinion, Drupal's future very much depends on these technologies because the web is changing and these technologies represent that change and how to deal with it. In order to really dive into it though and understand why I feel AngularJS is so important to Drupal, I'd like to kind of just take a step back and just talk about how the web has evolved to get to where we are today because it's real important to understand how we are today in relation to five years ago and why today, the way we build apps today is so differently, so different. And in order to really capture that context, let's just take a trip through memory lane, if you will, of the web. So everyone probably remembers back to web 1.0 and web 1.0 was really the static web. And the way this worked was every browser, a user would go and they would type in the URL that would go over this little cloud, this internet. It would hit a server and it was a one to one connection based on here's a page I want to request, the server that would then hand that page to the person and it was a static HTML file and everyone thought it was wonderful. This was a static web, it was a very brochure oriented web ecosystem. What a lot of people then realized is that from the server perspective, we have these requests coming in and I'm handing it back a page. I could actually intercept that request and do some other cool stuff and dynamically present a page to the user so they feel they're visiting a static website, but really, it's a page that's constructed via scripting languages. And this was the rise of web 2.0, which was the dynamic web where PHP really kind of rose from this as this really easy language to dynamically generate content. The important thing I really would like to point out here is the flow of traffic and what people are actually doing. So you have a user who hits the internet that hits the server. And then the server gives the user the interface to the browser. And that's the key that I want you guys to take away from this, is that the server is still handing the user the app that they interface with. And this all came about with web 2.0. And from this, a lot of people realized that we can build these tools that make it real easy for developers. So you don't have to learn how to write code in order to build these dynamic websites. And this really from that came the rise of these CMSs, Drupal WordPress, Joomla, they realized we're going to make it easy for developers. We're going to make it so you don't have to know how to code in order to deliver this content. So essentially what the user has at this point is a very dynamic web. They can create content, they can comment, they can do all of these things. But another really big takeaway is even in this world, the user is requesting the interface from the server. And the web is changing in a way to where I feel like that whole paradigm is actually flipping. And apps have to be made differently. And in my opinion, it has a great amount of consequence onto Drupal and what Drupal is for and how it is used as a developer. And all of this is sparked by Web 3.0, which I lovingly like to call the rise of the machines. So Web 3.0 is about we no longer have browsers hitting our servers anymore. We have a multitude of devices that we need to handle now. And so you have the, of course, still websites, people still use the browsers. But now people are using their phones. We have the watches that are coming out. We have eyeglasses, even Nest thermostats or your refrigerator. All of these devices are now connecting to the server and our servers have to adapt to that type of traffic. So if you think about it, we no longer have to cater our websites or our web systems to humans. Websites were based on this notion that humans would be the ones interacting with the server and that's not the case anymore. For every human, you may actually have five devices and each device is hitting the server five times as fast as a human ever could. So you have this massive concurrency issue where all these devices hitting the server and you also have to adapt the software so that they all communicate via this API, which this is a big word nowadays, this word API, application programming interface. And that's kind of this common language that all these devices connect to. And it's extremely relevant to Drupal. In fact, Drupal has made massive strides with the latest release of Drupal to address this. So Drupal 8 solves this problem through the use of every single request. And I know that those little boxes are very small. But what those represent is that every single device, when it sends a request to the server, it attaches in the header of that request what format it accepts. And it's called the accepts header. And Drupal 8 does something really clever. It looks at that header and it determines how it's going to respond to that device based on what that device says. Hey, here's my header. I accept JSON or I accept HTML and Drupal just knows how to handle it. And if it accepts JSON, it delivers JSON content. And if it's HTML, it delivers HTML content. And this is really fantastic the way that this works. In fact, now we can kind of see where Drupal's headed here. Drupal still is this hub, if you would, of all of these devices. In fact, Drupal kind of classifies itself as a hub. Hey, if you want any feature in any of these devices, we have a module for that. Everyone knows whenever you hear about Drupal all these modules that you can enable to add those capabilities. And you probably have also seen this graphic, which I think this was in Dries' keynote presentation last year, where he says, you know, this is kind of where Drupal is headed. We become this hub. So if you want any type of capabilities being added to these devices, all you have to do is enable that module in Drupal and it will expose those capabilities. And for example, if you want to do Google Maps, all you have to do is enable the Google Maps module. And now suddenly you have this mapping capability for websites, but it also potentially has mapping capabilities for the devices. I would like to challenge us a little bit and think about this. Because what I'd like to challenge us is, is this the right approach? Should Drupal be this hub where all the devices connect to Drupal and that's how they come alive? And I think this challenge is what AngularJS is bringing to the table for Drupal right now. It's changing the paradigm on how apps are being built. And not necessarily to say that this is incorrect, but I would like to challenge us and just think about it. Drupal does not have to be the hub anymore. If you want to enable features in your applications, applications now control their own destiny. And Drupal can just be a piece of the app. And the app can connect to other services. So just to give you an example, the way that we used to do it is we used to build a Drupal website. And if you wanted mapping capabilities in your website, you were told to go to download the Drupal map, whatever mapping module, and enable it. And poof, you have mapping capabilities. And so now people who want this type of capabilities, they're now dependent on a contrib module that offers this ability. And so Drupal 8, if I don't know if you guys have been around for Drupal 7, but we had a problem in Drupal 7 where the contrib modules just couldn't keep up with the release and we didn't have these modules in time. What I'm here to tell you is that Drupal 8 can be used differently. And I actually challenge us to use it differently. Because in order to create this mapping capabilities, really all you need is you need Drupal to handle the data and you build the app to do the interface. So this is what I call the web application. A web application works a lot differently. You use Drupal to input the data and to manage the data. And so all you really need is a text field to say what is the address that you want to enter. And now Drupal becomes a REST API for the address. And then you use AngularJS. You have a whole suite of libraries at your fingertips with AngularJS so that you have control over the app. And all Drupal is, it becomes this back end engine of data and it really has nothing to do with the app. And to me, this is what Angular represents to Drupal and it's the future of Drupal. So all you have to do is do Bower install Angular Google Maps and you build your application so that it takes that address, hands it over to the Google Maps API and it shows the map right on the page. And you can do that today with Drupal 8. And so this is what I'm saying. This actually might be our development strategy moving forward whenever Drupal 8 comes to market and we don't have those modules that we have previously depended on. So let me ask that question again. Why AngularJS? And the reason is because Angular forces us to develop a Drupal website like a web application. And I want us to start using those terms differently. A lot of us have been using, yeah, I build web apps. I'd like for us to say a web app represents this type of application structure that is completely different than a website. A website is the old legacy way where a person would hit the server and the server would hand them the interface and that's a website. A web application is this living thing that's on the front end and it's structured completely different and it only communicates to Drupal via RESTful APIs. And AngularJS is not the only technology that enables this. I'd like for you guys to take a look at React. Fantastic front end framework. Other ones are Ember. Angular is just the one that all the cool kids are using. No, not really. All the cool kids are using all of them. But AngularJS, it has definitely made a lot of traction in the market and it has a massive community behind it as well. So what does a modern web application look like? Well, it looks a little something like this. On the front end, which is the left side of here, you can see that it really becomes the application. You have AngularJS, HTML5, JavaScript, CSS. Angular provides the ability to create templates. So they call them partials. And so you can have all your templates reside in the front end application. It can dynamically request a template as the user is using the app. So you don't have to front load all the templates to them. You can make it dynamic if you wanted to. And then also local storage has become very important. So combine all of those three things on the front end. And you can literally build a complete software application that's just a front end solution. And it only communicates to Drupal via APIs. And those APIs then hit Drupal. And Drupal basically serves data. Drupal doesn't serve the theme. And for example, in this situation, you would never use the theme engine. You would use it to be an administrator of your CMS, which the theme engine is important for that. The admins still need to be able to administrate the app. But from a user's perspective, they're not hitting the theme. This is all data-driven. This has also been given a label that a lot of you have probably heard of. The label that it's been given is called Headless Drupal. And I really believe that it represents the future of Drupal and how web applications are going to be built in the future. In fact, I believe this is Drupal 8's saving grace when it comes to people having these dependencies on, you know, you need to build an app. You no longer have your hands handcuffed to the contrib community. You can build your app and make Drupal just be the manager of data. And you can move forward with Drupal 8 today, doing just that. Another thing that I would like to mention about Headless Drupal is a lot of people are giving a lot of focus on the Drupal end of it. And not much attention has been put on the AngularJS. And really, all what I'm talking about is that the whole paradigm is flipping. Instead of you enabling these contrib modules to add features to your website, now it's becoming, if you want to have comments in your website, you just embed discuss. You don't enable the discuss module. You just use the discuss widget to embed, and it basically comes alive. If you want Google Maps, you don't enable the Google Maps module. You just use Angular and pull in the map and then pull the data from Drupal. And what I'm talking about is something that I'm calling these multi-service applications. And to me, multi-service applications, this is the future where the whole, your world is flipping right now. Where you used to be very Drupal heavy and everything that you had to do had to be Drupal. What I'm saying is you now have the opportunity to connect to anything from the app perspective. And Angular enables you to have this ability. So if you wanted to use Drupal, you can. But you can also connect directly to Google Maps. You can direct Facebook, Twitter, the company that I'm working for, Form.io, is another one of these that you can just use it as this ancillary thing in your application. And Drupal no longer has to be this hub, this little spoke, and everything depends on it. Your app could just use it as a means to pull and manage content and pull in that content. It also changes the way we build apps. And as developers, a lot of you probably remember four or five years ago, the really big thing was this term called mobile-first development. And what mobile-first was is they were saying we got these mobile devices coming into market now. We have to build our websites so that they look good on mobile websites. But even then, even if you were building a site that had responsive template, you were still requesting the page from the server. And the server was handing you a responsive website. And what I'm saying is it's now completely different. The app exists on its own thing. You can deploy it using Cordova. You can compile it as a mobile application. But it exists outside of Drupal. And in Drupal, you really have to focus on something else, which is API-first development. I really feel like we are in a new phase of development where we need to start thinking API-first. And not mobile-first. I mean, mobile is just a part of API-first. But if you start thinking I wanna build my API-first, you then really open up the door to create a multitude of apps that consume that API. And the way I think API development should work is you build your REST platform first. You use Drupal to construct your entities, to construct your content types, and you expose that via RESTful interface. And the next step, in my opinion, is the most important step, which is your first app should be the API test. So once you have your REST API in place, you can build a test to test it. And guess what? You don't need PHP to test it. You don't need PHP unit. I recommend using a Node.js testing framework called Supertest. Makes it real easy. Think about this. This is now an API engine, and you can use any language you want to test the API because now that API is a black box that you can expose to other testing frameworks. I personally love Node.js and Supertest. And so you can write your tests for your API in that. But once you have your tests written, you have a very deep understanding to how this API behaves, and now your tests can serve as a framework for the application that you build next, which is next you build your app or website only using APIs. I think this is the future. This is where we need to start building apps and this is where we need to start thinking about how to build apps. So with all of that said, what I'd like to do now is I'd like to shift my focus over to Drupal and just say, okay, now that we've got that, this whole methodology of building apps, how do you actually do this in Drupal? Which is where I'm gonna shift my focus next, which is how do you configure Drupal for RESTful services? And then spend probably a lot more time in AngularJS. For those of you who are very interested in the technology, I think it's, there's more value if I spend more time on Angular than if I did on Drupal because be completely honest with you, from the Drupal perspective, setting up at least a read-only RESTful API is very easy. So that's what we're gonna do next. So let's build the future and see what that looks like. So let's configure Drupal 8 for web services. For those of you who do not know about Drupal 8, Drupal 8 actually comes out of the box with capabilities to do RESTful APIs. So all you do is download Drupal Core. In fact, everything that I'm doing in this presentation, I did not enable one contrib module. That's the point. You don't need to. You can build your app using Drupal Core. And to me, that's just a massively powerful concept. And you can build some pretty powerful applications that just use Drupal Core. So download Drupal Core. And the first thing that you're gonna start to worry about is how does this server communicate to all these multitude of devices? You remember whenever I said at the beginning, I was like, the old way Drupal did it is the server would hand over the interface, which means that when you're looking at the interface, you're on the domain of the server. Whenever you build apps as API first and the applications exist completely separately, it's very common that your app is served from a CDN, for example. In fact, I recommend that. You don't need to have the Drupal server serving the app. You can put it on a CDN. And that way, your app can be deployed all over the world and it just uses, hits the Drupal servers, but your CDN is gonna be on a different domain. And so therefore, you need to construct your app in a way and your server in a way so that the application can communicate to that server. And they call this cross origin resource sharing is what this is called, it's called cores for short. And it's very important to understand this whenever you start building this way. Otherwise, you're gonna get really frustrated whenever things don't work. There are a PHP ways to do this, but I actually recommend not using PHP to do this. You can do this from the web server level. So Apache, IngenX, you can go in and I know this is extremely small. But if you guys are viewing the website, over the website, basically you can set up in Apache the ability to set headers for every request. And so you can expose cores capability from the Apache level and from the IngenX level. And in my opinion, this is the way to do it. Because now you're not making your app, your server code complex by adding stuff that really should be server specific configurations. So once you have cores set up, the first thing you're gonna wanna do is install Drupal 8. How many in here have actually installed Drupal 8? Have had it up and running? Okay, we got this part, right? So this is easy. I like to use Drush to do it. And so you can get it up and going pretty quick. And you can install it locally. I recommend Calibox is a great way to get your local environment up and running. The first thing that you're gonna wanna do is head over to the modules section. And keep in mind, these are not contrib modules anymore. These are core modules. And there is a section called web services. And you're gonna go in there and you're gonna enable all of the web services modules. So HAL, HTTP basic authentication, RESTful web services, and this thing called serialization, which does all the JSON outputs. So once you're done doing that, we now shift our focus over to using content types as resources. Now I think this is kind of where Drupal's still kind of stuck in web 2.0 days by calling them content types. But you can use content types to create these objects that the REST API is gonna end up exposing via RESTful services. So the application that I'm building, I have a multimedia background. So I have this tendency to do everything with multimedia. I'm gonna create this movie app that allows you to create multiple movies and show YouTube videos and the like. So I'm gonna go create a content type. I'm gonna call it movie. And that's the URL that you go to to do that. And here's where a great illustration of what I'm talking about whenever I say you don't need contrib modules anymore to do cool stuff. If you want YouTube integration, YouTube has embed links and that's just a URL to the embed link. And YouTube exposes these widgets that you can embed those widgets in your front-end application. So if you just wanna do YouTube videos, you just make it a field type of link. It's a URL and that's your data input. I'm not, you notice I didn't install a media module. I didn't install media front. I mean, you really don't really need that yet. So you have this YouTube URL and you're basically adding it as a link. And then you now have essentially the data structure that you need to build to use Drupal as the back-end for your application. The next thing that we're gonna do is we're gonna go over to views module. Now views is part of core, but views also has this incredible ability to expose RESTful APIs from a get perspective. If you wanna just have an app that consumes data and views is really good for this. And so what we're gonna do is now that we have a content type, it's just as easy as going into the views module, creating a movies view. And then down there, because I enabled those REST modules, the views module now exposes this new section called REST export settings that allows me to put a path, a REST path, to get at those movies. And so when I do that, it actually kinda looks something like this. So I've got my structure here and I'm gonna go to my views. And let's see, where are some movies? There it is right there. And really it took me just a minute to set this up. And what this does is it now exposes a URL that when I hit it, it's a complete REST API and it's a list of it. And you also have the ability to use views to do all your filtering. So if you wanted some complex search capabilities within your application, you can set up those as parameters within view to filter the content. So your app just uses views as its data source. It's a really powerful concept. And also once you create one view to do a list of all of them, oh yeah, you wanna make sure that in the format settings, you enable these request formats to accept Hal and Jason. And I can actually show you where that is real quick. It really won't take very long. When you create your view, you'll notice it has a serializer format. If you just click on that serializer format, it comes up with the style options and that's where you'll actually configure your request formats. So once we've done that, the next thing that we're gonna do is we're gonna create the single movie page. So now we have a URL at movie. And the reason why I didn't go movies is because REST kinda has this thing where you use one term. And if you don't put anything after it, it's the index, right? It's the index of all of them. And so I didn't want my individual page to be movies and then the ID, I just like movies. So here we're gonna create a single page by going up to the add button over there on the REST and it's just gonna be another REST export. And then we wanna make sure we change the path to forward slash movie, forward slash in this ampersand sign. And what that ampersand sign does, that's not an ampersand, that's a percent sign. And what the percent sign does is it tells the view that there's gonna be an argument coming in at this location. And so take that as an argument and so that whenever you're configuring your view, you can use those arguments to do filtering, which is what I'm doing over here in the advanced section. I have this thing called contextual filters and I'm adding the content UUID to the input. Now UUIDs are very important for REST APIs and the reason why you wanna use a UUID and not a node ID is because as you deploy this on the multiple servers and you do imports and all of that into your multiple staging environments, the actual database IDs can change. And because this is now a REST API and you're gonna be writing tests around this, you wanna make sure that you keep that UUID because that won't change depending on what deployment this goes out to. If anybody you guys wanna see what that actually looks like. So here's the REST export. And it's gonna be, I think you guys get the point. I'm not gonna go Bill O'Reilly on you guys tonight. Do it live if any of you guys didn't get that joke. So yeah, you create the, and so now at that point your API is live and we can actually look and see what this API looks like in its, or we won't. I guess my server's not working. It's a good thing that I've got it all down. So anyway, you actually have the ability to go to movie, but then I can also, that's the name of the view. Let me just see if my view works. It doesn't. You get the point. So at movie you see the listing of all the views, but I could actually copy this UUID that's right here. Copy it and put it right next to it and then I would have that single movie resource that shows up. And so now you essentially have a REST API on the get side of things. Some of you guys are probably also wondering, okay, what about creating content? What about logging in authentication? Just for time's sake, I'm not gonna be able to get into that, but by default Drupal does handle user authentication via REST API. So any of the URLs that you want to do user login, those things are already exposed. Another thing I will let you know is that things are still changing in Drupal 8. In fact, they've recently made some changes to how the REST settings work. It was like an XML file where you can expose certain verbs on different content. So just keep your eyes peeled in the near future because I think that's gonna solidify here pretty soon. And I will very, very happily come out with another tutorial on doing login content creation and all of that. But one thing that I will like to mention is that when you build apps this way, you still have the Drupal interface to do the administration in the content management. Your app can basically be built as a user consumption side. And you may not have the need to have them create content or login or whatnot. But if you do, you can do that as well. So now that we have an API, let's actually shift our focus over to AngularJS and say, okay, now that we've done that, it won't take you very long to set that up, let's actually build the AngularJS client and see what that looks like. In order to get started, I highly recommend there's a thing called scaffolding and scaffolding this Yeoman scaffolding tool will very quickly bootstrap your AngularJS application and get you up and running pretty quick. So all you have to do is just type one command and it basically gives you all the structure you need for your AngularJS application. And the way that works is I'm gonna make a directory for my Drupal app and keep in mind, this is not my Drupal directory. This is local on my machine. I don't have to do any folders inside my Drupal folders. The app is completely separate. That's the whole point. I'm not in the theme folder here. This is just locally on my machine. I change directories into that and then I type npm install-gio. And so you will need NodeJS installed here, so NodeJS is fairly easy to install. If you just go to NodeJS.org, you can download it and it'll install Node on your computer. And then you have at your fingertips a whole amount of awesomeness because Node is amazing. So you're gonna type yo and then after that you're gonna type npm install-g-generator-angular and this is one that's maintained by the Yeoman team. And then all you have to do at that point is type yo-angular. And what Yeoman does is it starts off by asking you some questions. It says, would you like to use SAS? So this has all of the SAS capabilities built into it. Would you like to use Bootstrap? I think there's other CSS frameworks available for Angular Yeoman. I think there's one for foundation. There's probably some other ones. And then it asks you, hey, what packages would you like to include? In my opinion, this is the future of probably about 60% of Drupal modules on Contrib right now. 60% of Drupal modules are modules that facilitate app building and like the actual interface. And really Angular, the Angular community has an amazing amount of support for all types of application things that you can enable. By default, it's gonna ask you to do like animate, cookies, resource, message route, but there's plenty of others. And after that we're going to, now we have this application. In fact, I can show you what it looks like. So the application that it builds looks, it gives you an app folder. And inside there, it gives you a ton of stuff that it builds for you. It gives you grunt capabilities where it does auto compilation. It gives you a bower support so you can easily install new modules into your app. And it also does building of your applications so that before you push this to your CDN, if you wanna do some type of pre compilation for cache busting or any of those type of things, it has all of that built in. And so now it builds this disk folder so you can easily push this app to the CDN and you've basically done deployments. Another thing that a lot of you probably don't realize is when you build apps this way, your app is really decoupled from the deployment of Drupal. So that whenever you wanna roll out new features, you don't necessarily have to get in and tinker with Drupal. You can if you wanna add new fields or whatnot, you can tinker with it. But your app deployments become so much simpler. You don't have a server anymore. This is not a database. All you're doing is deploying an app to a CDN and then people then can use the CDN to request the resources. So another thing, the library that I added to GitHub has this folder in there. If you guys wanna go to GitHub and look at it while I'm talking about it, it's the app folder inside of it. So the first thing we're gonna do is we're gonna, once Yeoman builds us our scaffolding, we're gonna open up the app scripts app file and we're just gonna add our base URL of where we wanna point, where we wanna make our calls to our Drupal server. So this can be a remote server but we have the ability to set it. I like to do this just so that we don't have to retype this everywhere within the application. You can also make this part of the build process and I have some ways of doing that if you guys are interested. So you can just create a single config.js file that can be loaded depending on what, if you're doing a dev deployment or if you're doing a staging deployment, you can just include a different config file. From there, we're gonna use Yeoman to actually generate routes within our application. And so Yeoman's really cool because it allows you to do routing within the application but it is a single page framework or single page application. So if any of you guys don't know what a single page application is, really all you're doing is loading the index.html and every route that you go to just dynamically loads the content within that single page. And that's a much different paradigm shift than what you guys are probably used to where the pages are different based on requests. Angular basically says here's our page and I'm gonna load whatever content we want inside of it. So we can provide routes and we can use Yeoman to be our friend here by just typing a single command that says Yeo Angular route movies and what Yeoman does is it builds the route, it gives you the HTML page and it hooks all of that up for you. So here's what it actually looks like inside of our app file. It will actually create a controller for us called movies.js, provide some of the scaffolding behind it but then it also creates this movie's view. So in Angular you have this separation between the theme, the templates, how I mentioned that you have front end templates now and the actual controllers that control it. And each template only contains the content that you need within that template and these are front end templates. These are not rendered on the server. These are rendered in the browser. When you're first getting used to Angular that will throw you for a loop because it's very different than the way you guys are probably used to. And then the movies controller is responsible for all of the data. I might be getting a little bit ahead of myself but I wanted to make sure that you guys see how all of that is structured and how all of that relates to one another. There is a single index.html file. This is the single page in the single page application. And so here you don't need to learn templating languages. I mean, you do have to learn some things in Angular that are template E but this is HTML. If you guys know HTML, CSS, you can build a web app in Angular. And so here we're basically using these special tags within Angular called ng. Anytime you see ng in front of an element, that means this is a special Angular directive and the way Angular works is it attaches this custom functionality onto these tags. And so here I have the ability to change my navigation where I'm gonna assign a class based on if this is the active route or not. So inside the app index.html, if I wanna add that tab to the page, I add it in HTML. I'm not going to the menu section in Drupal anymore. I'm not going and saying I need to expose a menu tab. You just add it to the HTML. So for people who are used to Drupal, this is a very different concept but once you experience it, you're gonna feel free to just do what you want within the app and it's a wonderful feeling. And then within the movies controller, all I wanna make sure I do is I wanna make, I set this root scope variable which exposes variables at the root level and I wanna make sure that whenever I click on the movies tab that it actually sets that tab as active and that's what the ng class does. So these ng directives really expose custom logic to these Angular controllers. So the way that you do that and then it executes those controllers. So now this is how you create a table listing of the movies. You can just create a table within the movies HTML and you can give it a title video and then you're gonna use this thing called ng-repeat. And ng-repeat allows you to iterate over an array that's exposed within the controller. And this is kind of where I think people's minds are gonna get blown a little bit. So ng-repeat basically looks at variables, JavaScript variables and the variable that it's looking at is this movies variable and that movies variable and I'll show you where this is defined. It's set within the scope of the controller and it iterates over each one of them and assigns a variable called movie and then at that point you decide what you want each row to look like. So here I have an anchor tag and I'm using ng-href which actually uses Angular's single page routing so it feels like it's multi-page but it's really not. And here you see I've actually got Drupal data at this point and this Drupal data correlates to the JSON object that I get back from Drupal. And so that tells me that it's uuid. Drupal has this thing where it kinda adds everything in an array which is kind of little squirrely in my opinion but you can get around it by just referencing that value. And then obviously the title goes here and then your movie, your YouTube URI looks like that. The next thing that we need to do is shift our focus over to the controller. So AngularJS has this concept of controllers and views and controllers expose functionality to the views. And so this is inside controllersmovie.js where I set the active nav to movies but then I define this movies variable on the scope and what that does, so the scope variable is a special variable in Angular that says anything you assign to this scope is going to be exposed inside the template. So whenever I say scope.movies I am now assigning a variable that I know I need inside my template. So that's how that works. Angular is all about scope and you create these widgets that have control over the DOM that those widgets represent. Quite there yet. So then what we're gonna do is we're gonna pull in this thing called HTTP. This is a special AngularJS library that you can pass dependency inject into AngularJS. I probably should spend a little bit of time talking about dependency injection. And the way AngularJS works is is when you build a controller you tell it whenever you declare the function for the controller what do I need Angular to hand me so that I can use and then Angular just knows that it's supposed to handle the HTTP. You will also see another format in Angular where this is an array and each one of these is a string within the array and then it passes the function into and then the function's the last element in the array. I actually recommend that way. Then the way you see here, the reason why I did it this way is just because it's more readable. But just know that whenever you're building these controllers you need to look at and read some documentation because they'll show you this notation where you add it as an array and each of the dependencies is a string and that will work whenever you do compression. This will break when you run this through a compression algorithm, just FYI. So now once I have this HTTP variable I can use it just like I use jQuery Ajax if you guys are familiar with that. So I go HTTP get, I pass my base URL and then this is the Drupal movie endpoint and what that does is then I declare this success call back and then the result is assigned to that movie's array. So when you do that your page will then come alive and show all of the content from that Drupal view and it looks something like this. And just for the sake of time, just take my word for it. That's what it looks like. And I also don't think it's gonna work because something happened to the server I think. So the next thing we're gonna wanna do is we're gonna wanna create a movie page and for that we're gonna go right back to Angular Yoman and use this Angular route movie view and say I want that movie view to execute at this URL within the Angular app. And when I say URL, what it really is is it uses this hash sign. It uses the hashtag at the very front of it and so that whenever I actually navigate to something you'll notice that I navigated to hashtag movies but really what this is doing is this is sending a command to Angular so it works like a bookmark but it's not. It's telling Angular, here's the route that you need to execute and then whenever I click on any one of these you'll see that I add the ID to the end of it and suddenly we have a working app and I definitely got ahead of myself because you guys just saw the punchline. Forget you just saw that. So URI movie four slash ID basically says that's the UUID that I wanna pass to it and my movie view will just look like this. It's HTML. I wanna make sure I show the title. For the body content, Drupal likes to hand you HTML in a string and says okay here's the body of it but Angular is okay with that. What you have to use is this directive called ng bind HTML and you attach that to a page and then you pass in the variable and then there's one other really important thing here. Drupal, Angular will get really angry with you if you try to do unsanitized HTML strings but because we know Drupal's managing the content for us we can assume from the app level that it's okay to render. And we do that, oh this is what our controller looks like for movie add. We basically create a movie object and we do a get to that state parameter so whenever they see that URL, Angular does the same thing that views does where it takes that variable and it basically signs it there and then you're gonna sign this movie object to the result. And here's what that filter looks like. You do have to create it yourself. I created mine in the scripts app.js file and you just make sure that you use this special SCE, I don't know what that stands for. And SCE allows you to trust a string as HTML and so anytime somebody uses the filter safe on a string it knows to apply that filter and this is how you use it. You take the value of the body and use this, what is pipeline and you pipe it to the filter, the name of the filter and it just knows that that's how it's supposed to execute. So now because this is where it gets a little interesting we're not installing the YouTube module here but we can use Angular to create a really cool tag called the YouTube tag that basically creates a YouTube player on our page and Angular has a thing called directives that allows us to do this. So our directive looks like this. We wanna say that if they use the bracket YouTube we're gonna use this template, the views YouTube. We need to create another filter because we're giving it a URL that's outside of the domain so we have to make sure that we trust that URL as a URL. And so now here's what our actual YouTube template looks like. I got this from YouTube's embed page on their API. You just go there and they say here's how you embed a video and you'll notice all I'm doing is I'm passing in the source. This source variable is exposed from the directive so basically what I'm trying to do and you'll see how I use it here in a little bit. It looks like this now. So now inside my movie view I can use this YouTube HTML element and give it a source of the YouTube URI. I'm just gonna throw this out there that that's a pretty powerful concept here. It's also the concept that we at Form.io did with forms so that you can just hook a form up and provide a source tag and it knows how to do all the IO. So this whole concept is a very, very powerful thing that you can add to your apps. And once you do that, you get essentially a full working application that only uses Drupal as the RESTful API back end. And it looks something like this. So you basically have this icon. I could, and you notice here is it's actually rendering the body of the tags and this is a YouTube video and all of this was built completely separate and outside of Drupal. All I did was use Drupal as my database, as the data repository. And you can easily do this with maps as well. That's it guys, thank you so much. I think we do have five minutes for questions. If anybody wants to ask questions, yeah. Could you talk a bit about the REST based authentication that's coming out in Drupal 8 or what's already there? Is it like token based? So right now there's basic authentication that's exposed. So using the authorized header that you can use. I would love to see JSON web tokens get created because in my opinion, that's where we probably should be moving with authentication in Drupal. That has not been built yet but you can also, when you install Drupal Core, you have user forward slash login that you can use. You just have to provide the form ID in the post and that will authenticate and uses cookie based authentication in a way that Drupal 7 does. Great, thanks. You're welcome. Hi, so alongside Angular and other front end frameworks has been the rise of Node and Express and even Go on the server side. And you see those a lot in really interactive applications. And they have the advantage of being extremely fast where PHP is not. How do you see in the future Drupal playing in that ecosystem with Node and Go and those other server side technologies? What I love about APIs is it also allows interoperability between multiple services. And so I really see Drupal's place being in content management and all of the things around content management and content workflows. All of the other stuff that an application would need, in my opinion, I'm fully bit the hook on Node. I'll tell you that right now. I do most of my development in Node. So I know exactly what you're saying. It is an amazing framework. But how they're probably gonna end up playing together is there's probably gonna be a lot of connector technology where you can actually build like a Drupal connector for Node and then you can actually map. Like Mongoose is a MongoDB library in Node.js and it's schema based. And that schema looks very familiar to Drupal's entity. And so all you really need is, in fact I think this is coming is people are gonna start creating libraries that maps like a Mongoose schema to a Drupal entity. And so that whenever things are happening over here, you have web hooks or you have web socket communication to synchronize some of the data in and out of Drupal so that people can use it to manage the content. But as far as the actual real time runtime of the application, you can do so with using Node.js. That's what I see is coming down the pipe. Thank you. I got a couple of questions. Is there a way to do push state instead of those hash signs in the URL out the box with Angular? To change that hash? Yeah, with like the history push state method. There is out the box. Talk to that guy. I will, I'll catch you later. Thank you. Yeah, I don't like how they look. If there is, I haven't seen it, but you know about it. Okay. HTML5 mode. Very interesting. Awesome, excellent. Thank you. Yeah. There you go. So and secondly. Thank you. Secondly, I still don't get how you're overcoming the cross origin policy. Is the server that's serving this Angular app reverse proxying your views RPCs? That's a complicated question. Is it reverse proxying? Maybe I didn't understand what you're asking. So this app that you made right now, it's accessing a Drupal 8 in the back. It could be on a separate IP address, separate domain. So when the request comes from the browser, does it come through the Node.js and then gets reverse proxied over to keep it on? No, it hits the server. Separately from the browser. Yeah, well the browser does the request to the server and the server because it's configured with cores, it adds some headers that allows the browser to be okay with that request. So really the request cores is really for the clients that will refuse it. And if they have these special headers that they're basically asking the server, hey, is it okay that I'm doing this to you? And the server's like, yeah, yeah, do it, I'm okay with it. So it's from the server, it's not really from the bootstrapped app that decides. The boot, well, what's rendering the app is what needs cores because it sees those headers and it says, hey, is it okay to make this request? So when you push this app down from a CDN, is there something that needs to go on the CDN as well to say, okay, it's okay to access other URLs from this app that I'm throwing out? So you can actually map internal URLs to a CDN so that's one way to do it. Or you can use a subdomain to do not maps to the CDN. So in that specific case, you're not gonna have the cross origin policy issue because the app, even though it's being delivered by CDN, it's actually gonna look like it's on the same domain as the, so you don't have that issue. If you wanna host the app somewhere else, for example, on a Cordova, this is very important when you compile your apps for Cordova because people are actually loading the apps from within like a web view of the Cordova app. And so in that situation, the origin is gonna be different and it needs to, the course has to be enabled to make that communication work. Okay, and one last question. So making these things crawlable, like you know, by Google Spiders and all those things. So that's another tricky part of it. Do you like make like an offline version of it? Well, Google created Angular so they make sure that their search engine works plays very nicely with Angular. Yeah. All right, great. Awesome, thank you so much. Yeah, any other questions? I think we're almost out of time so maybe one last? Oh, this is a quick one. The hashtag in the URL does, now the URL from the services in Drupal doesn't need to be clean, obviously. Having that UID in there is calling the specific node not a big deal. For AngularJS, can you do clean URLs? Can you do clean URL? Yeah, like SEO friendly. Without the hashtag? Yeah, SEO friendly looking and all that. I wanna just give this guy the microphone. He knows a lot about Angular. I believe so, yes? Yeah, is the HTML5 mode? Yeah, it's fine. What? And they are clean. You define what you want the URLs to look like in Angular, so yes. Let's do, yeah, let's see if we can get through these three real quick. Yeah, go ahead. Yeah, I've used Angular, like the course thing gets rid of like JSONP and I've done an Angular app there and we're using JSONP. So the thing is, shouldn't somebody do, I look at the RESTful API like in Drupal 7 and there's nothing to like set those, so maybe a module, you know, like. So if you're using Drupal 7, you should be looking at the services module. Right, I'm just working at that right now, but in Drupal 8, should there be a module like to help people set the server, cores? Should there be? There's the RESTUI module. I know there's a cores module. And there's a cores module in Drupal 8? Yeah, okay. Then it's getting along, because the last time I installed it was like. And that's a PHP method of doing it. So if you don't want to dink with your server configurations, yeah, enable the cores module. Right. Okay, okay, good, good, that's good. All right, thanks. Thank you. Great session. So this was a great example of a very simple use case. So if you have a homepage with a lot of dynamic areas and then you go to another subsection with a billion other dynamic areas, each page load is gonna be loading 10 REST calls. Is that how it should work? Or should you be doing one REST call? So you could, you could, based on how you structured in Drupal, you could probably set up a REST call that combines a bunch of data and then from the app perspective it can then take that one REST call and distribute it out to where it needs to be on the content regions. That's one way to do it, but yes, it's gonna increase your load as from a REST perspective on the servers. But you have control over that as you build the app and as you configure the backend. So I'm a front end developer and I found that probably five to 10% of my time is creating templates, modifying templates and probably 90 to 95% of my time is CSS and jQuery and that sort of thing. And it seems to me, this is new to me, there's a lot of writing format handlers here. So in a time to market, how would you compare creating through what we do in seven versus creating a theme in a using Angular? So creating a theme, so this is where, this is where I'm my opinionation, I'm gonna be a little opinionated here. Creating a theme in Drupal for Angular in my opinion does not make much sense just because you're basically telling Drupal to try and create a theme that works like an old theme when really the theme is a single page application. And so from a, to try and answer your question you said from a speed perspective how much faster is this? Angular has a learning curve that you have to get over. There's a lot of facets to it. But once you get over that learning curve of Angular you get it and you can spin up apps very quickly and you're not locked into the theme system is kind of my point. You don't have to create a theme anymore for your user apps. You just use Yoman and let Yoman build your front end app and then build your services on the back end. So in my opinion, if you wanna use AngularJS it doesn't make much sense to build a theme for it. That's my opinion. Some other people may have some other opinions. I think we definitely have to get out of here. So sir why don't you come and talk to me afterwards? Yeah thank you guys.