Hi,
I work with a “mature” Java servlet-based web app that stores its state in-memory as something like an event store with serialized Java objects. We have existing web clients that connect directly to this Java application, and they are not going away anytime soon. We also have a cloud-based app for streaming JSON messages to WebSocket clients that will need to have the web app state streamed to them. So we need to convert the serialized Java objects from the web app to JSON and then send them to the cloud-based app so it can stream them to the clients. This smells like CQRS/Event Sourcing, with the command handling and event store responsibilities already being done in the web app (though not at all conforming to the command/handler domain model pattern), and a need to do conversion to a JSON read-side model suitable for streaming to clients. I’m looking for critique on the options I’m considering.
- The simplest thing I can think of would be to push the events from the web app into a shared cache based on something like Hazelcast. Then I can create a consumer app that gets notified when an event is added, converts the serialized POJO to JSON, and stores the JSON to a read-side model. Another consumer app would notice the read-side model changes and send them to the streaming app. This would of course become problematic when we eventually try to distribute the web app across multiple nodes, since we’d have to implement all the troublesome event store concurrency behaviors in the shared cache.
- I’m also considering using Axon between the web app and the streaming app. Since I’d love to move the entire web app to Axon eventually, this would put key pieces in place for future phases. Does this seem crazy? Too much extra work compared to option 1?
- I could create a simplified domain that just turns each web app in-memory event type into a command with aggregates that naively accept each command by generating an event. Then I’d have a real event store and could project the events onto a JSON read-side model. Would this be a good stepping stone to allow moving the web-app domain piece by piece to more robust commands and aggregates in the future?
- I could also just publish the web app in-memory events to the Axon event bus directly. So I’d still have the event store and projections to the read-side, but wouldn’t need to implement commands and aggregates. Would this be a quicker alternative, then work on the domain stuff later? I’m not sure how much I’d really save in the and, and I have a feeling I’d be stepping into trouble trying to use just half of Axon.
Having played around a bit with event stores, I found a lot of pitfalls. Then I found Axon and breathed a sigh of relief. I’m really hoping to take advantage of this awesome framework.
Regards,
Kevin