Froggle — фича-флаги без боли

Бороздя просторы космоса Хабра, рабочих репозиториев и не только, в сегменте Java разработчиков и других JVM динозавров, была обнаружена извественная проблема, большинство фич закрыты фича-флагами в виде простых переменных в коде (иногда чересчур замедруенными). И в этом хаосе родилась идея просто менеджера флагов для разных приложений.

В мире кубов и контейнеров JVM приложения чувствуют себя немного странного когда речь заходит о вопросах: кто сожрал все ресурсы в кластере? или как же мне вывернуть приложение чтобы не рестартить его? Со вторым вопросом предлагаю ознакомится ближе.
Механизм рефреша конфигураций есть:

1. В спринге в виде /actuator/refresh, но он не гарантирует консистентность между всеми потоками приложения, риск race conditions и деградации приложения

2. JMX — практически невозможен в продовой среде для наших целей

3. Jolokia — риски безопасности, часто в read‑only в проде

Многие и многие менеджеры и продакты отдали бы многое за систему которая в рантайме изменяет поведение системы в один клик, да еще и с раскаткой на n% юзеров! (все же ведь любят канареек?)

Так о чем я, родилась идея легковесного хранилища/менеджера флагов для любых бэк-енд приложений, мобилок или фронт-энда через REST/GRPC взаимодействие.

create table flags(    id            uuid                     default gen_random_uuid() not null        primary key,    key           text                                               not null        unique,    description   text,    enabled       boolean                  default false             not null,    default_value boolean                  default false             not null,    created_at    timestamp with time zone default now()             not null,    updated_at    timestamp with time zone default now()             not null,    status        text                     default 'draft'::text     not null        constraint flags_status_check            check (status = ANY                   (ARRAY ['draft'::text, 'active'::text, 'inactive'::text, 'deprecated'::text, 'archived'::text])));

• key — самое важное о чем спрашивают подписанные клиенты

• status — простой статус для жизненным циклом флага

• default_value — с каким статусом создался флаг

• enabled — свойство включен ли флаг?

У флагов предусмотрены опциональные условия, которым должены удовлетворить параметры передаваемые клиентами

create table targeting_rules(    id           uuid                     default gen_random_uuid() not null        primary key,    flag_id      uuid                                               not null        references flags            on delete cascade,    priority     smallint                                           not null,    attribute    text                                               not null,    operator     text                                               not null,    value        jsonb                                              not null,    return_value boolean                                            not null,    created_at   timestamp with time zone default now()             not null,    unique (flag_id, priority));

• flag_id — с каким флагом связано правило
  attribute — название параметра сравнения

• operator — eq, neq, in, not_in,

• value — целевое значение аттрибута

• return_value — что вернуть если правило совпало, пока boolean, возможны расширения до любого типа

В базовом виде вот и весь состав системы и флагов, клиент передает в evaluation‑api набор параметров, evaluation‑api получает данные о флаге, если их нет в кэше из бд, кеширует и отдает клиенту его значение. В случае обновления core‑engire через pg_notify пушит изменения флага в evaluation‑api и тот в свою очередь кеширует их, либо пушит изменения подписчикам GRPC.

На подходе rollout с реализацией консистентного хранения флагов для клиентов, нельзя же просто использовать random() < 0.1, поэтому чтобы один пользователь не всегда попадал в одну и ту же группу на всех флагах придется искать подход, или спрашивать у нейронки умных людей.