Nice one! Agree with all the others :) Good subjects, clear focus, simple explanations/presentations, good sound! Seeing this after the video on the Outbox Pattern it would make sense to me to use Brighter for both instead of Brighter in combination with Hangfire/CAP. Could I hear your thoughts on which technologies you would combine if you were to create a solution from scratch?
It honestly depends on the needs/requirements and extensibility of the library you choose. It also depends on which transport and storage you're using and which libraries support what. For example, you might want to use NServiceBus but you also want to use Kafka. Well that won't work as it's not supported. So you either decide to use a different transport, maybe RabbitMQ with NServiceBus. Or you choose Kafka and use something like Brighter or CAP. It really depends on the feature set you need, which transport and storage your using.
HI, this is great content, although there is a concern I have with this approach. For example what would be the best approach/solution to update client side data as soon as the entity is updated from out-of-process runner/executer ? Also what is the best approach to not allow a user to actually edit more than once same entity until the first editing process is finished from the executer ? Shall you query the store(in this case would be RabbitMQ, redis or sth similar) whenever u are editing an entity or there are better approaches ?
For updating the client once the out-of-process message has run, one solution is notifying the client via an event. In my example, the PlaceOrder command once completed would publish a OrderPlaced event to the message broker. This event would get picked up and then notify the client say via SignalR. This type feedback loop is pretty common.
Do you know if it's possible to use Brighter to handle both in-process commands (as a replacement to mediatr) in some areas of a project, and make out-of-process commands elsewhere? Is this just differentiated by using .Send() vs .Post()?
I agree with the rest of the other comments, great content! What do you think about using the Actor Model as a different approach to tackle this scenario?
Similar in some ways but different in others. You'd have a large # of consumers/actors (and producers) but they are processing work synchronously per actor, which you may or may not want. I guess it depends how you partition.
We use Orleans for enterprise level scaling that virtual actors provide, but it's overkill for our small to midsize companies. This approach appears to be a good alternative to a full actor environment, but as always, you need to pick the right tool for the job. We're also looking at MS's Dapr to fill this role.
@@ivcbusinesssystems6613 I've used Akka.Net for a project and I like it a lot. As you said, it is a bit overkill for smaller applications, but you can pick the features you want to use. I heard about dapr, but it's not production ready yet. Another tool I'm interested in using is MassTransit
@@fromano280272 Yes, we used Akka.net first, it's a more pure actor framework than Orleans, but the virtual actor design was the game changer for us. Yes, dapr isn't production ready, and doesn't look like it will be for awhile, so it's in our planning stage right now. I'm just glad to see so many great high level tools/systems coming available, we used to have to build all of this from scratch!
