Hello from the OpenFeature community! This post is a double-feature of sorts: we'll be wrapping up our time at KubeCon NA 2024 as well as talking about our latest SDK feature: ✨ tracking events ✨.
As comic book aficionados say, with great power comes great responsibility, or great complexity as the case may be. Feature flags provide incredible value, and now with OpenFeature they're more accessible than ever, but the complexity they introduce should not be ignored. As your application grows, it becomes more and more difficult to understand how feature flag evaluations and changes impact your users and their experience with your application. The OpenTelemetry feature observability semantic convention special interest group (SIG) aims to combat this problem by defining a consistent set of rules and definitions for feature telemetry data. Keep reading to learn more about this effort and how you can be involved!
We are excited to announce the availability of the OpenFeature Web SDK v1. The Web SDK represents a culmination of years of research and industry consensus. It was built from the ground up to be performant, powerful, and flexible while providing broad support for your favorite feature management tool or in-house solution.
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.
We are excited to announce the availability of version 0.6.0 of the OpenFeature spec. This release brings many significant additions that benefit both provider developers and application authors, while also establishing a strong foundation for first-class client-side support in OpenFeature.
While OpenFeature initially focused on support for server-side feature flagging, we know that a lot of feature-flagging (likely the majority) happens on the client - mobile apps and frontend web apps. As such, we're currently finalizing a proposal which extends the OpenFeature spec to support client-side use cases. By the way, if you're working on a feature flagging framework, whether it's commercial, open-source, or internal product, the folks at OpenFeature would love to hear more about how you approach client-side flagging.
In this post I'll summarize those changes, but to understand them in context we'll first talk about what makes client-side feature flagging different before diving into how that will impact the OpenFeature APIs.
Early this year, OpenFeature announced its intent to bring a standard to the rapidly growing development practice of feature flagging. In June it was accepted as a Cloud Native Computing Foundation Sandbox project. Now, we're pleased to announce a new milestone: OpenFeature has released 1.0 versions of its .NET, Go, Java, and JavaScript SDKs!