It’s important to weigh-up the saga/message-based approach to the initial version of the system. The former scales but the latter is much simpler. Experience helps inform us when it is time to transition from one design to the other.
Very helpful, thank you. I have a couple questions: 1. Say you have a UI where you can create an order. With the coupled backend, you might be able to return the label immediately since everything occurs in a transaction. How do you handle this when you switch to microservices? 2. Where should sagas live? API Gateway? If so, would you recommend the gateway talks to microservices over RPC? 3. Is fetching logic (e.g. here's an order id, get me the label and billing info) in a saga as well?
1 - Dealing with async workflows just means providing the user with what is actually happening. If they place an order and it's initial state is "Processing". Then that's the state you show them and details about all the steps in the workflow. 2 - Saga should live in the place that's doing the orchestration. In my example of an order, in the sales since that's where the orchestration of the order is. 3 - Saga should just be consuming events and publishing commands. It shouldn't be fetching data or doing anything beyond knowing the workflow based on the series of events.
@@CodeOpinion I think that for point 1 he needs to push notifications to the UI, something like SignalR perhaps. But the thing i dont know if its necesary to keep the socket always connected or only use it in special cases like this and when the order is created, disconnect from the socket. What is your opinion?
@@matiascasag Yes, you can use something like SignalR to notify the client when something has finished processing via an event. Often times as well you can just use polling to know if an operation has completed. Really depends on the situation
There's many different options. It could call back to the publishing service to get more data/info. Another option is to include it in the event. However you may not want to do either and prefer to use orchestration to send a command to billing rather than an event. Check out my video on Event Choreography and Orchestration: czcams.com/video/rO9BXsl4AMQ/video.html
With microservices everything becomes complicated. For a small team, dev ops, database back ups, and monitoring the entire system would become really hard. What are thoughts about this?
I don't think you start with microservices. I think it's an evolution of your system, ultimately because of Conway's Law. I really do think creating a Loosely Coupled Monolith (as in my series) is a better approach as you can carve off sections more easily as required by your org.
The whole point of a microservice architecture is that its difficult to get set up to start with, but ultimately once everything is in place it's far easier to manage. This ease becomes more prevalent when you use more good coding practices like TDD and clean architecture.
I can't learn so much good and free content without being at least a member. Fixed. Thanks for sharing, Derek!
Thanks a lot!
It’s important to weigh-up the saga/message-based approach to the initial version of the system. The former scales but the latter is much simpler. Experience helps inform us when it is time to transition from one design to the other.
Thank you for all of your content. It's help me a lot
Yaa, very useful to me. Thanks 😍
This is awesome
Another piece of great content! Saga seems pretty neat -- I will have to check it out.
My examples are using NServiceBus in the Loosely Coupled Monolith sample app. There's a branch for NServiceBus if you want to play around with it.
Amazing Video :)
Thanks!
Splitting up a Monolith to (micro)Services Great, thanks man, keep going
Thanks, will do!
What do you think about having all of the routes in one file?
Very helpful, thank you. I have a couple questions:
1. Say you have a UI where you can create an order. With the coupled backend, you might be able to return the label immediately since everything occurs in a transaction. How do you handle this when you switch to microservices?
2. Where should sagas live? API Gateway? If so, would you recommend the gateway talks to microservices over RPC?
3. Is fetching logic (e.g. here's an order id, get me the label and billing info) in a saga as well?
1 - Dealing with async workflows just means providing the user with what is actually happening. If they place an order and it's initial state is "Processing". Then that's the state you show them and details about all the steps in the workflow.
2 - Saga should live in the place that's doing the orchestration. In my example of an order, in the sales since that's where the orchestration of the order is.
3 - Saga should just be consuming events and publishing commands. It shouldn't be fetching data or doing anything beyond knowing the workflow based on the series of events.
@@CodeOpinion I think that for point 1 he needs to push notifications to the UI, something like SignalR perhaps. But the thing i dont know if its necesary to keep the socket always connected or only use it in special cases like this and when the order is created, disconnect from the socket. What is your opinion?
@@matiascasag Yes, you can use something like SignalR to notify the client when something has finished processing via an event. Often times as well you can just use polling to know if an operation has completed. Really depends on the situation
Where can I get the code? for both Mono and micro
How billing can know which customer to charge knowing only order id? Should it make a request to sales for customer id?
There's many different options. It could call back to the publishing service to get more data/info. Another option is to include it in the event. However you may not want to do either and prefer to use orchestration to send a command to billing rather than an event. Check out my video on Event Choreography and Orchestration: czcams.com/video/rO9BXsl4AMQ/video.html
What do you mean by "saga"?
Check out this video: czcams.com/video/rO9BXsl4AMQ/video.html
With microservices everything becomes complicated. For a small team, dev ops, database back ups, and monitoring the entire system would become really hard. What are thoughts about this?
I don't think you start with microservices. I think it's an evolution of your system, ultimately because of Conway's Law. I really do think creating a Loosely Coupled Monolith (as in my series) is a better approach as you can carve off sections more easily as required by your org.
The whole point of a microservice architecture is that its difficult to get set up to start with, but ultimately once everything is in place it's far easier to manage. This ease becomes more prevalent when you use more good coding practices like TDD and clean architecture.