Let’s discuss in detail how we can use Event Sourcing for real-time frontend applications.
Event Sourcing has a highly efficient write model. Therefore, it fits quite well to handle real-time events sent by the frontend application via Web Sockets. Then, these events can be processed and easily be fed across to any subscribed consumer via Web Sockets.
However, when a significant number of events gets added over time, this approach isn’t efficient in recreating the current state by replying to all the past events each time.
One way to handle this is by using snapshots. We can create snapshots at specific intervals. For example, it could be a daily snapshot, or the range is dependent on a particular number of events. Then the state can be derived by replaying the events from the time snapshot was taken, eliminating the need of replaying the events from the 0th event.
But, when it comes to real-time events, the snapshot period should come to a very minimum.
We can combine CQRS (Command and Query Responsibility Segregation) and Stream Processing to address this.
CQRS and Stream Processing
CQRS is a pattern that forces to use of different models for reading and writing data.
So, when it comes to real-time data, your frontend can push the data to a Web Socket channel that will go into the Event Bus (which stores the Event Stream). Then the event snapshots are processed, and the reconstructed state is stored in the Data Store by a processing agent subscribed to the Event Bus.
REST API for Queries
Then, the new state is exposed via a REST API for data queries completing the CQRS flow. The REST API is helpful for initial data loading.
But, since we are talking about real-time data, do we have to wait until the final state is constructed to notify the subscribers? The answer is No!.
Stream Processing to Publish Events
You can use another set of subscriber agents to process the events stream and publish events directly to the Web Socket channels. Since it happens in parallel to constructing the state, the responses will be faster.
Suppose you are building a chat application. Then, when a user sends a message from its frontend as an event, we can forward it to relevant Web Socket channels.
If the message is self-contained with data about its destination, minimal processing is needed before forwarding it to relevant channels.
However, if you need to query any metadata related to each event, we can improve the performance by processing events in bulk.
This way, enriching the publishing message becomes faster since we can perform batch queries against the database than processing message by message.
As you can see, Event Sourcing coupled with CQRS and Stream Processing would ultimately benefit real-time applications due to multiple advantages.