Presentation: Developing Great Web APIs Architectures w/ ASP.NET Core 2.1

Over the last five years, I've been busy getting solutions out to people. I work more on the backend doing API work, but that’s also meant I help mobile application and web application developers utilize the APIs I’m developing.

The motivation came from my mistakes building APIs that I've done over the last four or five years using REST. I don't want other people to make these mistakes, because they cost time, money, energy, they add to frustration around projects. I try to teach people how to build these APIs well with good patterns that can be reproducible and you can do over and over again for all your API projects, especially around .NET Core.

A lot of these ideas can be used on any other platform but I'll give specific examples on using .NET Core and ASP.NET Core Web API.

A big one is coupling all of your different parts of your API so that you can't test well (both unit testing and integration testing). I try to architect my APIs down to a point where I can unit test very granular pieces to make sure that things work. And then also I can replace things. My big thing is I want to test and refactor quickly. I use dependency injection also to allow me to build out new areas of my architecture that I can swap in and out quite easily and without a lot of friction.

I'm gearing this towards tech leaders and architects (CTOs that are a little more hands-on and maybe even project managers might get something out of it). But really this talk hits on those technical people that need to think about architecture, build out, and then build that testing plan for the APIs. I'm really looking at the people that get their hands dirty. While everyone can get something out of it, I primarily look at senior tech leads and architects.

This is an advanced talk. You have to come in knowing something about web APIs and building those type of projects.

It's a total rewrite of .NET.

If I take a look at ASP.NET, we as developers have had a lot of legacy, a lot of baggage that we've had to pull around with ASP.NET. If you've ever done ASP.NET web development you know System.Web is huge, because it has everything going all the way back to ASP.NET 1.0. It has web forms and stuff that we wrote don't really need today. If you're not doing web forms why have a library around that supports it when you're not using it? There's many other things with ASP.NET. That’s the first thing. We're getting rid of a lot of old baggage that collected and deposited over the years.

The second is cross-platform, so .NET Core can be not only developed on Windows, Mac OS, and Linux, it can be run out on all 3 platforms. It can be run very well on containers, Docker and Kubernetes. That's another great advantage. I can write a .NET Core web API, throw it into a Linux container, and then throw it up on both Azure and AWS. As long as they can use it, I don't really care where it's being run.

The other thing is they've taken a look at what they should have done with .NET and ASP.NET, things like building dependency injection into the actual framework. Now we have dependency injection right out of the gate. It's built in, it's easy to use, you don't have to use third party tools, and do all the configuration / ceremony around those. You just get it and then you're flying, and you can inject things in where you want them. Those are the big areas that I see.

There's probably lots of other ones that other people like (for example, it also has the command line, so you can work with visual tools as well as a CLI now). But these are the things that come to mind for me.