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 which 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
I'll show a better 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 Kafka and Kafka Streams 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.