techhub.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A hub primarily for passionate technologists, but everyone is welcome

Administered by:

Server stats:

4.6K
active users

#OpenFeature

0 posts0 participants0 posts today

#KubeCon has a nice track called #Contribfest where maintainers can meet with (prospective) contributors to solve problems.

I randomly popped into the #OpenFeature slot w/o knowing anything about it (open standard for feature flags).

Although I couldn't contribute to any issue, maintainer Todd Baert was helpful and patient in assisting me to get a sample Spring Boot app running locally with #OpenFeature & #flagd.

A memorable encounter.

Also got a shirt, now feeling obliged to give back lol

blurghed: adding feature flagging to a node app using OpenFeature.

Get started with a simple hard-coded feature flag provider in literally a couple of minutes, with the option of a seamless future upgrade to the full-blown feature flagging frameworks that integrate with OpenFeature.

blog.thepete.net/blog/2023/03/

Pete HodgsonFive Minutes to Feature FlagsAdd feature flags to a node service in no time using OpenFeature, the open vendor-netural standard for feature flagging.

blurghed: what makes client-side #FeatureFlags different from server-side, and how we're extending the #openfeature API to support client-side flags:

docs.openfeature.dev/blog/cate

TL;DR:

1) on the server-side the evaluation context for flagging decisions is highly dynamic (each request is for a different user), vs client-side where it's *mostly* static.

2) on the client, feature flag evaluation is expensive/slow.

This means on the client flags are typically pre-evaluated ahead of decision time

docs.openfeature.devCatering to the client-side | OpenFeatureClient-side vs server-side feature flagging can be seen as two distinct paradigms. We'll explore what defines those two paradigms, and how OpenFeature is planning to support them via two different flavors of API