When stateless APIs are not enough: deep dive into a reactive backend design
summary
Argues for a stateful reactive backend built with ZStream and mapAccumZIO that models a finite state machine to merge frontend commands and Kafka responses into one loop, track pending requests, and push incremental rows over SSE/WebSocket so data appears as available rather than waiting for the slowest piece. Shows concrete mapping of Kafka calls, per-connection state kept while socket is open, cancellation and coarse-grain requests, claims this reduces latency vs all-at-once GraphQL and avoids polling while keeping maintainable code.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 2:29Conductor and Kafka context
- 6:02Problem with single-request APIs
- 8:10Streaming APIs for UX
- 9:17Integrating streams in Tapir
- 11:53Need for stateful backend
- 13:22Stateful backend with WebSocket
- 15:31MapAccum operator
- 18:49Main loop execution
- 20:53When not to stream
- 21:36Key takeaways
- 23:28Q&A
related talks
55mRethinking Reactive Architectures
34mReactive Architecture
51mBe proactive about state in a reactive system
01h 21mReactive Web Applications
46mGet Reactive! Programming, Systems, and Microservices
28mArchitecture Patterns To Enable Stateful Communication Over Stateless Serverless Apis
42mReactive Design Patterns
59mSucceeding at Reactive Architecture