STM Meets gRPC: An Unexpected Marriage

I'll admit, when I first encountered gRPC batch operations, I dismissed them as unnecessary complexity. Then I started implementing the gRPC layer and realised something remarkable: gRPC batch boundaries map perfectly onto STM transaction boundaries.

The pattern is almost embarrassingly simple: client streams a series of operations, server accumulates them, then wraps the entire batch in a single dosync. What emerges is something genuinely powerful – distributed transactions with full ACID guarantees. Multiple musicians can edit the same score simultaneously, knowing that either all their changes succeed atomically or none do. Complex operations like MusicXML imports or multi-step undo chains become naturally transactional across network boundaries.

The implications are profound: no more partial updates corrupting shared musical data, no locks preventing collaboration, no eventual consistency headaches. Just proper transactional integrity that works identically whether you're editing locally or collaborating across continents.

How many music notation programs have distributed atomic transactions across any network? And entirely without locks, and with automatic conflict resolution? None.

​Sometimes the most elegant solutions hide in features you initially think you don't need.

---