Contexto de evaluación y hooks de OpenFeature: ¿Cómo mantener claros los límites de los feature flags?

Planteamiento y alcance

Un entrevistador podría preguntar: “Explique cómo funcionan juntos el contexto de evaluación, los providers y los hooks de OpenFeature, incluidos los límites de fallos, tipos y privacidad”.

La señal es si usted comprende OpenFeature como una API de evaluación de aplicaciones neutral respecto al proveedor (vendor-neutral), y no como una consola de flags completa o un sistema de autorización. La especificación separa la clave del flag (flag key), el valor predeterminado, el contexto de evaluación, el provider y los detalles de la evaluación. Los hooks pueden validar, enriquecer el contexto, emitir telemetría o manejar errores, pero no deben cambiar silenciosamente la semántica de autorización del negocio.

Qué está evaluando el entrevistador

• Si distingue entre el llamador de la aplicación, el provider, el contexto de evaluación y los metadatos del flag.
• Si la evaluación tipada y los valores predeterminados forman un comportamiento de fallo predecible.
• Si utiliza el contexto de transacción y hooks en lugar de un estado global mutable compartido.
• Si gestiona los tiempos de espera (timeouts) del provider, las discrepancias de tipos, los flags faltantes y los datos de privacidad.
• Si los registros de evaluación y las auditorías se mantienen separados de la autorización del negocio.

Preguntas para clarificar

• ¿El flag controla un despliegue gradual, la asignación de un experimento o la autorización de seguridad?
• ¿Qué campos del contexto son obligatorios y cuáles deben permanecer en el proceso o fuera de los registros?
• ¿El provider es de memoria local, un servicio remoto, un archivo o una composición de providers?
• ¿El valor predeterminado es seguro cuando el provider falla, y la política es fail-open o fail-closed?
• ¿Cuántos detalles de evaluación, versión de regla y error del provider deben registrarse?

Una respuesta de 30 segundos

Puede decir:

La API de aplicación de OpenFeature solicita un valor de flag tipado, el contexto de evaluación suministra los datos de segmentación y de alcance de la solicitud, el provider evalúa sus reglas y los hooks se ejecutan alrededor del ciclo de vida para validación, enriquecimiento de contexto o telemetría. El llamador proporciona un valor predeterminado seguro; un fallo del provider, una discrepancia de tipos o un flag faltante devuelve detalles diagnosticables sin convertir a un hook en un sistema de autorización. El contexto transporta únicamente los campos necesarios con controles de privacidad. Los experimentos y las métricas de lanzamiento pueden registrar versiones de reglas, pero no deben registrar datos personales.

Razonamiento paso a paso

Separar las responsabilidades de evaluación

El llamador solicita un valor tipado, el provider resuelve las reglas y el SDK combina el resultado con el valor predeterminado, la razón, la variante y el código de error:

application -> OpenFeature client -> provider -> flag result
                         |               |
                       hooks        evaluation details

El provider es dueño de la fuente de reglas y de la implementación de la evaluación. No asuma que todos los providers tienen el mismo comportamiento de caché, red o consistencia; el llamador sigue definiendo los valores predeterminados y las acciones del negocio tras un fallo.

Diseñar el contexto de evaluación

El contexto puede incluir un targeting key, atributos de usuario u organización y campos propagados por la transacción. Envíe solo los datos requeridos por las reglas; aplique hash, recorte u omita el correo electrónico, la IP y los identificadores de dispositivo. Propague el contexto de la transacción con la solicitud en lugar de utilizar un objeto mutable compartido entre solicitudes.

Utilizar evaluación tipada y detalles

Utilice la API correspondiente para booleanos, cadenas, números y valores estructurados, con un valor predeterminado del mismo tipo. Los detalles de evaluación pueden transportar el provider, la razón, la variante, el código de error y los metadatos para diagnóstico y análisis de experimentos. Los detalles no son un veredicto de autorización; un llamador debe distinguir entre “el flag está desactivado” y “el usuario no está autorizado”.

Ubicar los hooks y la política de fallos

Los hooks pueden validar valores, agregar telemetría, registrar errores o enriquecer el contexto en las etapas before, after, error y finally. Deben ser idempotentes, de baja latencia y seguros para la privacidad. Un tiempo de espera de un provider remoto o un error de tipo utiliza un valor predeterminado seguro y una métrica de degradación. La funcionalidad de alto riesgo puede usar fail-closed, pero explicando el impacto en el usuario y la recuperación.

Respuesta modelo de alta calidad

Trato a OpenFeature como un contrato de evaluación de aplicaciones. El llamador utiliza una API tipada y suministra un valor predeterminado seguro que coincide con el tipo; el contexto de evaluación transporta solo el targeting key y los atributos requeridos por la regla. El provider recupera y evalúa las reglas desde un sistema de flags concreto, devolviendo un valor, razón, variante, código de error y metadatos. Los hooks pueden validar, enriquecer el contexto y emitir telemetría alrededor del ciclo de vida, pero no reemplazan la autorización ni reescriben silenciosamente los resultados. El tiempo de espera del provider, un flag faltante o una discrepancia de tipos sigue el valor predeterminado definido y emite métricas de error. Los registros guardan un targeting key anonimizado, la clave del flag, la variante y la versión de la regla en lugar del correo electrónico o el contexto completo de la solicitud. Elija fail-open o fail-closed para un experimento de lanzamiento según el riesgo, y luego ejercite la expiración de caché, la recuperación del provider y el rollback.

Errores comunes

• Llamar a OpenFeature una consola de flags completa, un distribuidor de configuración o un servicio de autorización.
• Permitir que un hook cambie el valor sin registrar una razón, haciendo que los resultados sean inexplicables.
• Utilizar un valor predeterminado con el tipo incorrecto o tratar un flag faltante como un éxito.
• Enviar un objeto de usuario completo, correo electrónico o IP en el contexto de evaluación sin minimización.
• Reintentar indefinidamente un provider fallido u omitir una política explícita de fail-open/fail-closed.
• Tratar los detalles de evaluación como la decisión final de permisos.

Preguntas de seguimiento y respuestas

1. ¿Puede targetingKey ser una dirección de correo electrónico?

Solo cuando la regla realmente lo requiera y la revisión de privacidad lo permita. Un identificador de usuario u organización estable e irreversible suele ser más seguro. Los registros y los providers remotos aún necesitan minimización y límites de retención.

2. ¿Qué debería suceder cuando un provider devuelve un error?

Elija un valor predeterminado seguro según el riesgo, devuelva un código de error diagnosticable y emita métricas de degradación. Un flag de lanzamiento de bajo riesgo puede permanecer habilitado de manera conservadora, mientras que la funcionalidad de alto riesgo puede cerrarse o requerir recuperación manual. La parte importante es una política explícita y comprobable.

3. ¿Pueden los hooks implementar auditoría?

Pueden ser un punto de entrada de telemetría para eventos de evaluación, pero la auditoría también necesita integridad independiente, control de acceso y retención. El fallo de un hook no debería bloquear todas las evaluaciones a menos que el requisito haga explícitamente del éxito de la auditoría un requisito estricto (hard gate).