OpenFeature 0.9 estabiliza a avaliação de flags: o que muda na arquitetura

Ferramentas · "Loop"

A especificação 0.9 do OpenFeature, destacada pelo projeto em 12 de agosto de 2026, estabiliza as áreas de avaliação e providers depois de mais de dois anos sem uma revisão desse porte. Para quem usa feature flags, isso não significa que as flags ficaram “prontas” por decreto. Significa que a fronteira entre a aplicação e o sistema que decide uma variante ganhou um contrato mais previsível.

O release também mexe em pontos que aparecem fora do caminho feliz: ciclo de vida orientado a eventos, instâncias isoladas da API, tracking, logging e convenções de observabilidade. É aí que uma abstração independente de fornecedor deixa de ser só uma assinatura elegante e começa a ajudar em testes, micro-frontends e incidentes.

Estável não quer dizer que todos os SDKs já se comportam igual

Na linguagem da especificação, uma seção estável não recebe mudança incompatível sem uma nova versão major. A versão 0.9 estabiliza avaliação e providers e endurece contratos de hooks, eventos e contexto. Porém, o próprio anúncio informa que a conformidade 0.9 ainda está em andamento nos dez SDKs acompanhados.

Antes de migrar, confira três versões separadas: a especificação que sua arquitetura espera, o SDK da linguagem e o provider do serviço usado. “Suporta OpenFeature” não prova que os três implementam a mesma revisão nem que recursos como multi-provider e eventos de ciclo de vida têm paridade.

A aplicação deve pedir uma decisão de negócio, não falar com o painel

Uma camada pequena pode esconder o fornecedor sem esconder o significado da flag. O ponto de chamada deve informar uma chave, um padrão seguro e o contexto mínimo necessário para avaliar. O restante da aplicação não precisa conhecer endpoint, token, cache ou formato do serviço.

const client = OpenFeature.getClient('checkout');

const enabled = await client.getBooleanValue(
  'checkout-summary-v2',
  false,
  {
    targetingKey: user.id,
    plan: user.plan,
    region: user.region,
  },
);

O valor padrão faz parte do comportamento de falha. Se o provider ainda não estiver pronto ou ficar indisponível, desligar uma experiência nova costuma ser diferente de negar uma permissão. Por isso flags de release, operação, experimento e autorização não devem compartilhar a mesma governança.

Provider passou a ser dono de seu estado

Antes da 0.9, SDKs podiam emitir eventos sintéticos de pronto ou erro depois de chamar métodos de inicialização. Um provider com trabalho em segundo plano também podia publicar eventos, criando disputa de ordem. Agora o provider deve emitir as próprias transições, e o SDK deriva seu estado desse fluxo.

Para quem mantém provider, isso é uma mudança incompatível e exige mapear todas as transições: inicialização, recuperação, erro e encerramento. Para quem consome, a vantagem é distinguir “o método retornou” de “o provider está realmente pronto para avaliar”. Testes devem simular eventos fora de ordem e reconexão, não só uma inicialização bem-sucedida.

Instâncias isoladas resolvem um problema que o singleton escondia

A API global continua conveniente em uma aplicação simples. Ela vira acoplamento quando dois testes precisam de providers diferentes, uma biblioteca é carregada dentro de outro produto ou micro-frontends dividem o mesmo processo. A 0.9 permite instâncias isoladas, embora a disponibilidade prática ainda dependa do SDK.

Isso não autoriza cada módulo a criar uma ilha de flags sem coordenação. Em uma arquitetura de micro-frontends, a decisão precisa definir quem fornece contexto de usuário, quem controla conexões e como variantes são mantidas consistentes entre partes da tela. Isolamento técnico evita colisão; não substitui propriedade.

Observabilidade precisa explicar a avaliação sem vazar o contexto

A revisão reúne tracking, hook de logging e um apêndice com convenções atualizadas de OpenTelemetry. Um trace pode registrar chave, variante, motivo e erro da avaliação para responder se a regressão atingiu apenas quem recebeu uma flag. Evite anexar o contexto inteiro: e-mail, identificadores e atributos de segmentação podem transformar telemetria em vazamento.

  • registre a variante efetiva e a razão da decisão;
  • limite atributos de alta cardinalidade;
  • correlacione alteração de configuração com deploy e incidente;
  • não use logs como fonte de autorização;
  • defina retenção e acesso para dados de targeting.

A migração deve começar pelo inventário, não pela troca do import

  1. Liste SDK, provider e versão da especificação realmente suportada.
  2. Leia as três mudanças incompatíveis da 0.9 e a orientação de migração do ciclo de vida.
  3. Teste defaults, timeouts, provider indisponível e eventos fora de ordem.
  4. Compare bucketing e variantes antes de mover usuários entre providers.
  5. Adote instâncias isoladas apenas onde houver uma fronteira de responsabilidade clara.

O OpenFeature 0.9 deixa o núcleo da avaliação mais firme, mas expõe uma diferença útil: padrão e implementação não chegam no mesmo instante. A arquitetura ganha quando usa a especificação para reduzir acoplamento e, ao mesmo tempo, testa o SDK e o provider que vão tomar a decisão em produção.

Fontes

Leia também