davidajohn / fotostoriomicroservices Goto Github PK

There are several Services projects that have controllers which contain try...catch logic. It makes me feel a little uneasy seeing 500 errors being returned in so many of the catch sections.

I'd like to get rid of that repetitive code and use some form of exception middleware instead, which would make the controllers simpler and centralise exception handling and logging.

Something like Jason Watmore's solution would be ideal: https://jasonwatmore.com/post/2022/01/17/net-6-global-error-handler-tutorial-with-example

While updating the Admin.BlazorServer UI project, I noticed the admin page which shows customer orders provoked a 404 from the Ordering API (via the admin gateway) because there are no orders in the database (or none in the last x days).

I'm not sure this is the correct response when there are no orders to return, but there can be huge debates over this.

Ultimately, what does the CustomerOrders.razor page need to do? Is there value in returning a different response when there are no orders to return, as opposed to when there is a problem retrieving the orders?

It's no secret that Ocelot is no longer being actively developed and Tom Pallister himself has suggested people use alternatives like YARP, although he has said he will update Ocelot with each new version of .NET.

FotoStorio has several gateway projects that currently use Ocelot for routing requests to different services on the back end. They all function without any problems, but YARP is probably a better long-term option given that it is actively maintained by Microsoft and used internally by them.

I'll try creating a gateway using YARP instead of Ocelot to see how the amount of work involved stacks up against the benefits moving forward. I would imagine there may be speed and memory usage benefits to using YARP, as well as the obvious future-proofing.

It's probably time to start thinking about which projects would benefit from being upadted to .NET 7.

Anything involving Entity Framework should be stringly considered, given the performance gains.

Also the Discount minimal API would be a good candidate.

After quite a bit of experimentation, I've hit a brick wall trying to write integration tests that run against a real instance of SQL Server (or at least, a 'real' SQL Server instance created using Testcontainers from inside a WebApplicationFactory).

Whatever I try, I always end up back in the same situation where I get an error from Entity Framework about the entity already being tracked. I've tried just about every suggestion I've found on Stack Overflow and elsewhere, and the outcome always seems to be the same. There comes a point where everyone stops trying to get this to work and looks at an alternative involving an In Memory database and/or SQLite.

For reference, here's an example from Microsoft's own sample projects.

I'm not particularly keen on that approach because you're not testing against the actual database and there are issues with LINQ.

Microsoft have an absolutely insane suggestion which involves running tests inside a transaction and then rolling it back afterwards, to avoid any commits being made to the database. That seems like a tacit admission that there is no way around these EF tracking issues. It also just relies on an existing database, rather than having some kind of automatic creation and teardown.

Here's a potential alternative which uses the Docker.DotNet library:

.NET Core Integration Tests using a Sql Server Database in Docker

It's time to gradually update the application to .NET 8, even if it's just a case of switching to the new v8 libraries for now and implementing new features later.

Anything that can help improve speed and reduce the memory footprint of each microservice has to be a good thing.

It was always my intention to create a simple client application that enabled the creation of marketing campaigns and discounts.

There is a marketing gateway already built and the backend functionality is available in both the Discount minimal API project and the Discount gRPC project.

It really only needs to give a fictional marketing dept the ability to create a campaign with start and end dates which includes a selectable list of discounted products.

I could build something using Blazor, but I'd always wanted to demonstrate how to add something different to the mix, so the feasible options for me are:

Blazor (Wasm or Server)
Angular
Next.Js
Vue/Nuxt

While updating the version of AutoMapper used in parts of the application (in order to switch to the non-DI v13> package), it occurred to me that perhaps the Discount Grpc project should be using a custom mapper class instead - which should be quicker (but slightly less convenient).

Otherwise, we're potentially losing part of the speed advantage that Grpc offers.

The store's product details page currently has a hard-coded limit of 5 items.

The idea of allowing more than one to be bought is obviously a little contrived for a store that sells high-cost goods like cameras. Plus, why would anybody buy two of the same camera/lens?

But, given that we have an inventory API with current stock for each product, it would be good to link this up and set the limit to however many are in stock.

At the moment, the application consists of a mixture of .NET 5 and .NET 6 projects.

The Blazor client apps are .NET 6, but most of the backend services are still .NET 5.

It's not a huge problem, but it would be nice to have everything consist, especially as .NET 6 is the LTS release.

The first step would be updating the version numbers in the .csproj files and testing that each project still builds successfully.

I'd like to make it a requirement that an email address needs to be confirmed when registering.

I think using a service like SendGrid may be the answer.

Their C# library can be found here: https://github.com/sendgrid/sendgrid-csharp

There are a couple of unrelated issues with the Application Status project which uses the built-in .NET health checks generated by each project:

1. There is a cosmetic issue where a particular font isn't being loaded after the update to .NET 8. It appears to be a relatively simple fix involving the webpack config. There is an open issue containing a PR waiting for the contributor to agree to the CLA. I'll leave it for now as this isn't vital. It's just to show the icons in the UI.
2. The projects that have been updated to .NET 8 are all showing as being down (when they are not). Is it related to the default port changing to 8080 from 80? Microsoft's docs on Health Checks are here

There is a security issue with the Identity API's Accounts Controller. This is during the registration process where there is a check for existing email addresses in the database.

This was corrected recently in the monolith version of FotoStorio and needs to be implemented here too.

The commit is here: Refactored code related to login and registration

I'd like to update the Identity service project.

One option would be OpenIddict: https://documentation.openiddict.com/

Although Serilog is now being used to log to a Seq instance from the vital backend services like the Products API and the Ordering API, having done that it feels like the entire application should probably be doing the same as well.

Seq's UI is fantastic for filtering logs by application/service (among many other things), so although we may not need the full power of Serilog's structured logging of objects for the other services, there is still a lot to be said for having all logs available in one place, especially for an application with this kind of microservice architecture.

An addition that I'd like to make to the application is to add Serilog to at least some of the services - definitely to the Ordering API and the Products API at least.

This would probably only need a few additional nuget packages and perhaps some minor alterations to the logging statements. Sinks for the console and Seq would likely be sufficient.

I'll then add a Seq container instance to the application based on the official Docker image.

There are some breaking changes that have been introduced with the .NET 8 Docker images.

While testing, I found that several services that had been updated to .NET 8 where no longer responding, although no errors where visible in the logs. I quickly discovered that I'd missed a memo about the default port changing from 80 to 8080.

There are some other changes as well, which Andrew Lock has explained excellently, as ever:

https://andrewlock.net/exploring-the-dotnet-8-preview-updates-to-docker-images-in-dotnet-8/

Also here's a practical example of a .NET 8 app that uses docker compose:

https://www.yogihosting.com/docker-compose-aspnet-core/