Skip to main content

OpenFeature at KubeCon EU '24

· 3 min read
Todd Baert
Software Engineer at Dynatrace, OpenFeature maintainer

It's that time again, KubeCon EU!

We have a lot going on this week, and we'd love to meet you! Join a session, get your hands dirty at the Contribfest, and come see us at the booth! See below for details and links.

Reconciling with State: Simplifications and Improvements to Better Support Framework-Specific SDKs

· 5 min read
Todd Baert
Software Engineer at Dynatrace, OpenFeature maintainer

Recent Specification Changes 🗒

There's no shortage of frameworks available when it comes to the development of enterprise software. Whether it's the "frontend" or "backend", developers are quick to avail things like React, Spring, Gin and Flask to avoid boilerplate code and structure their applications in a familiar way. Such frameworks also offer convenient abstractions that ease the employment of common patterns, think dependency injection as in Angular or Spring, or MVC as in Django or ASP.NET MVC. Many also provide extensibility features so that new functionality can be implemented seamlessly and idiomatically.

OpenFeature, we've been working on enhancing our specification and base SDKs to support the creation of such framework-level SDKs in order to bring vendor neutral feature flags to them. Specifically with respect to front end frameworks such as React, we've found that it was critical to refine the semantics of our events API and context-reconciliation concepts. This post discusses some of our improvements.

Context Reconciliation

As discussed in previous blog posts, we've seen that client-side feature flag APIs share some commonalities we refer to collectively as the static-context paradigm; in short, the context used as the basis for flag evaluation is less frequently changed and generally corresponds to a user, or application state that a user occasionally modifies. When a user logs in, or some state is modified, providers frequently need to fetch a new ruleset or re-evaluate their cache of flags based on the new contextual data. We refer to this as reconciliation. During reconciliation, some asynchronous work is often required (frequently this takes form of some kind of network request). During this time, depending on the provider and the needs of the application, it might be necessary to display loading indicators, or prevent users from taking action. Some frameworks have patterns or in-built functionality to support this, such as React's suspense. In order to leverage such features, we've added a new RECONCILING provider state and PROVIDER_RECONCILING provider event. These indicate the provider is in the process of reconciling it's internal state due to a context change. Previously, something like this was achievable with the use of the STALE state and events, but we believed this was overloading the meaning of this state and didn't provide adequately robust semantics.

* transitions occurring when associated events are spontaneously emitted from the provider

Wider Implications: "Stateless" Providers

Up to now, providers maintained a publicly-exposed representation of their own state: when they became ready, they changed their state to READY; if they lost connection to their source of truth, they might change their state to STALE or ERROR and emit PROVIDER_STALE or PROVIDER_ERROR events. This state management was burdensome for provider authors, and the addition of new states (such as RECONCILING mentioned above) only worsened that issue. Additionally, it allowed for widely divergent behavior between provider implementations, making the creation of framework-specific SDKs difficult and their behavior less predictable between providers, without meaningful benefit. With this update, the provider interface has become stateless. Now, the SDK itself maintains the provider's state based on the completion of lifecycle functions (initialization, shutdown, on context change) and events emitted by the provider. This simplifies things for provider authors, and results in a uniform experience for application authors, especially when leveraging framework-specific SDKs.

Bad States

