 Hi, my name is Glenn Condren. I'm a program manager on the ASP.NET team. Today, we're going to talk about some of the good features coming up in ASP.NET Core 2.2. We're going to specifically talk about a few of the features we have that build together really nicely in order to help you build APIs. APIs are everywhere, most of your applications probably have a couple floating around and so in 2.2, we really wanted to focus on making that experience better. We're going to talk about APIs, our analyzers, and our conventions, and we're going to talk about health checks as well, and so bringing a little bit of cloud native microservices in here. Then at the end, we'll have some links to where you can get started, where you can find more information, and where you can see a demo app that shows off every feature that we talk about, plus a lot more that we won't have time for today. So let's get started with some demos. So here, we have an ASP.NET Core API project. What it is, this is a startup class, and all we do is we add MVC. We say that we're using the 2.2 version for compatibility switches. We add some swagger. If you're not using swagger, swagger is a way to document your APIs and show other people that other people consume your APIs and knowing the sorts of things that your API does. It describes it, it tells everybody about the things that you're going to return, and the things that they can do with your API. Then we add an identity framework here with this section of code, and in this case, we're also starting to use this net topology suite, which is the beginnings of using a new feature in EF Core 2.2, their spatial types. We don't talk about it much, but it is a feature that you can check out if you're interested in it. At the end here, we add the necessary services to be able to do health checks in ASP.NET Core 2.2, which we'll talk about a lot more later. So to begin with here, let's open up the browser. Now, I have the browser open to my application running, and it is hitting the swagger slash swagger endpoint. If we go back to our startup CS, just here, we say this line of code adds this swagger endpoint that I'm hitting that displays swagger UI. What swagger UI lets you do is, describes your application, it shows you me the endpoints that I have in my app, and it describes the models that my application can return. So in this case, I have a place's controller. It has a get that returns a list of all the places that I have in my database, and it has a get by an ID which returns a specific place. Then if we look at the swagger UI for that, then it has the places. I can try it out, I can execute this, and it returns me a list of places from my database here in the browser, so I can test out my API. I can also try it out by passing in a parameter. Now we're going to say, let's execute one. Now, if you look up here in my dataset, I don't actually have my IDs are good, so there's not going to be a one. That's interesting because the UI says that the only things that this API could respond with is 200 okay. But we know that's not true because right here, it's returning a 400 and it's returning this type, some type here, which is not documented in any way in our swagger. Now, the reason for that is that in order for the code to generate the swagger document from my code to know what my API does, I need to give it some attributes. So in here, you need to add more information telling the swagger generator what stuff it does. So in 2.2, we added some stuff to try and make that easier. We did that by having a package that I'm going to uncomment here. This is ASP.NET Core MVC API analyzers. What these do is augment your tooling experience to let you know when you're doing things that aren't documented. So if I build my project now with this new package ref, and I come down here and I look at my warnings, you'll see I have this action method returns an undeclared status code 404. If I go into my actual method, then what I see is return not found has a squiggly line, and it has a squiggly line because I'm not documenting the fact that I'm returning this not found. So if I control dot on this, it'll say, hey, let me add all the attributes that it looks like you're doing here. It's saying, okay, you're going to return a 200, you're going to return a 404, and you're going to do this produces default response type. So if we just do that, we control dot and then save our file. Then if we head back over here to our swagger endpoint, then what we'll see is that we now have this new model, this problem details model, which is another feature that we added in 2.2. Problem details are basically a type that we will return that describes what went wrong when something bad happens, or when you don't tell us to return something else will return a problem details when there are problems. It's just a structured way of giving information back to people who aren't humans necessarily. So you could parse this and you could understand it when you're writing a client that talks to this API. So now that we've added those attributes, the swagger document now knows that we could return a 404, we could return a 200, we could return default. It's pretty cool, you get some good, this just gives you hints, it gives you help when you start doing stuff. But adding all of these attributes to every one of your APIs adds a lot more boilerplate code to your controller and we like to try and avoid that. So over here in our program CS, we can see another feature that we added 2.2.2, which is the concept of API conventions. So with an API convention, what this is saying is add to this whole assembly an API convention type of default API conventions. We ship this type and you can ship your own. If you wanted to, you could have this code in here with any type that you want that implements this stuff. And if we go to the definition of this type, we can see it has a lot of method declarations with a lot of attributes. And so if we look at our get one, because that's what we've been looking at, then this says name match prefix. So this is saying any methods in my application to start with get and have an ID have something with an ID suffix. So this could be place ID or something like that. Then apply these attributes to it, those default attributes because if you've got a get that accepts an ID, you're probably going to return a 404 when that ID doesn't exist. You're generally going to return a 200 when it does when it is there. And we know we're going to do the default response type stuff because that's what we do now in 2.2. So now without any attributes in my controller, if I go back to my swagger document and hit the same endpoint, then I'll be able to see the same thing that we just saw, where I'll be able to go to places, go to places ID. Now I have this 200, I had documented that I've done a 404, it's documented that I've got a default. So if you are following some patterns or guidelines within your organization that either are the same as the ones that we ship or are different but are fairly consistent or you want them to be consistent, this is a really good way for you to get reminders and hints and help around getting the right things into your app. Now, one thing is that we do not give you warnings and squigglies if you give more information than what you return. So it's not a warning from the analyzer's point of view, if you say that you return a 404 but there's no code that we can tell to actually do it. That's us walking the line because sometimes it can be difficult to know exactly what you do and we believe that over specifying information is good, it's okay, but underspecifying is really bad. So we want to give you help to under for when you're underspecifying, but we're not really worried when you go out when you say more than what you're actually going to do. Okay. So then the other feature that we saw in our startup CS was health checks. So this is a new feature that we added specifically around building using load balances, deploying to things like Kubernetes, using the power of a cloud like using Azure or one of the other clouds. So and the reason for that is you frequently want to be able to ask your application, are you okay? Should I send traffic to you? Should I restart you? You can do that today, you could make a controller, you could put an endpoint on it, you could make it that controller's job to report the health of your application. But that's a fairly common pattern and you writing the code to check all of your dependencies potentially, it can be some time consuming. So we wanted to just remove that from something that you needed to think about. So we have a service, you can add this health check service. This gives you a service that you can consume in your application like any other service that's added to the DI system. So you can go manually invoke this to check whether you're healthy within your app if you wanted to. Then we also add this DB context check. So what this is going to do is, if I ask the health check system, are you healthy? If it cannot connect to the database that this context is configured to talk to, it will say no, I am not healthy. If it can talk to it, then it will say yes, I am healthy. What that lets us do is, we have this middle where you can add to your application saying app.useHealthChecks slash ready in this case. What that means is if I go to slash ready in my application, then it says healthy because I have a Docker container running on my machine that's running SQL Server and my application is communicating with them. If I was to go and stop that container, then it would return unhealthy. Right? Makes sense. So this is interesting and it's valuable for things like, if I was going to load balance to this application, I was going to have several instances of it and I was going to put say an Azure Traffic Manager or any load balancer in front of those several instances, and then route traffic to them. Say on geographical location, maybe you want to deploy an application to several regions of the world and you want to prefer the locations that are closer to any customer that's going to come to you. Well, you need an endpoint that your load balancer can know, don't send traffic to this one because it's now down. In order this lets you do that, you just tell the load balancer the slash ready endpoint is going to be the one that you hit in order to tell whether or not this app or API is ready and we are going to use that. Now, where this also becomes really powerful is if you have a file that looks like this guy, this is a Kubernetes configuration file, then just here we have the concept of a readiness probe. Now, a readiness probe in Kubernetes means that if those two things it will do very importantly, so let's talk about them in order. If you're doing a deployment, you're deploying a new version of a service that you have running in Kubernetes and the readiness probe never says that it's ready, that never returns a success at 200, then the deployment doesn't continue, but just sits there and waits for somebody to resolve whatever that problem was. So for example, if you add a new dependency to your API and you forget to deploy that dependency as part of your deployment but you do add it to the health check system for the ready endpoint, this will be caught and you will know, and you won't be able to actually finish that deployment. The other thing that readiness probes do in Kubernetes is they will not route any traffic to you just like a normal load balancer scenario we talked about if this area ever returns false. So super powerful for Kubernetes, it plays into what is built in here. The other concept that Kubernetes has is a live-ness probe. So in here, we could write a live-ness probe and we could do exactly the same thing that we just did, we could do a HTTP get and we could add a new another path. Now, generally what we want here is, we don't want to do the same exact path, we don't really want to say slash ready, because the difference here is that when a live-ness probe returns unhealthy, Kubernetes restarts it. So we really want a different set of checks to be available on readiness versus ready. So the way that you would do that is, in your startup CS, you would add a second use health checks middleware in here and you would name all of your checks and then in your options for use health checks middleware, then you would only run the ones that made sense. So you can add a new health check options in here, and then you can configure how that works. When adding health checks, you can name them and you can add tags to them in a future version, which will let you tag health checks and then only execute subsets of them for when you want to do the different tasks. But we expect readiness to be the mainline, the one that the vast majority of people need in all sorts of scenarios and liveness is interesting as well when you're in other places where somebody is monitoring you and wants to reset you. So the last thing that we should mention is, you noticed over here in the CS Proj, I have this new ASP.NET Core Hosting model up here and says in process. Now in process ASP.NET Core Hosting means that when running in IIS you should see significant performance improvements because of us running within the IIS process. Instead of as today, we start up a second process and we send all the traffic over. So those of you using IIS today with ASP.NET Core should get some pretty significant perf improvements by switching to this model. And yeah, that's all of our demos today. Okay. Thanks for watching these demos. Here's a few links to help you learn more and get started. This first link here is how you can download all of the pieces you need to be able to run ASP.NET Core 2.2 and .NET 2.2. We have a link here to a demo, to a sample app with all these demos came from. So on GitHub, you can send pull request log issues, talk about it, ask about it. It's there as a resource for everybody to learn. And it is really supposed to be about learning, not about shipping it to production. So it has lots of stuff, but it shows off all of our features really well. And then these last couple of links are our blogs. Almost nothing that I talked about today would be a surprise. If you had been following along, reading the announcements, we show code, we talk about roadmaps. We post there fairly regularly. So if you want to follow along in the future, then check those out and read some more. And thank you for watching. Have a great connect.