---
title: "Type-safe feature flagging in openfeature: Lessons learned from using feature flags at google"
weight: 2
tags:
 - kubecon
 - dev
---

{{% button href="https://youtu.be/mewXGSwDCE4" style="warning" icon="video" %}}Watch talk on YouTube{{% /button %}}
{{% button href="https://static.sched.com/hosted_files/kccnceu2025/f6/Type-safe%20Feature%20Flagging%20in%20OpenFeature.pdf" style="tip" icon="person-chalkboard" %}}Slides{{% /button %}}

## Featureflags?

- Idea: Change the behaviour of an application without rebuilding it
- Goal: Control rollout, reduce risk, experiment (a/b)
- At google: A huge number of feature flags (150k+) but that's because people forget to turn them off

## Where does the flag come from

- Lifecycle of a flag: Create, Manage, Deprecate, Delete -> But will it be created frist in code or in the service
- Classic implementation: Just a if/else that uses a function to get the flag
- Problem: What if the flag names missmatch between the code and flag ser -> Muliple sources of truth
- Solution: Require use of auto-generated flag bindings (codegen from the management system) to mitigate typos, etc.

## OpenFeature

- Goal: Vendor agnostic, standardized, open source
- Basic setup: Register provider (once per app), create a client, use client to get flags
- CLI: Integrate into management system, keep a local manifest of all flags and generate code (generates the client)
- Now: Just call the client's method instead of hard-coding feature flag names
