OpenFeature é um padrão vendor-neutro, mantido pela CNCF, pra avaliação de feature flags: seu código de aplicação chama a API padrão do client OpenFeature, e um provider por baixo traduz essas chamadas pra qualquer plataforma de flags que você esteja de fato usando. Trocar de provider, ou rodar duas plataformas lado a lado durante uma migração, não toca em nenhum ponto de chamada da sua aplicação.
O openfeature-provider é essa camada de tradução pro rollfuse: ele implementa a interface de provider Go do OpenFeature, sustentado pelo go-sdk por baixo, então você tem avaliação local, em cache, sem chamada de rede no caminho quente, com a mesma semântica de bucketing e match de regra que o go-sdk já tem, só acessada pela API padrão em vez do tipo de client próprio do rollfuse.
Instalando e registrando o provider
go get github.com/rollfuse/openfeature-provider
import (
"github.com/open-feature/go-sdk/openfeature"
rollfuseprovider "github.com/rollfuse/openfeature-provider"
)
provider, err := rollfuseprovider.NewProvider(baseURL, credential)
if err != nil {
log.Fatal(err)
}
openfeature.SetProvider(provider)
client := openfeature.NewClient("checkout-service")
NewProvider embrulha a mesma construção de client do go-sdk por baixo dos panos, ele aceita a URL base do seu Environment e uma Service Credential, e começa o mesmo ciclo de busca-e-cache de Configuration em segundo plano. Tudo sobre avaliação local, fallback seguro e reporte assíncrono de exposição que vale pro go-sdk direto vale aqui também; só a superfície de chamada muda.
Avaliando pela API padrão
enabled, err := client.BooleanValue(
context.Background(),
"checkout-redesign",
false,
openfeature.NewEvaluationContext(subjectKey, map[string]any{"plan": "growth"}),
)
if enabled {
// serve o novo checkout
}
Essa é exatamente a mesma avaliação que seu serviço teria chamando o Evaluate do go-sdk diretamente, o mesmo cache, o mesmo bucketing, o mesmo comportamento de fallback num estado de config não pronta, só expressa pelos métodos BooleanValue/StringValue/FloatValue/IntValue/ObjectValue do OpenFeature em vez do tipo de resultado próprio do rollfuse.
Por que isso importa numa migração
Se você está migrando de outra plataforma de flags, conectar sua aplicação à API de client do OpenFeature primeiro, usando o provider OpenFeature dessa outra plataforma, se ela tiver um, e só depois trocar pelo openfeature-provider, significa que a migração muda configuração, não código de aplicação. Veja nosso Verificador de Migração do LaunchDarkly pra dimensionar o que uma migração do LaunchDarkly especificamente envolve, com ou sem OpenFeature.
Veja o repositório openfeature-provider pra referência completa da API do provider e a versão suportada do spec OpenFeature.