Closed james-milligan closed 1 year ago
To aid with the simplicity of both the client and server implementations for the subscribers I propose that a single grpc stream is opened for each flag. This will reduce the requirement of routing the received flag values on the client side, the downside of this is an increased number of open connections.
Ive put together 2 diagrams to show a possible mechanism for this approach, happy to do the same for a 'singleton' connection in which all subscribed flag updates are handled over the same grpc stream.
In this example the context is sent with the subscription request and will be used in the flag evaluation once an updated flag value is received, a state Is also stored to ensure only deltas are sent - preventing repeated values being received client side.
In this example no context is present, this may be required when the context value is likely to change following the subscription to a given flag key. In this example the client receives a notification of change and can then request the new flag value via the standard grpc/rest interfaces.
Its likely that both of these will need to be present and the interface will contain pairs of subscribers, such as SubscribeToBoolean and SubscribeToBooleanNoContext
@james-milligan, is this issue still relevant?
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in next 60 days.
@james-milligan, is this issue still relevant?
no, will close
Using gRPC streams we can create subscribers to allow for client side updates to be driven from flag value changes in situations where a flag will not be re-evaluated, such as those involved in startup.
Next steps: