Real-time UI synchronization by leveraging event streams

[Alexandre Potvin Latreille]

I realize that this question isn't DDD specific at all, but I'm quite sure that some of the folks here that plays a lot with event streams have already leveraged their event stream to create a real-time UI and I'd like to know what would be the most efficient solution to my problem or at least if the solution I'm planning to use would be fine.

Thanks!

[Chris Martin]

We use GraphQL subscriptions via websockets to keep UI up to date.

Basically, the client will subscribe to events by issuing a GraphQL query to run when the event is fired. The server returns the result of the query. There’s zero client-side logic to maintain.

On Thu, Sep 15, 2016 at 12:42 PM Alexandre Potvin Latreille <alexandre.pot...@gmail.com> wrote:

I realize that this question isn't DDD specific at all, but I'm quite sure that some of the folks here that plays a lot with event streams have already leveraged their event stream to create a real-time UI and I'd like to know what would be the most efficient solution to my problem or at least if the solution I'm planning to use would be fine.

Thanks!

--
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.
For more options, visit https://groups.google.com/d/optout.

--

Thank You,

Christopher Martin

[Alexandre Potvin Latreille]

I wanted to avoid hitting the server with further queries when events are occurring and let the client synchronize the state itself e.g. activeUserCount - 1 upon receiving a UserDeactivated event, but perhaps that's not the right approach and I should just re-run impacted queries. That would definitely simplify the client-side logic.

[Greg Young]

Hace you seen the sklaida example? https://github.com/eventstore/sklaida

> --
> 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.
> For more options, visit https://groups.google.com/d/optout.



--

Studying for the Turing test

[Chris Martin]

I don’t actively query the server though. The server listens to the event stream(s) and if anyone is subscribed, the subscribed query is run and streamed to the client(s).

Keeping all that UI sync logic on the client will become a mess very quickly. Ask me how I know ;)

My solution won’t work for you unless you’re using GraphQL anyway. Sorry.

[Jorg Heymans]

On Thursday, September 15, 2016 at 11:28:42 PM UTC+2, Chris Martin wrote:

We use GraphQL subscriptions via websockets to keep UI up to date.

Basically, the client will subscribe to events by issuing a GraphQL query to run when the event is fired. The server returns the result of the query. There’s zero client-side logic to maintain.

Could an alternative, more bare-bones perhaps, be that the server sends json-diffs representing the model changes to the client (via SSE or websockets ) ? 

Jorg

[Alexandre Potvin Latreille]

I think that for now I'll just stick to re-execute queries upon receiving certain events. It will greatly reduce the client-side logic and as there are not that many users I'm not concerned about the performance hit that much. 

For people doing event-sourcing and have projections for every views, they could just use the latest processed event number as a version for their projection and return that number as query metadata to the client. It would make it easy for the client to know wheter the event affected the query or not. 

In my case I do not have projections and I'm querying the current state so I guess that a timestamp is the most pragmatic version I could get for aggregated data. I could always compute a version number dynamically at the same time I'm processing the query, but that would probably add a lot of overhead.  

[Alexandre Potvin Latreille]

I did end up simply querying the head of the stream to get the position of the last event and from that point listen to further events. Upon receiving an event the UI issues the appropriate queries to update the data affected by the event. It does mean more web traffic and I guess that the approach could be problematic with many users, but it works for my case and requires no complex logic in the UI.