✅ Event-Driven-Architecture Cons Issue
i have a microservice project as a backend and spa as frontend. I have some question while designing my service. When a user on a checkout page after pass the payment process which is a microservice a command will be thrown in the service to the order service. Order service will consume the command and save the order information to the database. My question is after the payment is processed normally, order information id,name,date etc. will shown to the user. But in this scenario (Event-driven-architecture) my frontend does not wait the order API response where my order information will be fetched. So how am I going to show the user it's order information after checkout process ?
technologies;
- Angular
- .Net
- PostgreSQL
- rabbitmq(masstransit)
10 Replies
So you basically asking that you publish an event triggered from UI but its not request-response model, its just fire the event and its done on UI. You asking how do I notify UI back once the event is consumed ?
One option is polling, UI can fetch the status periodically or signalR where UI will be notified once the event is consumed
And best option is why not just wait the response on UI ?
you should think of having a websocket to receive events, there aren't really that many other ways to do this
If the user is going to wait on the result of the action then using commands doesn't make sense. Just update the db and return the info in the response to the same request. The user will also then know if the order failed.
Commands are useful when the user doesn't immediately care about the result - for example generating the tracking number for the order.
i believe what he is trying to say is that the details will be available after the request has already ended
basically e-commerce websites when you order something after ordering you will be shown the order details and what i want to do is that. But also making this action async what i am trying to do. After my research i get the same results as you guys. In addition to these solutions i found out there is another way called sse (server-sent-event) which is linkedin and twitter uses it. I guess this will be the best option for me. What do you guys think ?
or instead of making order service async using rabbitmq, i could use grpc between checkout and the ordering service.
sse is one direction only
yes that's what i needed
I will send request to client just to get the order informations
as long as you not use it just as return value of a method
yes i know and it seems at first will only need for the fetch the order informations after checkout
thx for the help guys
an event would - roughly - have a context and bring the ui in a next phase of the whole process (for example payment ok or not), the "fetch order information" would be is included in that