open-feature / spec

OpenFeature specification
https://openfeature.dev
Apache License 2.0
588 stars 35 forks source link

DOC:Best practices or Cases #237

Open freshchen opened 5 months ago

freshchen commented 5 months ago

Hello, OpenFeatrue is very attractive, but it seems that it requires developers to hardcode a lot of if else, and I am not sure whether this will put a mental burden on developers. Are there any best practices or cases that you can provide? In addition, are there any plans to integrate with springboot, react, gin and other development frameworks in the future?

lukas-reining commented 5 months ago

Hey, I think we currently have noting from the project regarding best practices like where to apply the feature flags in the code or at which granularity. Generally speaking one can reduce the mental burden by having the flags at the right layers and structure to prevent "ifs everywhere." Maybe we can build up a collection of patterns and structures that prevent these distributed conditions.

Regarding the SDKs, generally they should be working with frameworks of that language out of the box. Even though we are currently working on a specific SDK for React and NestJS, both are still experimental, that make integration a bit more idiomatic to the framework. And in the Roadmap we have an Angular SDK We also had the discussion here in the js-sdk. Regarding the Spring SDK, feel free to open up an issue in the java-sdk which either you, or someone else could pick up if interested.

toddbaert commented 5 months ago

Basically, everything @lukas-reining says!

I would consider the current SDKs base/"low-level" SDKs. Removing if/elses and that kind of conditional logic is something I personally believe a lot of frameworks like the ones you mention are positioned well to handle, so instead of building our own, the goal is to build "framework SDKs" which use the base language SDK + $framework, for example:

A Spring SDK, etc would be a welcome addition, and probably would be relatively low effort as most framework SDKs are, since they can stand on the shoulders of the underlying language SDK (Java in that case).

toddbaert commented 5 months ago

@beeme1mr @lukas-reining do you think we can make some documentation issue or something out of this? @freshchen certainly makes a good point, and though we are addressing it with things like the React SDK, Nest SDK, is there something more we should do? A blog post? Docs? Issues in GH maybe?

lukas-reining commented 5 months ago

Yes, I think we could create something like best practices, architecture styles and general recommendations. Something like patterns maybe that help to understand how to structure software for good feature flagging. It could be anything like blog posts, best practices in docs or so. Maybe it would be cool as "Good first issue" for the contribfest? I will open up that question in the community meeting.

beeme1mr commented 5 months ago

Yeah, that sounds good to me. I'll be out for a few days but if you could create a few issues, I can take a look when I get back. A best practices section would be very valuable in my opinion.

federicobond commented 5 months ago

@moredip's excellent article on Feature Flags can serve as a good starting point on what we should include:

https://martinfowler.com/articles/feature-toggles.html

Kavindu-Dodan commented 5 months ago

We currently maintain several getting started guides based on flagd [1]. And this section contains examples that use GO Gin [2] & Java spring boot [3] . However, as others have stated these are low-level SDK interactions where logic relies on if-else to perform conditional operations.

When it comes to spring boot, its main focus is on configuring the runtime (along with other framework features). But the feature flags focus mainly on dynamic application logic which is different. With the current Java SDK and provider point of view, I am yet to see how a spring(or a gin integration) would look like other than for injecting a configured provider for business logic.

[1] - https://openfeature.dev/docs/category/getting-started [2] - https://openfeature.dev/docs/tutorials/getting-started/go [3] - https://openfeature.dev/docs/tutorials/getting-started/java

luizgribeiro commented 3 months ago

From @moredip's article, we could use routers to segregate different behavior based on flag value and execute a branch based on flag evaluation results. I've done it in the past to refactor complex flows and it was a great approach (turned out even better to clean up).

I've sketched this in the past based on those ideas. It might be worth having a look

freshchen commented 3 months ago

@beeme1mr @lukas-reining do you think we can make some documentation issue or something out of this? @freshchen certainly makes a good point, and though we are addressing it with things like the React SDK, Nest SDK, is there something more we should do? A blog post? Docs? Issues in GH maybe?

Thanks for the answer. Searching for feature flag, I see almost all solutions. There is no more specific implementation case. My intuition tells me that the code will be filled with a lot of if else judgment logic of low-level SDK API, making the project difficult to read. And with what granularity to design the flag switch is very confusing. If there is a blog or Doc that I haven't retrieved that can explain this, please let me know, thank you very much

freshchen commented 3 months ago

We currently maintain several getting started guides based on flagd [1]. And this section contains examples that use GO Gin [2] & Java spring boot [3] . However, as others have stated these are low-level SDK interactions where logic relies on if-else to perform conditional operations.

When it comes to spring boot, its main focus is on configuring the runtime (along with other framework features). But the feature flags focus mainly on dynamic application logic which is different. With the current Java SDK and provider point of view, I am yet to see how a spring(or a gin integration) would look like other than for injecting a configured provider for business logic.

[1] - https://openfeature.dev/docs/category/getting-started [2] - https://openfeature.dev/docs/tutorials/getting-started/go [3] - https://openfeature.dev/docs/tutorials/getting-started/java

Thanks for the answer 1 Regarding the feature flag best practices, are there any relatively well-known open source projects that already use them? I would like to learn from them. 2 For development frameworks like springboot, I personally feel that feature flags is a superset of properties. So can we carry out deeper integration, such as integrating feature flag into spring environment, providing @ConditionOnFeatureFlag, etc.