005-OFEP-flagd-update-subscribers

james-milligan commented 2 years ago

Signed-off-by: James-Milligan james@omnant.co.uk

beeme1mr commented 2 years ago

This has a dependency on https://github.com/open-feature/spec/issues/77

AlexsJones commented 2 years ago

This is very interesting. I am thinking of how this might work in the flagD wide implementation.

My initial thoughts are:

Challenges are knowing how to handle types of services that wouldn't be realistically streaming events ( e.g. file changes are atomic ).
We could create a streaming facade for services that don't support true streaming and have a layer to integrate in between.
The UX will be very dependent on how much work we want to do in the client SDKs
A ws:// address might be the easiest step 1 to get something operational

Option 1. Perhaps the easiest start would be to acknowledge that we own the OpenAPI spec for flagD and it's not a 1:1 with the upstream spec. As such we could extend it to offer a /stream/register set of capabilities. This could do an HTTP upgrade in place to switch to a WS connection. The primary work would then be writing an interoperable layer for the grpc/stream back to WS.

Option 2.

Another thought would be to provide a unique API endpoint that avoids having to do an in-place upgrade, therefore removing SDK side work. This would mean that there are several ws:// protocol style comments around a tagged group of API endpoints for streaming.

toddbaert commented 1 year ago

@james-milligan is this still relevant given our current implementation and https://github.com/open-feature/ofep/pull/25?

open-feature / ofep

005-OFEP-flagd-update-subscribers #21