Frontend and Sagas

260 views
Skip to first unread message

Murilo Carlos Cardoso

unread,
Aug 30, 2020, 8:54:26 AM8/30/20
to ddd...@googlegroups.com
I'm looking for strategies about how the frontend can deal with sagas and CQRS (not event sourcing). Do any of you have some references or something to share about it?

About CQRS, I think that a version in the aggregate can help. Every command returns the new version. So the frontend can get the information using retry strategie until finding the version in the read side.

About Sagas I think that it's a little bit more complicated, maybe some kind of "server to client communication". I have some ideas but I would like to hear and read more about it.

Thanks! 

( the tech stack for the backend is java/spring/rabbit/postgres and for the frontend is typescript/angular/rxjs )

Mauro Servienti

unread,
Aug 30, 2020, 9:05:56 AM8/30/20
to ddd...@googlegroups.com
Can you better describe what problem you’re trying to solve?
“frontend can deal with sagas and CQRS” is a bit vague.

Cheers,
.m

--


You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.


To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.


To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/CAH7D42TOvNVUUpV8aajmsszgr_Ahb_wZSXXo5gHdncm6EKDaqg%40mail.gmail.com.


--
Mauro Servienti

Murilo Carlos Cardoso

unread,
Aug 30, 2020, 10:15:59 AM8/30/20
to ddd...@googlegroups.com
When the user hit a button in the frontend, the long running process (saga) start to process, after hitted the button the aggregate changes its status. The aggregate can change among different status. How the user can follow these changes?

The user could be seeing just the instance that he started the process OR multiple instances that are being changed their status.

The saga could last some few seconds and would be ideal not refreshing the whole UI.






Mauro Servienti

unread,
Aug 30, 2020, 10:35:31 AM8/30/20
to ddd...@googlegroups.com
Correlation ID is the key concept in this case.
When the client sends the first request appends a unique identifier. This unique identifier is transmitted with whatever “message” exchange happens in the backend (e.g. in saga). At each status change the backend can decide to propagate it to clients for example using web sockets. The web socket notification will carry the original correlation id that the subscribed client can use to update the UI.

Does it make sense?
.m

--
Mauro Servienti

Murilo Carlos Cardoso

unread,
Aug 30, 2020, 11:45:20 PM8/30/20
to ddd...@googlegroups.com
I think so! I'm a little bit confused on how to put everything together because there is the command side, the query side, and the frontend.

Trying to guess how to put everything together, it seems that just my query side needs to persist this correlation id and when the saga (choreographed) gets completed this correlation id can be removed from it. So the front-end should identity that there is a correlation id in the view and start the connection with the query side. When the saga gets updated the query side listens to some event that represents it and sends the new status information to the client. At some point in time, the query side receives the event that ends the saga, removes the correlation id, and ends the connection.

Does it make sense or is this a complete mess? 

Thanks!
 

To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/CAKhTcw1jSxSr1qtMeH9C_V04CZKHO-m50gbW6UPXLikfb--Upw%40mail.gmail.com.

Harrison Brown

unread,
Aug 31, 2020, 1:22:04 AM8/31/20
to ddd...@googlegroups.com
Yep. Makes sense, although for most front end architectures I tend to find it less complex to have the front end poll the query side rather than be sent events.

Harrison 
Sent from my iPhone

On 31 Aug 2020, at 04:45, Murilo Carlos Cardoso <murilo...@gmail.com> wrote:



손경덕

unread,
Oct 20, 2020, 7:15:15 PM10/20/20
to DDD/CQRS
refer this site.

2020년 8월 30일 일요일 오후 9시 54분 26초 UTC+9에 murilo...@gmail.com님이 작성:

Mauro Servienti

unread,
Jan 14, 2021, 11:40:35 PM1/14/21
to ddd...@googlegroups.com
It took me too long, partially because I’m lazy and particularly because there is a pandemic that’s destroying my routine and making everything absolutely impossible for everyone.

I wrote an article that goes into the details of the entire flow: 

Hopefully that’s not too late.

--
Mauro Servienti
Reply all
Reply to author
Forward
0 new messages