You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
It would be nice to have a "subscription" pattern for changes, similar to implementing a read side. This would allow applications to register as streaming consumers at runtime instead of in the COS configuration. This could be used to back cool patterns like serving changes over websockets to external API clients, etc.
Describe the solution you'd like
add a subscribe client method to the COS service, perhaps one that allows consuming changes for a particular entity or all entities
implement the subscribe method in COS server as a gRPC stream. probably use akka streams, and find a way to do this without too many connections to the journal (if db reads are needed at all)
Describe alternatives you've considered
n/a
Additional context
akka has cool streaming "Hub" concepts that allow you to change the streaming graph after initialization https://doc.akka.io/docs/akka/current/stream/stream-dynamic.html. Need to research how we would do late registration and broadcast changes on a node to all gRPC streams.
we should allow all nodes to answer gRPC stream subscribe requests, instead of a cluster singleton, etc
Is your feature request related to a problem? Please describe.
It would be nice to have a "subscription" pattern for changes, similar to implementing a read side. This would allow applications to register as streaming consumers at runtime instead of in the COS configuration. This could be used to back cool patterns like serving changes over websockets to external API clients, etc.
Describe the solution you'd like
subscribe
client method to the COS service, perhaps one that allows consuming changes for a particular entity or all entitiessubscribe
method in COS server as a gRPC stream. probably use akka streams, and find a way to do this without too many connections to the journal (if db reads are needed at all)Describe alternatives you've considered
n/a
Additional context
subscribe
requests, instead of a cluster singleton, etcThe text was updated successfully, but these errors were encountered: