Комментарии 15
Забудьте о локальных if-ах
Тем временем:
if (isNewDiscountEnabled) {
Я имел в виду не буквальный отказ от операторов «if» в коде, а уход от локальных «зашитых» переключателей, разбросанных по проекту и не связанных между собой. Короткий if, завязанный на централизованный флаг, остаётся, но сам флаг и логика его включения/выключения уезжают в единое управляемое место. Так мы можем гибко и безопасно менять поведение приложения, не меняя код ради каждой правки.
Делать HTTP запрос на фичу-флаг по-моему перебор.
Можно загрузить состояние всех фиче флагов за раз при старте приложения. Можно поставить им expire time, если нужно.
Это все ещё лучше, чем делать новый релиз, в случае проблем с новой фичей. Особенно, в случае с мобилками, где доставка на пользовательское устройство может занимать дни.
На практике это решается так, что сервис фич-флагов не «дёргается» при каждом запросе к вашему приложению. Большинство SDK один раз загружает и периодически обновляет состояние флагов, храня их локально в памяти. Таким образом, реальный оверхед сводится к минимуму, а преимущества — динамическое и централизованное управление.
Конечно, все это актуально только в том случае, если ИТ отдел довольно большой.
Но сколько же воды. Можно же это как-то проще донести! Плюсы и минусы без раздувания текста "белым шумом" Сами на проекте используем флаги и это очень удобно с точки зрения модульной разработки. Подход к работе с флагами должен быть регламентирован на уровне процесса разработки. Проверять фф на бекэнде полный бред. Фронт может и, обычно, разрабатывается быстрее бекэнда - сделал задачу закрыл флагом, перешёл к следующей. Очистка кодовой базы от выпущенных флагов должна быть организована на постоянной основе после каждого релиза.
Понимаю, что развернутый текст может восприниматься как «водный», но хотелось подробно раскрыть тему для тех, кто впервые сталкивается с централизованными фич-флагами. По поводу проверок на бэкенде: если фича меняет бизнес-логику, доступы или безопасность, то проверять флаг на сервере надежнее, чем на клиенте, поскольку злоумышленник может модифицировать фронтенд-код. К тому же, кэшировать фичи на клиенте не всегда уместно — при недоступности нашего основного API значения флагов там, скорее всего, собьются в отключенное состояние. А если мы говорим о высоконагруженных системах, то отдавать клиентам флаги прямо из «центра» может быть и вовсе нежелательно, так как это небезопасно и создаёт риски утечек. В итоге каждая команда решает, что им подходит: иногда флаги удобно проверять на фронте (особенно когда всё сводится к UI), но в более сложных сценариях или при жёстких требованиях к безопасности серверные проверки оказываются надёжнее. И да, регулярное удаление устаревших флагов действительно необходимо, иначе кодовая база зарастает условностями и приносит больше вреда, чем пользы.
Злоумышленник всегда может модифицировать код на фронте. И проверки флагов на бэкеде тут не помогут) С той же лёгкостью подменяется ответ... Это мнимая безопасность и, честно, непонятно, что вы этого не понимаете. Если у вас логика приложения целиком завязана на фронт и это ещё по безопасности бьёт, то у вашего приложения большие проблемы. Максимум что долго быть при несанкционированном доступе к флагам(а это не вот прям что-то супер важное) это переключение логики работы фронта. Если бэк не готов, то получаете ошибку на фронте. Ну включил для себя мамкин хакер новую кнопку, а она не работает - увы...
О каких высоконагруженных системах вы говорите? О реалтайм доступе к флагам каждые 5мс при работе? Флаги, они же часть конфигурации приложения, применяются при старте и до следующего перезапуска. Всё...
Точно. Коротко и по делу. А не то что автор наваял.
Конечно, если пользователь имеет доступ к собственному фронтенду, он, разумеется, может теоретически модифицировать код или подменить ответы. Но вопрос в том, где реально «живет» логика, влияющая на систему. Если весь функционал, включая критичные операции, обрабатывается только в клиенте, то безопасность действительно страдает, независимо от наличия или отсутствия фич-флагов. Но если важные решения принимает бэкенд — например, проверяет, действительно ли пользователь может вызвать ту или иную функцию, — тогда проверка фича-флага на стороне сервера даёт гарантию, что его подмена «на клиенте» не даст злоумышленнику несанкционированного доступа.
В этом смысле «мнимая безопасность» возникает, когда флаг используют как единственный рубеж защиты, не дублируя проверку на бэкенде. В таких случаях согласен, если вся логика только на фронтенде, то действительно любой «мамкин хакер» может увидеть флаг и нажать на нерабочую кнопку, не получив при этом никаких реальных полномочий. Но в серьёзных проектах, где критичные действия исполняются на сервере (выдача прав, проведение транзакций, доступ к данным), наличие проверки флага на бэкенде исключает риск того, что «включённая кнопка» приведёт к обходу бизнес-логики. Ведь если сервер видит, что у пользователя нет прав (или флаг у него неактивен), он вернёт ошибку.
Что же касается высоконагруженных систем и «реалтайма», то речь не о запросах флагов каждые 5 мс. Главный смысл в том, что при масштабной распределённой архитектуре мы не хотим, чтобы каждый микросервис, мобильный клиент или фронтенд сам хранил состояние всех флагов в статичных конфигах. Мы предпочитаем их обновлять в едином месте и распространять изменения, не дожидаясь перезапуска приложения. Если ваши флаги меняются редко и вы готовы перезапускать сервис, всё может отлично работать и с локальной конфигурацией. Но в крупных проектах флаги часто переключают «на лету» (для тестов, экспериментов, отката или постепенного выкатывания). В таком сценарии они перестают быть лишь частью стартовой конфигурации, и тогда централизованное решение действительно упрощает жизнь команде и снижает риски.
К примеру, при работе в условиях санкций, ваше мобильное приложение может быть удалено из app store, в таком случае фича флаги позволяют включать или выключать некий функционал в мобильном приложении «на лету», что довольно удобно.
По моему опыту, если приложению нужны фича флаги и их больше 5 - в пртложении продумано что-то неправильно. И потом на их поддержку будет тратиться слишком много времени и сил (=денег)
Да, согласен, но у разных команд может быть совершенно разный опыт, и если в небольшом проекте, где редко вносятся изменения, действительно хватает пары флагов, то в масштабных продуктах с непрерывными релизами и сложной логикой бывает, что десяток-другой флагов — это норма. В таких случаях они служат не просто временными переключателями, а полноценным механизмом управления поведением приложения без отката или внепланового деплоя. Кроме того, при грамотной организации эти флаги не обрастают огромным количеством условий: многие из них живут краткосрочно (эксперименты, релизные флаги) и быстро удаляются, остальные остаются как «константные настройки» или аварийные рубильники.
Я работал в нескольких таких продуктах, где сотни фичи флагов и по несколькукоманд и именно из этого опыта говорю - фичи флаги в таком случае становятся злом, на которое уходит львиная доля времени (бюджета) из-за того, что код становится похож на спагетти. Обычно это значит что у разных клиентов должна быть разная функциональность и вместо отдельного приложения для каждого из клиентов всовывуются костылями фича флаги, и чеоез пару лет это превращается в дресучее легаси.
Как быть с изоляцией теста и прода?
Какое время вы отводить на обновление рычага? Зачем ещё одна точка отказа всего, если ределой занимает секунды и обновит конфигурацию именно там где нужно?
https://openfeature.dev/ стандарт индустрии
Забудьте о локальных if-ах: как централизованные feature flags делают жизнь разработчика проще