In some circumstances, providers may not be able to evaluate flags. This could be because a provider hasn't yet been fully initialized, or has experienced some internal error. Previously, provider-authors had to ensure their publicly exposed state was updated if such errors occurred, as well as emit an error event. Furthermore, provider authors had to check with this state to accurately return an informative error code (ie: PROVIDER_NOT_READY) if evaluation was attempted in such states. With these recent changes, we've added a new FATAL error code, indicating that the provider has entered a irrecoverable error state (typically due to a bad credential, hostname or other value that's likely to represent a misconfiguration). Along with this helpful new state, implementations will now "short-circuit" evaluations if the provider is in NOT_READY or FATAL states.

Overall, we believe these changes will improve consistency for application authors across providers, and simultaneously reduce the burden on provider authors as well.

Contributing 🤝

If you're interested in contributing, there's no shortage of opportunities! You can create a client-side provider for a vendor or tool you're familiar with and host in our contrib repos. If the server-side is more your thing, you can help to update any of our existing server-side providers by simplifying them consistent with this latest spec change. As always, we're looking for help with our newest SDKs, some of which have yet to reach 1.0, including Kotlin, Swift, Python, Ruby, and Rust. We're also interested in more framework-specific SDKs as discussed in this earlier post. If there's a framework or library you think could benefit from an OpenFeature SDK, these are a great idea for a first contribution.

Shout Outs 🥇

Thanks to everyone who worked on this specification change, and a special shout-out to the folks at Spotify who've been contributing to the spec, as well as to our client implementations including our Kotlin and Swift SDKs.

Stay Tuned... 📻

We're excited to be working on an open, vendor-neutral protocol for the evaluation of feature flags, which adheres to OpenFeature semantics. This protocol could be used as the basis for a single provider which is compatible with any implementing backend, and might be of particular usefulness for client-side feature flagging. If you'd like to know more, check out our dedicated slack channel for this topic.

OpenFeature December 2023 Update: We're Incubating & more!

· 4 min read
Stacey Potter
Program Manager, Open Source Community at Dynatrace

December 2023 Update

Hello OpenFeature Community 👋

Happy holidays and a very happy new year in the coming weeks! There’s a lot happening as we wind down the year, so keep reading! As always, we thank you for your continued support and contributions and look forward to an exciting new year in 2024!

Different approaches for server-side SDK architectures

· 6 min read
Liran Mendelovich
Software Developer

Server-side feature flag software development kits (SDKs) are a common way to integrate feature flags into your microservice application architecture. Feature flag SDKs have several functionalities, but the primary purpose is performing a feature flag evaluation using contextual information. Each feature flag service can publish SDKs in multiple programming languages. A feature flag service commonly exposes APIs via endpoints like REST HTTP and/or gRPC. SDKs are an important layer, as network traffic loads affect both the application and the feature flag service. When the feature flag service is a cloud SaaS service, often it supports a relay proxy or a sidecar application, which can be deployed on an organization network. A relay proxy lets multiple clients connect to a local proxy, reducing the number of outbound connections to the cloud service. Considering that a large amount of microservices using SDK instances can be deployed, this can be significant.

Naming is Hard: Renaming the @openfeature/js-sdk

· 2 min read
Todd Baert
Software Engineer at Dynatrace, OpenFeature maintainer

Renaming the @openfeature/js-sdk

It's been said that there's only two hard things in Computer Science: cache invalidation and naming things. Here at the OpenFeature project we can attest to both, but today we'd like to talk about naming.

What's changed

In order to avoid confusion, we recently renamed our server-side JavaScript SDK. We've deprecated the @openfeature/js-sdk and published the same package under a new name: @openfeature/server-sdk.

Why we made this change

With the introduction of the @openfeature/web-sdk, we heard many stories of users having trouble due to incorrectly importanting modules; either importing modules meant for the web in a Node.JS context, or vice-versa. This problem was exacerbated by the fact the server-side SDK was called @openfeature/js-sdk, which doesn't indicate it's intended for server-side JavaScript runtimes such as Node.JS. With our new naming scheme, it's clear that @openfeature/server-sdk is useful for the server, while @openfeature/web-sdk should be used in browser environments.

How to migrate

To migrate, simply uninstall the old package, install this new package, and update all your require/import statements. There are no changes between the last published version of the @openfeature/js-sdk and the first published version of the @openfeature/server-sdk. Note that we have re-released all the relevant community-provided artifacts hosted in our js-contribs repository, and modified them to include a peer dependency on the @openfeature/server-sdk. You will need to migrate in order to consume the latest versions of these components.

Flag Definition & Flag Evaluation Protocol Standardization Discussion

· 2 min read
Todd Baert
Software Engineer at Dynatrace, OpenFeature maintainer

Currently, the OpenFeature specification describes a vendor-neutral API for flag evaluation. It does not describe a flag definition language, or a flag evaluation wire protocol. Consequently, the only means of integration with the OpenFeature SDK is to implement a provider in the relevant programming language(s), which serves as an adaptor between the OpenFeature evaluation API and the flag management system powering the provider.

Feature Flags: With Great Power Comes Great Responsiblity

· 12 min read
Jake Van Vorhis
Senior Software Engineer

Please note: This is a cross post from the Virtru Blog, dated June 16, 2023 by Jake Van Vorhis.

There is an ever-present tradeoff between speed and durability in engineering. Even if you’re cooking up boxed mac n cheese, there’s a spectrum that spans bare minimum utility on one side and needless hyper-optimization to the nth degree on the other side. Nobody wants uncooked noodles with still-dry cheese powder for dinner, but they’re also not expecting a couple of bucks at the grocery store to lead to a Michelin-quality in-home dining experience. It’s about balance.

As the Engineering org and Product roadmaps grow, the question “How can we make this happen?” needs to become “How can we make this happen quickly while not harming ourselves later on?” There is a priority switch from feature enablement to enablement while minimizing new tech debt. Paying the technical debt credit card bill is always painful, so navigating the speed and durability tradeoff effectively is one of the most important challenges teams face.

Last year, a feature in one of Virtru’s newer products kicked off an exploration into Feature Flags. What follows is a recap of that journey. I hope you have your cheesy mac ready.

OpenFeature Adoption Story

· 4 min read
Liran Mendelovich
Software Developer

Our team recently needed to use one of the largest feature management cloud services. This service has a documented SDK with usage guidelines. Thinking about how to define the exposed interfaces, while keeping it simple and generic, we started doing some research, and encountered OpenFeature. Gladly, the mentioned feature management cloud service has already created an OpenFeature provider. Let me explain why and how it was adopted.

Feature Flags are just if Statements, Right?

· 4 min read
Adam Gardner
DevRel @ Dynatrace, OpenFeature Contributor

Most feature flag explainers begin by explaining that feature flags are equivalent to environment variables.

While that’s true (to a point), feature flags wouldn’t be as versatile or as popular as they are, if that’s all they were. Indeed, you wouldn’t need a feature flag – you could easily achieve the same thing with an environment variable.