We are excited to unveil the first official release of the @openfeature/angular-sdk! 🚀 This SDK extends OpenFeature capabilities to Angular applications, with a focus on Angular's unique patterns and practices. In this post, we’ll walk you through some of the standout features and how they integrate seamlessly with Angular development.
Today we're announcing the release of the OpenFeature SDK for .NET, v2.0! This release contains several ergonomic improvements to the SDK, which .NET developers will appreciate. It also includes some performance optimizations brought to you by the latest .NET primitives.
We're stoked to announce the first release of the @openfeature/react-sdk! This SDK is a distribution of our SDK for the web with extensions to support idiomatic React development and features. This blog highlights a few of these, with a few implementation details for the real React nerds. 🤓
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.
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.
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.