We are super excited about the latest Eventuate sample application. It is a real-time, collaborative Kanban board. The application uses Websockets to deliver events published by the Eventuate event store to each user’s browser. This ensures that every user viewing a Kanban board sees the same consistent view . It is a great example of how event sourcing is an excellent choice for real-time collaborative applications.
The following diagram shows the architecture.
The application has an AngularJS front-end. Each of the microservices as well as the API Gateway are written in Java and use Spring Boot. The system-of-record is the Eventuate event store. MongoDB is used as a CQRS view of boards and tasks. The microservices , the API gateway and MongoDB are deployed using Docker.
Event sourcing is a good choice for this kind of collaborative application. That is because whenever the state of the application – i.e. a board or a task – changes an event is published. Those events can then update the information displayed to the users. In this application the events are transformed into WebSocket messages and delivered each user’s browser.
Learn more about Eventuate
To find out more about Eventuate:
It is a challenge to write a simple yet meaningful example application that illustrates how to develop event-driven microservices using the Eventuate platform. That is because the microservices architecture requires you to have at least two services. The Money Transfer application has, for example, three (soon to be at least 4) separate services. Even though it is a great example of how to write event-driven microservices using event sourcing and CQRS it is not the easiest introduction to the topic.
To make the getting started experience easier we have created the Todo List application. This application is a Java and Spring Boot application built using Eventuate™’s Event Sourcing based programming model. The application has a HATEAOS-style REST API for creating, querying, updating and deleting a todo list. The API design is inspired by the Todo backend project. The principle difference is that unlike the original version this API is eventually consistent.
The application has a CQRS-based architecture. Creates, updates and deletes are handled by the command side service, which consists of a Todo Aggregate that is persisted using event sourcing. Queries are handled by the query side service, which maintains a materialized view of the todo list in a SQL database.
There are two versions of the application. The simplest version is a single module Gradle project that builds monolithic version of the application of the API. It is a great way to learn the Eventuate API.
The other version of the application is a multi-module Gradle project, which can be deployed as either a monolith or as two microservices: a command-side service and a query-side service.
Both versions come with a Docker Compose file that can be used to launch the application along with a MySQL database.
To get started take a look at the README.md.
Learn more about Eventuate
To find out more about how you can use the Eventuate platform to build event-driven microservices: