Playground enhancements to better demo OpenFeature

[toddbaert]

Initially, this repository was set up as a test-bed for SDK features and concepts. It serves that purpose well, but doesn't provide a particularly compelling tech demo. I'd like to propose some enhancements to provide for a better demo. Something more stylish, more realistic, and which better emphasizes the benefits of OpenFeature and feature-flags in general.

The things I'm seeking to highlight are:

• flexible user-targeting being used to solve realistic problems
• realtime flag configuration updates
• vendor neutrality
• integrations with other tools/frameworks, such as OTel, Jaeger and Prometheus, and easy navigation to relevant views

Most of these things exist in the playground currently, but aren't showcased in a realistic application with multiple users.

I've used excalidraw to outline a demo. Please take a look here, and let me know your thoughts.

@moredip @justinabrahms @beeme1mr @Kavindu-Dodan @dyladan @thomaspoignant @kinyoklion

[dyladan]

It's definitely a more interesting demo and I think it shows real world uses much better than the previous demo.

• vendor neutrality

I think this is an excellent thing to highlight but vendor neutrality doesn't have value on its own. I'd focus on novel use cases enabled by vendor neutrality instead of the idea of vendor neutrality. I think it might be helpful to think of the story you will tell while you are presenting the demo. You should also make sure the demo README/website clearly shows how a user can walk themselves through these scenarios. For example:

• A mature company with an in-house feature flagging solution just purchased a startup that uses vendor A and wants to consolidate
• A growing company gaining technical maturity that wants to move away from ad-hoc environment variable flags to something more powerful
• A global org with data privacy compliance requirements, e.g. European user data cannot be used for flag evaluation in an American datacenter
• Different teams working in separate features or parts of the org use different feature flagging backends because of e.g. historical reasons like an acquisition, preference, differing required feature sets, etc.
  • reduce from multiple vendor SDKs to a single open SDK. particularly important in web where payload size is important
  • keep your existing backends if you like them
• Slow code migration over time. If the company has one or more existing vendors, you can slowly roll out open feature into your codebase and use the same vendor. Once you're completely moved over to the flagd SDK you can roll out a new unified vendor all at once.

Some of that may be more relevant to the presentation of the demo than to how the demo itself is actually built.

---

I'd also like to see common failure scenarios:

• provider is down
• data returned from provider is bad
• slow provider
• In the case of multiple providers, only one is down or slow
• et cetera

edit: didn't realize how long that got. I guess the short version is that I think you may want to think about placing more emphasis on what makes OpenFeature different. Most of the things in the proposal can be done with any feature flagging tool.

[toddbaert]

Thanks @dyladan . I agree with your points. I'll think about how I can highlight some of the aspects you mentioned in the demo itself, in addition to in documentation and presentation.

[Kavindu-Dodan]

Agree with all the points highlighted by @dyladan

I will add the following points to the discussion,

• Why adopt OpenFeature for a startup/new project

Unified SDKs from multiple vendors. One could start with a custom or opensource solution(ex:- flagd) and later as the product grows, migrate to a vendor which provides extra features & management capabilities.

• Why follow a standard rather than do it yourself

Show the benefits of standardization - while switching providers is one use-case, openfeature have powerful concepts like hooks that allow custom logic to be executed in the flag lifecycle. OTEL hook is a really good example and it is vendor-neutral thanks to the standard

Besides, openfeature focuses mainly on the code level(API & SDK), giving a clear separation from providers/flag backend. This gives developers a standard flag evaluation interface, which is much better than DIY solution.

On the other hand, standards help DIY concepts if that is a need of the org - OF SDK is pluggable and one can maintain SDK implementation internally. And support bring your own flags through the custom SDK.

---

And regarding the demo, overall it looks good and should allow us to capture many features that we discussed here.

• Regional lock & attribute based evaluations: Empahises the need of server-side evaluation
• Region-based color theme(dark mode): Could be a client-side FF example
• Telemetry(OTEL hook) -Highlight successful evaluations and errors