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.
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.
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.
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.