2021-05-20

Github tag 0.7.0.0

OK, made a few more steps forward. Firstly, specifying to run the project 'out of process' discussed in last post, worked a treat in terms of running the Startup class methods at application startup and not at first access. All that was required was adding this to the .csproj file...

<AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>

I left the logic to load the MINST images into the DI services collection in a protected method in the startup class. There was a lot of previous musing about putting this in an implementation of IStartupFilter... but as far as I can tell, these startup filters are run later in the startup process, and the DI services collection is accessible to read, but you can't add to it. Currently all the code concerning pre-caching of MNIST images is encapsulated in the Startup.SetupMnistImageDataStructures() method, and I'm happy with that.

In addition, I've made the following changes...

I've changed the setting of the IApplicationBuilder.ShowDeveloperExceptionPage option to take a boolean from config. I don't really like this idea of having fixed dev/staging/prod environments... although that's likely what you'll have in the real-world in 90% of cases, who's to say I won't want to spin up secondary (or tertiary) staging environments for specialized testing etc... and in that case, what if I want to vary options between those environments? Anyway, again, happier with this approach for now.
I created an MnistImageLabelIndex container class (basically a wrapper for a Dictionary), so that I don't have a store a generic Dictionary<Int32, IList<Int32>> in the DI services collection, and therefore block storing of any other Dictionary<Int32, IList<Int32>> instances.
The MnistImageStore project has been updated to .NET 5.0 - This initially created problems because apparently System.Text.Json doesn't support serializing multi-dimensional arrays (and the MnistImage classes' image data is a 2D byte array)... but was simply fixed by just changing back to Newtonsoft.Json with this statement in Startup.ConfigureServices()...

services.AddControllers().AddNewtonsoftJson();

I wanted to document all of the next steps / outstanding things, as there are quite a few of them, and writing them here gives them some permanency...

Item	Notes
Cleanup of MnistImageController routes	Don't like having consecutive numbers in Label/{label}/{index}... because looking at an actual URL (not the code), how do you know the meaning of the 'index' parameter? Something like Label({label})/{index} could be an option, but also has some drawbacks. I'm starting to lean towards using OData for these type of 'secondary' query/filtering of a resource endpoint.
Versioning	Reviewing the suggestions in the MS API Guidelines, and I expect I'll use the ASP.NET API Versioning libraries.
Logging	I reviewed the doco for the stuff built into ASP.NET Core and it looks pretty comprehensive, so will likely go with that.
Metrics	Likely I'll use my own ApplicationMetrics project for server-side metrics capture. Doing this will also force me to update that project to .NET Standard.
Pagination	Will probably tie in with the 'Cleanup of MnistImageController routes' mentioned above, as I can likely leverage OData filters to control the pagination and also help to cleanly define a continuation URL.
Swagger	Want to have clean/detailed Swagger defined for the API surface.
IMnistImageReader implementation for AWS S3 and/or Azure Blob Storage	To be ready for cloud deployment.
Deployment	Get a basic automated deployment pipeline setup for AWS and/or Azure.