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.

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.

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.

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.

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.

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.

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!

Logging is the act of keeping a log. A log (in this case) records events that occur in software.

Subject to many opinions and differing principles of best practice, the best thing we could do for the go-sdk was to create an implementation as open & configurable as possible. To achieve this, we've integrated logr, this allows the use of any logger that conforms to its API.

Applications may already have a chosen logging solution at the point of introducing openfeature. An integration with logr may already exist for their chosen solution (integrations exist for many of the popular logger packages in go). If not, they could write their own integration.