Getting started with .NET Aspire - .NET Tutorial

In order to familiarize ourselves with .NET Aspire, let's create an app. Luckily, or rather conveniently for us, the .NET Aspire team provides us with several project templates, including one that shows a fully-fledged application more or less in action. When using the .NET CLI, you can do "dotnet new", and providing the parameter "list" just gives us all of the templates that are our system currently. The list, of course, depends on which versions of the .NET SDK are installed, but by default it's sort alphabetically. So .NET Aspire is at the very top. And you see here that we have five different templates including aspire-starter. That's a starter application for .NET Aspire with several projects. Everything is set up so we could do .NET new aspire starter. And then I do --help because there are a couple of options for that template. You can use --use-redis-cache because that means you would like to use Redis, and you do need a container engine for that. So we are using Docker here, but you could also refer to Podman if you want. You can also create test project for your .NET Aspire app and have a few other settings. If you're using Visual Studio then it might be a little bit more convenient because when you create a new project, then you can filter by .NET Aspire, and then you also get those five templates and the number of the templates and the naming that might always change, or there could be more templates being added in the future or some of them being retired. But the .NET Aspire Starter Application is what we are looking at. And if you choose that, then use a name, how about DiscoveringAspireApp1, and then the settings you see here kind of reflect the command line options you saw previously. So we can enable HTTPS. We can use Redis for caching if you have Docker or Podman running, and we can also create a test project for that. And then if we hit "Create" or if we do the .NET new Aspire-Starter command in the .NET CLI, then we get, well, not just one project, but a couple of projects in a .NET solution or a Visual Studio solution. You see by the bold font here the app host project is the starter project. So let's run that project and see what happens. There we go. Browser is opening up and we get this dashboard here by the way based on Blazor. We have five different parts here. Resources which is shown by default, console, structured logs, traces, and metrics. So we can get super-detailed insights into our application which consists of different parts. So we see here we have a cache which runs on Docker. That's the Redis cache. You will see in a minute what is being cached. Then we have an API. That API returns some data the application is consuming. And talking about application, we have a web frontend and for each of those we can have access to logs, have a detailed view which has just can go directly to the app. So let's go to the web frontend. And the web frontend is an app that you may have seen a lot, because that's the Microsoft Sample app for Blazor, with a Hello, world! homepage and interactive or some counter component, and the infamous weather forecast where 109°F or 43°C is considered chilly. Yes, those values are entirely random. I refresh the page now and just try to remember the first two values here. So we have 26 and 78. I refresh and still the same values. And now the values changed again. So there's caching involved. Caching for about five seconds. That's what we need the cache for. Back in the dashboard we can then have a look at the console output, for instance, for, say, the API service, which is basically what you get in the console when you run this locally. We have structured logs for all of the applications like start processing requests, sending requests, et cetera. And we have traces. That's what I like best. So, for instance, when we were calling the weather page in the web frontend, we required a couple of resources from the web frontend. So, for instance, the CSS and the markup. But we also had to talk to the API service and we can drill down on that. And here you see like a waterfall graph when was which resource loaded and when was, say, a call to the API service being done. So it's similar to the F12 browser tools, but now you get all of that information about your running web application. So you don't need a browser. Any client that talks to a web application will generate data that lands into their dashboard. And then we also have metrics. So we could use any of those applications where we get metrics, including open telemetry data, and then, for instance, the number of active requests. And then can have a graph or a table view and get all of that info here. So pretty nice and pretty convenient, especially for local testing because you get real good insights about your applications.