PLEASE SEE ALSO MY STRANGELOOP TALK, WHICH INCLUDES VIDEO: https://speakerdeck.com/bobbycalderwood/commander-better-distributed-applications-through-cqrs-event-sourcing-and-immutable-logs
Have you ever hit a wall with REST? Does modeling your problem domain into CRUD-able entities feel like fitting a square peg into a round hole? Perhaps instead of modeling our services like little databases, we should instead model them like reactors to event streams. REST APIs are great, but their typical implementation tightly couples various concerns that would be better separated:
* Reads (perception) from writes (action)
* Current state from historical narrative
* Business logic from HTTP design from operational concerns like metrics and monitoring
Commander is a pattern for writing REST APIs that de-couples these concerns, thereby alleviating common frustrations with CRUD-flavored REST. This pattern imposes a clear separation of action from perception, and uses immutable values conveyed by Kafka and the Kafka Streams library to separate business logic from HTTP concerns, all while preserving the historical narrative of the entire event stream. In this talk, I'll discuss the benefits and tradeoffs of this approach, and demonstrate my implementation using Clojure in the HTTP layer, and using Java with the new Kafka Streams library in the event stream processing layer.