Speaking as an open-source feature flag 'vendor' (https://github.com/flipt-io/flipt), the OpenFeature organization has been a joy to work with. They are very welcoming of new contributors (e.g., implementing a provider SDK in a new language).
We've been thinking a lot recently about supporting 'edge' k/v stores like vercel/cloudflare and having the client side evaluation SDKs pull from there, which wouldn't require a server at all. This seems very similar just with using GitHub. We could even use GitHub Container Registry as the store as its OCI compliant.
Approvals are coming next btw. With the ability to lock down envs like production and optionally require all state changes to go through a proposal/approval process
I tried to answer your first question below, hope I did!
Re: GitHub outage, each org gets their own instance in our cluster and maintains a checkout of the git state, so you can still write/read from your environments, they just wont be synched to GitHub until they recover.
We're also thinking about adding other 'sinks' like S3/object stores and OCI as backup sinks.
This! 100% All the same benefits of config as code, infra as code. And with feature flags if something goes wrong its a simple `git revert` to get back into the previous state.
Another benefit is you can easily replicate the current (or previous) state of production/staging/etc flags locally just by doing a `git clone` and then run our self-hosted version locally. Its a single binary, can be installed with curl or homebrew and can read the flag state from your local filesytem.
This allows you to test your code locally or in CI with the same state in production
Yeah the context only supports a map/JSON object of k/v string values for evaluation at the moment.
We could definitely look into supporting other types and making this simpler. The constraints that are matched can be of several types, which we try to parse at evaluation time https://docs.flipt.io/concepts#constraint-types.
Also thank you for the feedback about not being able to change the organization name. Currently we use the 'slug' of the organization (based on the name) when we setup the routes for your environment, so it was just simpler to make it a one time thing.
But I think we could support renaming your org, it would just make the previous URLs invalid, or we could maybe handle redirects on our end too.
We at https://flipt.io are putting on a buy vs build webinar in a couple of weeks to discuss this very thing as it's a common question that engineering teams seem to have.
We're currently evaluating OPA for adding RBAC to our open-source application [0]. We plan on using the Go API [1] and doing the policy eval directly in our app since our app is also written in Go.
The thinking is we'll have some basic built-in policies (like admins can do X, editors can do Y, etc) but also allow users to configure their own policies if they want by writing rego and loading their policy rules at startup time (via config). We'd document the inputs that we pass to the evaluation call such as request headers, IP, role, etc.
I'm curious if anyone has ever tried something like this or similar?
Hey thanks for giving Flipt a look! I'm the creator of Flipt so would love to chat more about your needs to see how we could make it work for your use case! We're actively looking into providing local caching for all our SDKs btw and would love to learn more about what your requirements are for remote configuration as it's also on our radar!
Feel free to send me an email at: mark (at) flipt.io.
Author here. I just removed the previous section I had around using build tags because I realized I was using `// +build 1.18` instead of the correct `// +build go1.18`. Oops.
If you're interested in this space I'd recommend lurking in their CNCF Slack Channel https://cloud-native.slack.com/archives/C0344AANLA1 or joining the bi-weekly community calls https://community.cncf.io/openfeature/.