Good afternoon, morning, or it's that time
of day, isn't it? Y'all having a good time so far? Good! Who is ready for some more Angular? [Applause]. All right. Feeling a little sleepy! Today's talk, when I was talking with the
event co-ordinators, I wanted to do something a little bit different and talk about the
ecosystem around Angular, and the title of this talk is Less Servers for Angular Apps
but I want you to think about when building applications, it's not similar. The hardest part of Angular is not just Angular,
it's the stuff around it. Angular is relatively easy to use and smooth,
it's the pieces around it that you have to use to build an entire application. I want to talk about how we build applications,
and the assumptions that we have in those applications when it comes to servers. So we are going to challenge our assumptions
today. All the things that we just live by day by
day in how we build our web application s remove remove the questions we should be asking
is images, fonts, assets, are they the same type of content as a web API, as data being
served off a server? When we serve static assets are they the same
concerns and things we have to deal with when we deal with a web API that we might build
with Node or asp.net, for example. If there are different things that you have
to do to get your data and different static - what is the maintenance and the load on
those servers? And that could be anything. That could be the physical, how much money
it takes, how much how many servers you have to prepare, what do you do to make sure that
Node is running on your servers, how do you patch them? How do you scale up or scale down? All these things have to come into play, and
the difference between a static server and a web API is very different. For example, if you build a very public web
API, website, out in the web that has millions of users hitting it, the static assets get
hit for the first page once with Angular, right? Most of them come once. A bit of lazy loading a couple of other times. Your web APIs will get hit a little bit more
than once on your application. There are different things that actually happen
to them. The loads are different. Then when you build a real enterprise application,
you generally have more than one environment as well. Do you have dev, tests, staging, prod, load? You have all these different environments,
multiple servers. You go from dev to prod. God bless you! You have one of those. Sometimes, you need to scale up or scale down,
so you need multiple servers to handle the load as well. How many servers do you need? I worked in shops where we had seven environments
and we had to scale out to ten servers and the production one. You start doing the math and even add a couple
of bucks a server, those things add up. There are a lot of things to talk about but
the maintenance of them all, keeping them in sync, and, of course, you're running Windows
10, I'm running Mac, and you're running Linux. You're in CI, you don't know what you're running,
so you have to make sure all these things are into account. This is real-world stuff. This has nothing to do with Angular. You want Angular running at the cloud. It works on my laptop? Can I go home? That's where I am. Let's explore first what I'm talking about
with this. You've got, let's say, a Node express server,
PHP, Java, whatever. Let's say we've got a Node server and we want
to see what it takes to deploy an Angular app with it. We will walk through Angular using TypeScript
and Node.js on an Express server. So in this application, and I like to point
out a couple of times in the talk that everything I do today you'll be able to try, all the
GitHub repos, there's an article explaining how to do this, two tutorials that you can
walk through, and if you want to deploy it to Azure, there's a link you can get a free
account as well. Everything you need, I will give you the resources
at the end. In this application here I've got - and we
will zoom over on the left - I've got my Angular app right there in my source folder, then
I've got my app, and I've got heroes and villains. Guess what, John Papa did a tour demo. Everything is running my heroes and villains
inside of Angular. I have to hit a server and my server folder
is here. It's the running Express. I can see I've got Express, body parser, in
a full-blown enterprise app I have 20 other middleware options as well, for logging and
security. And then I've got my function right here that
just kicks everything off. Checks your environment variables. Loads up my routes. Loads my HTML and my static assets. Everything looks pretty good to go. And then inside my services and routes folders,
that's where I'm holding on to my routes and cells like heroes, like when I see, I've got
/heroes, go to my - I come down to that one. I've got my async function for getting heroes,
and I'm using TypeScript, which by the way is awesome for Node express because I can
get the requests for my response-type objects - and I can go ahead and make my call out
to my database and return my response however I want to. All of this is running through Express, and
it works just fine. No app is real unless you can run it and debug
it. I've got a bunch of debug configurations up
here. These are in the article that I will point
to in the end so you can see how to set them up. I'm going to show you let's debug Express
and Angular at the same time. I'm going to select that one here. I will show you over here what that does. It's a compound inside of and it points to
two different debug configurations. These are the same names that you would find
up here. There is my launch configuration - launch
chrome. If you've got the Angular snippets, it types
it in for you. You can do it for Edge if you're using Edge
as well. We've also got our Express up there too debugging. I can press that button. Zoom back out. I just deleted my launch configuration. There it is. Now we press the green button. What it is doing is cranking up a couple of
things, cranking up the debugger for Express, and then it's going to hook to it and debug
it and also building my Angular application, and then once it builds the Angular application,
it will serve it and inside the browser. The debugger is already starting up here on
the top of my screen. It's going to look a little bit different
when it's done because that will be two configurations for the debugging in my application. Here's my app, my tour of heroes, and over
here in my debugger, we can see that I can debug either Node Express or Angular. You don't have to select one or the other,
it actually does it for you, but you will see, if I go and enable my break points, I
flip back to the app itself, and I refresh. I'm now hitting a break point inside my Angular
application. I press run, and now I'm hitting a break point
inside my Node Express application. It automatically to go else between the two. You can step, go into it, jump over it - anything
you would like to do. The nice thing about this is now I've got
my Node Express app that I can debug locally on the machine and if I want to deploy it,
I can do it in one of two ways. One is loose files which takes the files from
the builds and X copy them up to the server or go through GitHub through a CI process
and push them to the cloud. I'm not as huge a fan of that as I used to
be. I tell you why: I've been burnt on this a
lot. I'm building this on my Mac here, the CI machine
is running Linux, suddenly different, someone updates from Node 10 to 12 on the CI machine
and start pushing to production and it breaks. Things aren't working. Now you've got ten apps, 30 apps and that
could break. So what I like to make sure is that the environment
I have on my machine when it works, it works everywhere. I like to use Docker to do this exact same
thing. In the same repo, once I destroy the debuggers
- there we go - you will also see there's a Docker file in here. The Docker file is set up so we can both build
the Angular application. It does everything you would do normally,
basically an ng install and an ng prod and if gets whatever version of node I want. It does an npm install. I'm using TypeScript so I transpile my TypeScript
for Node and Express as well. I take the final results and push them up
into a container. I have this Docker extension in VS code which
you can download. I just build it and I'm going to start it
up because it's in my machine. Now you can see it's the running on port 770
right there. If I go back to the browser, and let's go
ahead and open under window, and there it's running in Docker. Don't believe me? We can go over here and debug it. Docker attach to Node. I think I left my break points on. Now if I refresh, - oh, it didn't hurt. VS likes it when you tell it what to do! It's now debugging again inside of Docker. I like the debug steps because it makes sure
everything runs the same everywhere you are. The reason we went down the path, to say we
build these applications, this has been the traditional way to build it - with a server
and a client. Imagine I take the Node server and have to
deploy it out with multiple instances of the server with a load balancer on top so everybody
can hit it, may be a light and dark mode, the Azure terms for this are "slots". You have one version on the site now, you
want to put another version in later. This stuff can really add to the maintenance
of what you have to do so to do because you night need multiple servers. All we're doing on the server is serving the
assets and using a web API. So let's think about this architecture. Often, we are envisioning this when we run
into projects. Every time I go to a new project, I'm thinking
that's how it's going to work. I've got a web browser, .NET, Java, Node,
whatever, and I'm hitting a database. That's usually what happens when somebody
talks to me. We've got this problem. Can we build this app? Usually, it looks more like this when I end
up going to it. They're like, yeah, we're hitting the other
back ends with different databases. Sometimes we get HTML, XML, and, this one
here is JSON. I'm yes, one is JSON. Yes, but that's ten meg of data. It's like oh, man, real world, you know! Then you start thinking about can I change
my back-end? The budget for the project is to build an
Angular app. You're an Angular developer. You're hired to build the Angular app. You're not building the Java, .NET, and Node
apps, and there may not be even budget and time to do this. How many here work under budget and time constraints? Nobody, right? Yeah! When you have those issues, what do you do? There are numerous calls, large data, lots
of different things going on. I like this pattern I call the "presentation
API", so let me show that one more time. We've got the web browser on our back-ends. All we are doing is shifting this thing called
a presentation API in between the back-ends and the front-ends. There's an extra layer, yes, but it's super
fast. What is super fast at input and output. I wish we had a technology like that. Node is great at that. Node is one thing. You like Go? You can go that route. The purpose of this API is to aggregate the
data and make a bunch of calls for you. What happens if you don't have the presentation
API and you make the four or five calls from the web browser? And you're on slow Wi-Fi? Are you going to let the browser make the
HTTP calls aggregate the Tait, try to transform your XML into JSON, merge multiple data sets
together just to show "John Papa"? It can add that aggregation, transform the
data, reduce the data, do those things for you or make database calls directly if there
are new things. Think of this as an API for your UI. So now we've shifted the web APIs to a different
place. This is what Angular sees. When you go develop with Angular now, you
could say, you know what? I can even mock out that presentation API
and use what I need right from there. Because I love to mock out my APIs, so then
I can build the UIs, it makes sense for me and my team. So we talked about Node and Express as a server. But now we are talking about okay, we just
went to building a presentation API, what if instead of Node and Express, we use serverless? Something like Lambda, or Azure Functions,
Google Cloud functions? We can use serverless to do the same thing
and now we don't have to have a physical server we deploy to because serverless is built to
scale up and scale down as we need and we don't have to worry about setting up an actual
server. If we go back to that diagram, we have a web
server still too. Don't we need a server for that? Well, if we move the APIs over to serverless,
now we just need to serve our HTML, CSS, and JavaScript. Do we have anything in the web that can serve
static assets? Absolutely. We have storage, we have CDNs, with , and
he they do these really, really well. You're taking your static assets, serving
them from any kind of storage container on the cloud, you can attach a CDN if you desire,
and you can serve those assets from there, you can serve your presentation APIs from
serverless functions. Guess what happens to all your servers? Poof! It's serverless! You always need serverless. The serverless term is interesting, it doesn't
mean that you have servers but you think about them less. Somebody else is managing those for you. Doing this, you can reduce a lot of the maintenance,
a lot of that load, and you still get quite a bit of the benefits in the process. You also have security benefits too. Have you ever had a server in the cloud where
you had to put patches on it with VMs? Or you want to make sure someone else is doing
it for you? Well, with serverless, these things are automatically
handled for you. There are a lot of ways you don't have to
worry about them, and it will also scale up and down for you, and you can put on different
kinds of note fires and logging to determine what is happening to your server at the same
time. Super high performance with serverless as
well. This is great for things like when you have
a Black Friday sale, you always hear about the sites that are kicking into serverless,
scaling up and scaling down. You get really fast performance, you get high
scaleability and the cost, if you pick a consumption model with serverless with any of the major
cloud providers, you only pay for when you're actually running the functions. That's it. Whereas if you buy servers, you're paying
for the server, whether you're using it or not. So you may have heard this term before, the
JAMStack. So serverless web apps, serverless for the
functions themselves, I don't have to serve the static assets, and they're web apps, right? They're Angular. With serverless web apps, the JAMStack. J is for the JavaScript - we've got that. APIs. We've got that with our serverless technology. Our markup - we've got that as well. All of these things put together help us build
our serverless web apps. We are here for Angular, so what this look
like for Angular? Here's the real surprise: it could work for
Angular, React, vue, or Backbone if you prefer in your application. Remember, this is what Angular sees. We talking about, if we're using Node and
Express in this case, our web server could be serving from Node Express, so our presentation
API, now, if we go another direction, with the storage, we can actually use storage to
serve the static assets, so now presentation API is serverless, Storage is running our
static assets, and Angular is just looking at our storage assets to load up the web browser
to see our content, and then it hits the functions whenever it needs to get its data. So, let's see a demo with the same application
on how this could work. We're going to work through the Angular code
which doesn't change R change at all in this case other than where it's pointing for its
APIs. We are going to look at the TypeScript obviously
both on client and server, because the serverless functions you can use TypeScript. You don't have to. You can choose JavaScript, C#, or whatever
else, or TypeScript. That's where we stay TypeScript on the server. We can see where our storage works on our
files and look at serverless, and I will be using Azure functions inside of VS code. Here is our same application. I'm going to disable the break points again. And we will take another exploration over
here at the application itself. Remember, we have this server, but we don't
want to use that. We want to use Azure Functions. I've got an Azure Functions project here. How did I get that. The cool thing about the Azure Functions,
you can create a new project, that one creates a new function, and that one, which looks
like it's pointing at the ceiling, because that's where Azure is, that's deploying the
function app. So if you want to deploy it - but you can
run the function app into your machine without talking to the cloud. Don't worry about Wi-Fi. Inside the conference centre, you can actually
try it. Once you create that project, I put it inside
this folder. Every function basically gets its own folder,
and I named these overly explicit to show what they have. I've got my heroes get function and two files. There's a heroes JSON and it shows you how
you can set up this function itself. The only thing I changed was line ten. The rest of the lines got set up for me. I can set up authorisation if I wanted to,
other methods, and in this case, I wanted a route to be called Heroes. I don't want it to be called Heroes -get. The function itself is this. The function, and it generates this code for
you, all you have to do is fill in line 5. Line 5 is what do you want me to do when I
get this route? When I go to /heroes, what happens? Here is the cool part. I wrote this project over in Node and Express,
so when I go and look at my node Express app, here's my hero service. Let me open up my hero service for functions. Does it look similar? It is literally copy and paste, except for
two things: line one Express. That's where I'm go the request and response. Line 1 on the other side. Go and get this context object from Azure
functions. Then you're thinking, what is that other thing
? I just just used restructuring to get response out of context. I copied the files over that Node and Express
and TypeScript, put them in the functions, made two changes, which is super fast to do,
and then I can run my functions app. So let's take a look at this. This app happens to run against both so I
will run a different port just to be explicit. My functions app runs against port 70, 71,
and the Express app runs against 770. We've got another debug configuration up here
for debugging functions and Angular. I'm going to click on that one and press Run
with the green button. Now it's going to run a couple of different
things at the bottom. It's going to make sure that Azure functions
are opening up on your machine. It's got really cool ASCII art setting that
up. It is setting up my routes and in another
window setting up the Angular process. You can see there are four tasks open. It opens some of those to build this app and
then the app loads up here. And once again in the debugger, we can see
that they've got Launch Angular, and I've got my functions. So if I go back and I go to my break points,
and I enable them, which I'm doing by hitting this button right here, and I go back to my
app and I refresh, I'm debugging in Angular, and now, just to prove it's happening, I'm
actually debugging right there in my function app for my code. So all of this allowed me to set up my presentation
API running in functions. What is the other half, though? The other half is making sure my code runs
in storage so I can actually browse to that application. So Angular, as we all know, and we turn off
the debugger, we will kill those within as we all know, Angular has a dist folder, and
inside the dist folder you have all of your assets that you're going to deploy. Mine is called heroes.angular. I did that ahead of time. All I had to do was deploy this to the cloud
is that I can right-click and I can choose deploy to static website right there. Another way to do that is to come over to
this Azure extension for storage, and in the I've got one here called AngularConnect. That created me a minute to create. You have to press the button here to press
one. And then once I created that, you will notice
you upload it and it puts the same assets up inside the storage account. So you can also hit this button here to redeploy
it. If I make changes when I press redeploy, it's
going to ask you where do you want to go, what folder will you look inside of? Again you can do it here. You can right-click on the heroes, deploy
to static website. Again, choose this one here. Notice what it is warning me about. It says the storage container already contains
21 files. If you deploy what's on your machine, it will
delete those and put what is on your machine and put those there instead? I'm glad it is done this because I've nearly
gone over the wrong app. When it's done, I haven't set up a custom
URL yet. You can see this is the storage site that
is hit in the cloud for the heroes application that we are running. Now we've got the app running in storage,
super fast, we've got the web APIs running in functions, super fast, no servers, and
all I need is to set up a custom URL of my own, I can set a CDN up if I want to, and
maybe set up cores to proxy the storage ask the over to the serverless functions. And we saw how everything working through
debugging and VS code. This is important for me, but I don't know
about you, but when I write code, I make a lot of mistakes. When I make mistakes I like to go through
and figure out what is happening. I don't write it right the first time. You can debug your express code locally, and
debug your Docker code, if that's the way you go, locally as well. You can take front-end JavaScript like Angular
and you can debug that alongside your Node Express or your functions app at the same
time inside VS Code. I hope you rethink how some of the apps are
being built and deploying them, for you to go he will back and forth to figure out what
is the right scenario for you. There's no-one scenario. It's choose the right tool for the right job. Challenging our assumptions, three main tips
that I would like to leave you with: consider the presentation API. Maybe there's a better word for this out there
somewhere, but basically, it's another API server that can straddle if you have that
problem all the different APIs that you have to talk to. Consider creating one of those, consider creating
a storage account, and using serverless with it. When you create your serverless functions,
you can create your storage account and tie the two together to build your Angular app
and deploy it to the cloud. If you need more full control over your servers,
absolutely build your own server and ten employ to the cloud using Docker or loose files. It's absolutely fine either way. You've got to weigh the balance between the
cost, and I don't just mean money, but I mean, the cost, the time, the resources and the
effort for building both types of solutions. As promised, if you have any questions in
any of this, you can walk through exactly what I did. There's a static site tutorial up at this
link here. I will post it on Twitter too. It will walk you through creating a static
sight from scratch and I believe it's a React app that deploys to cloud but you can deploy
any app you like. A serverless tutorial where you build a function
from scratch and deploy it to the cloud. If you want to use all the cool extensions
that I had, this AZ tools extension will give you the Docker extension, the storage extension,
the function citizens. It's excellent and it works really well inside
of VS Code. If you want to try pushing it to the cloud,
there's a free link right here. You can sign up to get Azure for free. If you want to learn how to do the Express
app over to functions, because I made a side note where you can build an Express app, I
wrote an article on how to do this, and then of course all the code that I showed, you
can get from this link right here. Sore for all the links. It was a lot of content. I hope you have a great conference and that
you challenge your assumptions this week. Thanks for coming. [Applause].
