Full Stack Angular 2

0 0

JEFF WHELPLEY: Great. How's it going everyone? Great to see everybody. Standing room only, awesome. My name is Jeff Whelpley. I'm the chief architect at GetHuman, and this is Patrick Stapleton, also known as PatrickJS. PATRICK STAPLETON: Hey, guys. JEFF WHELPLEY: He runs Angular class. Today, we're going to try to go answer two pretty simple questions. Why should you care about full stack development using one technology across all your stack and your application? How's it going to benefit you? And then why Angular 2 a good solution for doing full stack development? Now what you'll hear often, as a smart thing people will say is, use the right tool for the job. And this is a smart thing. It generally makes sense. But there are some challenges with doing this. Namely, if you work for a bigger company, you can't just use any tool. You can't just use any technology. You have to get it approved. You have to get other people to buy in. And you have to go through n levels deep of committees. And that take a long time, be arduous, and you might end up with something that's more politically driven than the actual best tool for the job. The other thing is that in certain environments, it causes contention among people that have different opinions. Even if you don't have those two issues, in a hybrid environment, you have some loss of productivity when you're switching between many different technologies, or if you split teams across technology boundaries, you have a problem with-- you have increased communication needs between those teams. And then finally, in a hybrid environment with many different technologies, you end up having a lot of code duplication, where the same security standards, data models, other things that are common throughout the organization have to be implemented many different times. So just, I'm curious, a raise of hands of people in the room. How many people have experienced one of these issues in your organization? OK. Pretty much everyone. And that's not uncommon. So there are a lot of ways of dealing with these issues. But I want to throw out there one kind of simple solution, which is to think of a hammer. And everything else is a nail, where you're using one technology, one primary technology, and you're using it for everything. When you do something like that, just from a conceptual stance, you eliminate a lot of these-- no committees, no contention. I mean, it's all the same thing. No worry about context switching, and it's very easy to eliminate code duplication. Essentially, you're able to save a lot of time that you waste on these things in your organization. And that's time you can reinvest back into the product you're building. You can turn one developer into the productivity of five. Or you can use that time for other stuff, like playing cricket, or getting another pint at the pub, or doing whatever this guys does. But the people have tried to do this before. It is true that it's not necessarily a slam dunk. There are challenges with trying to use the same technology across all your stack. It's not automatically going to give you all of those benefits. When you look at JavaScript, which is really the only game in town for doing this because JavaScript is only thing that runs in the browser. JavaScript used to not even be good for the browser, much less on the server side. And it's gotten better over the years. It's improved a lot. But there's still challenges. However, with the advent of ES6, a lot of stuff coming with ES7, and Angular 2, we believe that this is going to be the best solution for doing full stack development. It's going to eliminate a lot of the common challenges that you face when you try to do something like this, when you try to get the advantages of using one technology across your whole stack. Specifically, there's about a dozen different features within these technologies that make full stack development really easy. It's much easier to adopt within your organization. We originally set up this talk to go over all these things. And the talk was like 2 and 1/2 hours. And that wasn't going to work. So we decided to focus on just the top two most important ones-- dependency injection and server rendering. So first for dependency injection. Think of just a simple model. You have your some utility that's referencing a model with some data. And conceptually, this is very simple. But when you try to implement this in a full stack environment, on the server, you might have the model that talks to a database, whereas In the client, you talk to an API client that talks to the API interface, probably to the model then on the server to the database. And in this case, even if you're using JavaScript on all of your layers, you're copying your code in this particular situation. So we can at least do a little bit better this. Let's at least combine them-- the utility, so that's it the same exact utility. This a little bit better, but in this case, there's a problem where you have to have branching logic within the utility to say if server, do this. If client, do this. And that's not ideal too. That's something that in the early days of Meteor, they've kind of gone away from this. But that was like a common way of doing full stack where you're kind of aware of what container you're in. But that's not ideal. Ideally, you want to eliminate that reference. And using dependency injection is one way of doing that where the utility, instead of referencing each of those directly, just references the dependency injector, asks for that reference, and then uses whatever's returned back. And this works, except there's two problems with this. One is that in Angular 1 at least, this only works on the client side. It doesn't actually work on the server at all. But if built your own, or whatever, and got this to work, it's not ideal either because the machinery that's involved with dependency injection is still within your code. You still see it throughout. What's really ideal is if you did something like this, what we are originally wanted to do, just a utility talking to a model. Now the great thing about Angular 2, and Angular 2 dependency injector-- which I think is pretty much the best dependency injector that I've seen-- is that you can do something like this. You can just have a utility reference a model without seeing all of the DI machinery, without seeing how all of that occurs. But DI still works behind the scenes to allow you at, runtime, to reference either the server or the client when you're running that code. So let's see a quick demo of this. PATRICK STAPLETON: Oh wait, they switched to the wrong one. JEFF WHELPLEY: Oh. Can you switch back? Yeah, thanks. So in this case, we're setting up. This is on the server side. I'm going to do an example-- Patrick's going to do an example later of rendering with the client and server. But I want to do example just purely on the server side using the Angular 2 dependency injector. Where in this case, we're creating an injector and passing in a bunch of providers. So these first couple ones are just used as is. But then we have a reference to a server, which the implementation of it, I happen to be using Happy.js as my server implementation. But you could also use Express or something else similar. And then for a router, we're going to actually start up an API. So let's just actually start that. Oops. So, it's just a simple page to show that it's starting from the API, versus if I just change the implementation here to use a different router, and then recompile. Same thing is from the web. So the main thing I want to show here is if you look into these classes-- so we are creating an injector at first. And we do see the machinery of dependency injection at this initial entry point. But once you dive into our happy implementation, everything goes by-- and this is using the TypeScript sugar you can use with Angular 2. Everything just uses the constructor. So you don't see inject. You don't see any of that. It's just as if you have types, but behind the scenes, this is compiled, It adds that injector so that it will inject our middleware directly into here. And then as it goes further down the stack, it'll just do that automatically. So this is what I'm saying. That going back to the presentation, you're able to achieve this thing where you're just doing this simple reference here, of essentially what's an interface. OK. Universal rendering. Back in June, Patrick and I talked about how we were starting to implement server rendering within Angular 2. And this was sort of the main diagram we went over where all of your code in Angular 2 is using the Angular 2 application layer, which doesn't change whether you're on the server or the client. And what does change is the adapter that's used within the rendering layer. That either you're using the DOM renderer on the client side, which interacts with the actual browser DOM, or on the server side, the server DOM renderer that we built to output actual string that you return back on the server side. And so during that talk, we talked about how, when you start using this, it's going to be as simple as, write your client side app. And just install a plug-in. And we have that fully set up at during that talk. But we do today. So if you want to switch, we're going to go over that. PATRICK STAPLETON: Now, what we're going to do is we're going to convert a client side only application to do server rendering. Now we're going to go-- we're going to be using the simplest example. What you saw here was the more advanced case. So what we see here is a very simple component. Now if you have been playing with Angular 2 recently, you know that the syntax kind of changed. And it's a lot more simple. You only need to do that component. And this is basically it. And there's one thing to know about this particular file. There's two files here. There's a app.ts, and a bootstrap.ts. The reason for the separation is for our universal case of being able to render on the server and a client. The problem is that if you have Bootstrap inside of this application, when we require the application on the server, it will Bootstrap itself. And then we don't have control over that. So this is the reason why we have this file separation. So you can think of the app.ts as the universal app, and then the Bootstrap as the starting point for the client. Now this is a webpack application, very simple config. You could look at this later. This is our HTML. We notice how we do the standard loading on our client side. And then we're loading our bundler. All right. Now let's start our dev server. Now this is one provided by webpack. This is only to showcase the client side application. Now as you can see, this is our initial page load. We see the loading screen at 30 milliseconds. Then now we see at 62 milliseconds our application. This is what we're used to today. Now let's convert this to a-- let's convert this to server the application from the serve. So let's create a server real fast-- server.ts. And we're going to be using TypeScript because it's amazing. Why not? All right. So the first thing we have to do to start a server is we have to, for our example, we're going to be using Express. So we're going to import Express. And we need to serve our files. So we're going to do express.static(__dirname). So __dirname is a helper in node to serve. That's representing the current directory. So what we're doing here is we're saying express-- this is a built in express middleware to serve this particular route-- in our case, the whole application itself. And then now we have to tell it to listen on a port. Going to use this because it looks fancy. And that's pretty much all we need for our client application to serve the index.html. Now if we go back here and do npm start. So npm start is referencing this particular file, which is doing ts-node. ts-node is a module that my friend Blake Embrey made. It's really awesome. It really should be built into TypeScript. Anyways Can't find application because I didn't create. So I totally screwed up here, and I forgot to make our Express application. So make sure you do that. Now we see that our application's hosted on port 3000. And we can see the exact same loading screen as we saw using the webpacks server. Now, this is where we start introducing server rendering. So we do that by using one of the helpers in the server rendering repo, which is currently the universal preview module. And it is the ng2express-- or ng2engine helper. And if anyone that used Express before, they'll know that this is how you would set up your views. You're basically telling Express to use these particular views. So let me just write this out real fast. Now this is saying that for every file that's ng2.html, I'm going to use this HTML engine, in which case, this is going to do all our fancy server rendering. And we have to change this file to ng2. This is just so it doesn't conflict with our static middleware. So now we're able to specify a route. Was it req, res? Now what this is doing, it's saying for this particular route, I'm going to use this middleware. And what this is doing is saying, I'm going to render the index file. And it knows that it's going to look inside the views directory, which is this whole directories itself. It's going to find the index that has-- why did I point to the screen-- that has the file extension ng2.html. Now we have to do one more thing. And that is import our application itself. Now our application lives in source app. And this is kind of why I was saying that Bootstrap shouldn't live in this particular file, because as soon as we import it on here, it would Bootstrap on the server. And that's not exactly how we would want to do that. So we pass it in here As such, denoting that our application-- that this is our top level component. And we're using the object enhancements in ES6. So that's basically like this. And if live coding works well, everything should be dandy, but nope. Universal preview. What did I do wrong? server.ts. AUDIENCE: Use Angular 2 instead of Angular. PATRICK STAPLETON: Oh, yeah, sorry. You're right. Angular 2. We didn't quite get there for Angular 1. But thanks for that. Cool. Now let's do this so it builds the files as well. Now refreshing after it's done building, whoops. Now we could see-- so I think I'm throttling the data so you guys can see this. Yep. So we're throttling it by really bad Wi-Fi, as if the conference Wi-Fi isn't bad enough. And you could see that whatever we refresh, so Chrome is doing optimizations. So that's why you see negative numbers here. It's so fast that it's, you know, ahead of time. [LAUGHTER] AUDIENCE: Backwards in time. PATRICK STAPLETON: Eventually if I refresh it enough, it'll say the correct numbers. There it is. So in 36 milliseconds, we're able to see the initial page load. And this is exactly what every single search engine, Google crawler, will see. And that's pretty much how you would do server rendering with Universal. JEFF WHELPLEY: Thanks Patrick. You can switch back. OK. So you can go and try that out. We're going to have a link at the end of where the starter repo is. And you can use the npm install that we have. But we are going to be working a lot over the next couple months about making it even easier so that depending on whatever your environment is-- there's many different types of server based environments that people have-- that whatever it is, that we'll have an easy way for you to just download it, get it into your app, and then have it working. So I want to make sure we thank Tobias. He's from the member of the core team that has been working with Patrick and I on this project. And in conclusion, full stack Angular 2 rocks. I can't stress enough how much we believe that it's going to change the way people think about full stack web development, that it just makes a lot things easier. Even if I wasn't using Angular for some weird reason, I would still use a lot of tools that we brought up in this list, especially the Angular 2 dependency injector. So we have the link here that you can check out after for seeing the starter repo. And one more thing we wanted to talk about. When you look at this list of different stuff that's involved in making a really good full stack app with all these new tools, there's a lot of things. And I totally sympathize with people that get frustrated in trying to move to this new world of JavaScript. There's just so many different technologies, so many different build tools, and other frameworks and libraries. And so it's hard when you see just little examples, like even the ones that we showed, of how you're going to apply that to your application. So one thing we thought about as we were working on this project actually was how great would it be if you had a real world application that integrated all this stuff in a full stack application? Now, for about two seconds, we thought that we were going to build that for this conference. But that wasn't going to happen. So we did start the project. And it's going to be at FullStackAngular2.com. I definitely invite everybody to go there, sign up, and over the next couple months, that's going to be our goal, to basically create an idiomatic example of full stack Angular, seeing how all of this stuff works for real. So thanks a lot guys. And appreciate it. [APPLAUSE] PATRICK STAPLETON: We should say that-- JEFF WHELPLEY: What's that? PATRICK STAPLETON: We should say that we need some help with Universal. JEFF WHELPLEY: And Patrick just reminded me, if you do want to help on the actual Angular Universal project, we are looking for people. And there's tons of individual tasks that are needed. So we definitely appreciate any help. PATRICK STAPLETON: Any feedback or any issues that you run into normally with full stack, just tell us and we'll make sure we fix it in our implementation of Angular 2. So if anything hurt you in the past with [INAUDIBLE], we'll fix it. JEFF WHELPLEY: Thanks guys.