OpenFeature визначає vendor-neutral API для feature flags. Застосунок звертається до стабільного SDK-контракту, а provider під’єднує конкретну систему керування прапорцями. Це зменшує залежність бізнес-коду від постачальника, але не скасовує потреби проєктувати lifecycle, fallback і контроль доступу.
Проблема різних SDK
Кожна flag-платформа має власні методи, context, hooks і модель помилок. Після прямої інтеграції міграція торкається сотень викликів. OpenFeature відокремлює evaluation API від provider: код використовує boolean, string, number або object evaluation за спільним контрактом.
Evaluation context
Контекст містить атрибути, потрібні для правила: environment, tenant, тип клієнта або стабільний псевдонім. Не передавайте все, що є в профілі. Мінімізація зменшує витік даних до провайдера й ризик випадково створити сегмент за чутливою ознакою.
Default value обов’язкове
Кожна evaluation отримує default. Це не формальність, а поведінка під час відсутнього flag, помилки provider або неправильного типу. Значення вибирають fail-safe: платіж не повинен випадково ввімкнути експеримент, а захисний контроль — вимкнутися через outage.
Provider і домени
Provider реалізує зв’язок із backend. Domains дають змогу використовувати різні providers або конфігурації для частин застосунку. Важливо не дозволити бібліотеці непомітно змінювати глобальний provider під час runtime: ініціалізацію та shutdown контролює composition root.
Hooks
Hooks виконуються до, після, при помилці та наприкінці evaluation. Через них додають telemetry, validation або policy, але не приховану бізнес-логіку. Hook має бути швидким і не змінювати результат непередбачувано, інакше flag evaluation стане неявним distributed workflow.
Події й кешування
SDK може повідомляти про готовність, зміну конфігурації та помилку. Застосунок не повинен перезапускати важку операцію на кожен event без debounce. Для локального кешу визначають freshness, стартову поведінку та те, чи допустиме використання останнього відомого набору під час втрати зв’язку.
OpenFeature не керує lifecycle
Стандартний API не вирішує, коли прапорець видалити. Практичні правила з ownership, expiry date і cleanup описано в статті про безпечне використання feature flags. Без цього нейтральний SDK лише робить технічний борг переносним.
Міграція без зупинки
- обгорніть наявний SDK у provider;
- зафіксуйте типи, defaults і semantics помилок;
- порівнюйте рішення старої та нової систем у shadow mode;
- переносьте домени по одному;
- видаліть adapter лише після закриття всіх розбіжностей.
Спостережуваність без витоку
У telemetry корисні flag key, variant, reason і error code, але не повний evaluation context. Кардинальність user identifiers швидко збільшує вартість, про що попереджає матеріал про контроль витрат на спостережуваність. Для product analytics і operational metrics встановлюють різні правила доступу та retention.
Evaluation semantics між серверами
Два providers можуть по-різному трактувати відсутній attribute, hashing і percentage rollout. Під час міграції недостатньо зіставити flag keys. Створіть набір golden contexts із очікуваними variants і запускайте contract tests для кожної SDK-мови. Особливо перевіряйте Unicode, null, numeric conversions і порядок правил.
Flag metadata
Evaluation details можуть містити variant, reason, error code та provider metadata. Бізнес-код не повинен залежати від vendor-specific полів, інакше abstraction руйнується. Водночас reason корисний для діагностики: TARGETING_MATCH, DEFAULT або ERROR пояснюють однакове значення з різним походженням.
Безпека адміністративного контуру
OpenFeature стандартизує runtime evaluation, але не панель керування. RBAC, approval, audit log і separation of duties залишаються у flag service. Зміна прапорця, що впливає на authentication або billing, повинна проходити такий самий контроль, як production configuration.
Тестування відмови
Відключіть provider, поверніть неправильний тип, прострочіть cache і створіть повільний hook. Перевірте, що request не зависає, default справді безпечний, а alert не містить персонального context. Відновлення service не повинно одночасно перемкнути всі instances без оцінки навантаження.
Готова інтеграція має inventory flags, owners, expiry і доказ cleanup. Коли експеримент завершено, команда видаляє evaluation calls, правила й provider data в контрольованому порядку. Інакше старі прапорці залишають приховані гілки, які не тестуються, але можуть випадково активуватися.
Першоджерело: OpenFeature Specification.
Коментарі
Щоб залишити коментар, увійдіть через Google.