Request Metrics is a performance analytics tool. As such, we need to build a data ingestion pipeline that will consume performance data and process it. One common approach to ingest is to shove incoming data into a queue. We like simple things, and figuring out fancy distributed queues is anything but. So we're going to eschew best practices and use NGINX as our queue!

Request Metrics won’t be very successful if users can’t sign up! We recently completed cookie based user authentication and distributed session using Redis in ASP.NET Core but neglected initial sign up. Now we finally go back and write some boring forms and CRUD logic. A rich set of internal admin tools helps with customer support, system monitoring and visibility. We’ll start our suite of tools with a user admin page that lists all users in the system.

We need distributed session. Spoiler: We DON'T roll it ourselves. In-memory sessions stop working as soon as there is more than one server. Most production environments have more than one server so the session issue needs to be dealt with. There are two options for sessions in a web farm. First, a load balancer can be used to lock each user on a specific box. This lets us continue to use in-memory sessions. The second is switching from in-memory to distributed session storage.

Core Identity is the officially encouraged method of authenticating users in ASP.NET Core. As you might have guessed, we're not fans of the heavy handed, black box approach needed to make Core Identity "Just work". We want to use as much of the existing ASP.NET Authorization framework as we can while avoiding Core Identity. Thankfully, ASP.NET Supports cookie authorization without Core Identity!

It's time to think about the data model for Request Metrics. We plan to store all customer records in Redis. This requires some thought because Redis is not a relational database. The first thing we need is a user. We'd like to work on authentication soon and we won't get far without a user to login with.

We've started writing code for Request Metrics. That code needs to be tested. We need a unit test framework for our .NET Core solution. We've used various frameworks on our .NET projects over the years, but enough has changed in .NET Core to require a small investigation into unit testing options. Ultimately, we settled on NUnit because of its good balance between simplicity and features.

We thought we were done with infrastructure work. We were wrong. Just as we've started work on application code, it turns out our server configuration needs a couple changes. Our application loads its environment config based off of an environment variable. We need to ensure this variable is actually set on the server. We also want to fix our Ansible playbook which fails when run on fresh servers.

We've finally finished screwing around with basic groundwork. Today we start writing actually useful application code! First, can we connect to Redis? Connecting to Redis implies some connection strings, so we'll create a basic environment based configuration while we're thinking about it.

A pre-built playbook from Ansible Galaxy lets us easily install Redis. (Even we don't re-invent the wheel every time.) The Request Metrics application will use Redis as its main data store. We need to install Redis on our servers to find out if this is a good plan. Ansible provides a repeatable way of doing this configuration work.

Query string parsing in ASP.NET has never been pleasant. The APIs were always a little weird and had some gotchas. Well, in .NET Core, Microsoft has taken another stab at a query string parsing API. Now, remember, they've had over a decade to come up with something better.... have they managed to improve things? Let's find out.