As I continue to build out some reference architecture applications, I realized that there was a great deal of boilerplate code that I add to my APIs to get things running. Time for a library!
Enter the “Platform”
I am generally terrible at naming things, but Spydersoft.Platform
seemed like a good base namespace for this one. The intent is to put the majority of my boilerplate code into a set of libraries that can be referenced to make adding stuff easier.
But, what kind of “stuff?” Well, for starters
- Support for OpenTelemetry trace, metrics, and logging
- Serilog logging for console logging
- Simple JWT identity authentication (for my APIs)
- Default Health Check endpoints
Going deep with Health Checks
The first three were pretty easy: just some POCOs for options and then startup extensions to add the necessary items with the proper configuration. With health checks, however, I went a little overboard.
My goal was to be able to implement IHealthCheck
anywhere and decorate it in such a way that it would be added to the health check framework and could be tagged. Furthermore, I wanted to use tags to drive standard endpoints.
In the end, I used a custom attribute and some reflection to add the checks that are found in the loaded AppDomain
. I won’t bore you: the documentation should do that just fine.
But can we test it?
Testing startup extensions is, well, interesting. Technically, it is an integration test, but I did not want to setup playwright tests to execute the API tests. Why? Well, usually API integration tests are run again a particular configuration, but in this case, I needed to run the reference application with a lot of different configurations in order to fully test the extensions. Enter WebApplicationFactory
.
With WebApplicationFactory
, I was able to configure tests to stand up a copy of the reference application with different configurations. I could then verify the configuration using some custom health checks.
I am on the fence as to whether or not this is a “unit” test or an “integration” test. I’m not calling out to any other application, which is usually the definition of an integration test. But I did have to configure a reference application in order to get things tested.
Whatever you call it, I have coverage on my startup extensions, and even caught a few bugs while I was writing the tests.
Make it truly public?
Right now, the build publishes the Nuget package to my private nuget feed. I am debating on moving it to Nuget (or maybe Github’s package feeds). While the code is open source, I want to make the library openly available. But until I make the decision on where to put it, I will keep it in my private feed. If you have any interest in it, watch or star the repo in GitHub: it will help me gauge the level of interest.