Microservice architecture

[alindgren]

Perhaps use RabbitMQ? https://www.rabbitmq.com/

Check out https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/

[alindgren]

Decision: use RabbitMQ over NServiceBus so that we have the option of integrating microservices in other languages.

See if it's possible to create a layer that uses DI to optionally not use RabbitMQ. Perhaps create separate libraries that contain Mediatr handlers - one that uses RabbitMQ based microservices and another for handling the logic internally (or calls microservices synchronously).

[alindgren]

https://vimeo.com/183448835

Use Event Sourcing? https://eventstore.org/?

[alindgren]

Next step: move Requests and RequestHandlers into their own libraries.

Maybe Requests can go in Fundraise.Core, and have the existing RequestHandlers go into a new library (perhaps RequestHandlers.InProcess) with the goal of creating another library of request handlers that use RabbitMQ (perhaps RequestHandlers.RabbitMQ).

[alindgren]

MediatR requests and requesthandlers have been moved into their own libraries (Fundraise.Requests and Fundraise.RequestHandlers.InProcess). The "InProcess" handlers (maybe not the best name) are for the non-microservices (monolithic) version of the app. Next step is to add microservice versions of these request handlers.

Perhaps the microservice hanlders should be divided into two types: synchronous (HTTP-based) and asynchronous (utilizing RabbitMQ):

The two commonly used protocols are HTTP request/response with resource APIs (when querying most of all), and lightweight asynchronous messaging when communicating updates across multiple microservices.

from https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/communication-in-microservice-architecture

So next, create a project for handlers that use microservices (Fundraise.RequestHandlers.Microservices?). Perhaps first implement everything using synchronous communication by creating a WebAPI app. Basically move the logic in the handlers to the WebAPI and then have the handlers call those WebAPI methods. Then I can introduce RabbitMQ for updates/inserts. Queries should, I presume, should continue to use the WebAPI.

[alindgren]

As much as I would like to dive into microservices, I think that it makes sense to build out more of the functionality and look into using notifications with MediatR.

But maybe start small with a couple simple async microservices such as one for sending email notifications and one for logging donor events. These could be implemented while leaving the rest of the example app as a 'monolith'.

Update: Logging should probably be done within the service and aggregated using something like ELMAH https://elmah.github.io/.

Initial microservices should target integration. I think it would be easy to start with Airtable's Individual and Corporate Donations template and then do QuickBooks Online.

[alindgren]

https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/multi-container-microservice-net-applications/integration-event-based-microservice-communications

Probably should inherit from something like IntegrationEvent to create an ID and timestamp for each event object.

Each microservice should define it's own events though:

What is not recommended is sharing a common integration events library across multiple microservices; doing that would be coupling those microservices with a single event definition data library