Problem
OFREP currently only supports polling for flag change detection in client-side (static context) providers. There is no way to implement real-time flag updates, and frequent polling introduces unnecessary load on flag management systems while adding latency to flag change propagation. Many vendors already use SSE for change notification, but without a standardized mechanism in OFREP, each must implement proprietary push solutions.
Proposed Solution
Add an optional sse array to the bulk evaluation response (POST /ofrep/v1/evaluate/flags). When present, it provides SSE endpoint URLs that the provider connects to for real-time flag change notifications. SSE events contain a type field (e.g., refetchEvaluation) along with optional etag and lastModified values that the provider uses when re-fetching the bulk evaluation via the existing ETag-based caching mechanism.
This is a backward-compatible, additive change -- servers that don't support SSE omit the field, and providers that don't support it continue polling.
Further details on schema, event format, provider behavior guidelines, and open questions will be provided in the ADR PR.
Problem
OFREP currently only supports polling for flag change detection in client-side (static context) providers. There is no way to implement real-time flag updates, and frequent polling introduces unnecessary load on flag management systems while adding latency to flag change propagation. Many vendors already use SSE for change notification, but without a standardized mechanism in OFREP, each must implement proprietary push solutions.
Proposed Solution
Add an optional
ssearray to the bulk evaluation response (POST /ofrep/v1/evaluate/flags). When present, it provides SSE endpoint URLs that the provider connects to for real-time flag change notifications. SSE events contain atypefield (e.g.,refetchEvaluation) along with optionaletagandlastModifiedvalues that the provider uses when re-fetching the bulk evaluation via the existing ETag-based caching mechanism.This is a backward-compatible, additive change -- servers that don't support SSE omit the field, and providers that don't support it continue polling.
Further details on schema, event format, provider behavior guidelines, and open questions will be provided in the ADR PR.