Да, согласен, но у разных команд может быть совершенно разный опыт, и если в небольшом проекте, где редко вносятся изменения, действительно хватает пары флагов, то в масштабных продуктах с непрерывными релизами и сложной логикой бывает, что десяток-другой флагов — это норма. В таких случаях они служат не просто временными переключателями, а полноценным механизмом управления поведением приложения без отката или внепланового деплоя. Кроме того, при грамотной организации эти флаги не обрастают огромным количеством условий: многие из них живут краткосрочно (эксперименты, релизные флаги) и быстро удаляются, остальные остаются как «константные настройки» или аварийные рубильники.
Конечно, если пользователь имеет доступ к собственному фронтенду, он, разумеется, может теоретически модифицировать код или подменить ответы. Но вопрос в том, где реально «живет» логика, влияющая на систему. Если весь функционал, включая критичные операции, обрабатывается только в клиенте, то безопасность действительно страдает, независимо от наличия или отсутствия фич-флагов. Но если важные решения принимает бэкенд — например, проверяет, действительно ли пользователь может вызвать ту или иную функцию, — тогда проверка фича-флага на стороне сервера даёт гарантию, что его подмена «на клиенте» не даст злоумышленнику несанкционированного доступа.
В этом смысле «мнимая безопасность» возникает, когда флаг используют как единственный рубеж защиты, не дублируя проверку на бэкенде. В таких случаях согласен, если вся логика только на фронтенде, то действительно любой «мамкин хакер» может увидеть флаг и нажать на нерабочую кнопку, не получив при этом никаких реальных полномочий. Но в серьёзных проектах, где критичные действия исполняются на сервере (выдача прав, проведение транзакций, доступ к данным), наличие проверки флага на бэкенде исключает риск того, что «включённая кнопка» приведёт к обходу бизнес-логики. Ведь если сервер видит, что у пользователя нет прав (или флаг у него неактивен), он вернёт ошибку.
Что же касается высоконагруженных систем и «реалтайма», то речь не о запросах флагов каждые 5 мс. Главный смысл в том, что при масштабной распределённой архитектуре мы не хотим, чтобы каждый микросервис, мобильный клиент или фронтенд сам хранил состояние всех флагов в статичных конфигах. Мы предпочитаем их обновлять в едином месте и распространять изменения, не дожидаясь перезапуска приложения. Если ваши флаги меняются редко и вы готовы перезапускать сервис, всё может отлично работать и с локальной конфигурацией. Но в крупных проектах флаги часто переключают «на лету» (для тестов, экспериментов, отката или постепенного выкатывания). В таком сценарии они перестают быть лишь частью стартовой конфигурации, и тогда централизованное решение действительно упрощает жизнь команде и снижает риски.
К примеру, при работе в условиях санкций, ваше мобильное приложение может быть удалено из app store, в таком случае фича флаги позволяют включать или выключать некий функционал в мобильном приложении «на лету», что довольно удобно.
Понимаю, что развернутый текст может восприниматься как «водный», но хотелось подробно раскрыть тему для тех, кто впервые сталкивается с централизованными фич-флагами. По поводу проверок на бэкенде: если фича меняет бизнес-логику, доступы или безопасность, то проверять флаг на сервере надежнее, чем на клиенте, поскольку злоумышленник может модифицировать фронтенд-код. К тому же, кэшировать фичи на клиенте не всегда уместно — при недоступности нашего основного API значения флагов там, скорее всего, собьются в отключенное состояние. А если мы говорим о высоконагруженных системах, то отдавать клиентам флаги прямо из «центра» может быть и вовсе нежелательно, так как это небезопасно и создаёт риски утечек. В итоге каждая команда решает, что им подходит: иногда флаги удобно проверять на фронте (особенно когда всё сводится к UI), но в более сложных сценариях или при жёстких требованиях к безопасности серверные проверки оказываются надёжнее. И да, регулярное удаление устаревших флагов действительно необходимо, иначе кодовая база зарастает условностями и приносит больше вреда, чем пользы.
На практике это решается так, что сервис фич-флагов не «дёргается» при каждом запросе к вашему приложению. Большинство SDK один раз загружает и периодически обновляет состояние флагов, храня их локально в памяти. Таким образом, реальный оверхед сводится к минимуму, а преимущества — динамическое и централизованное управление.
Конечно, все это актуально только в том случае, если ИТ отдел довольно большой.
Я имел в виду не буквальный отказ от операторов «if» в коде, а уход от локальных «зашитых» переключателей, разбросанных по проекту и не связанных между собой. Короткий if, завязанный на централизованный флаг, остаётся, но сам флаг и логика его включения/выключения уезжают в единое управляемое место. Так мы можем гибко и безопасно менять поведение приложения, не меняя код ради каждой правки.
Да, согласен, но у разных команд может быть совершенно разный опыт, и если в небольшом проекте, где редко вносятся изменения, действительно хватает пары флагов, то в масштабных продуктах с непрерывными релизами и сложной логикой бывает, что десяток-другой флагов — это норма. В таких случаях они служат не просто временными переключателями, а полноценным механизмом управления поведением приложения без отката или внепланового деплоя. Кроме того, при грамотной организации эти флаги не обрастают огромным количеством условий: многие из них живут краткосрочно (эксперименты, релизные флаги) и быстро удаляются, остальные остаются как «константные настройки» или аварийные рубильники.
Конечно, если пользователь имеет доступ к собственному фронтенду, он, разумеется, может теоретически модифицировать код или подменить ответы. Но вопрос в том, где реально «живет» логика, влияющая на систему. Если весь функционал, включая критичные операции, обрабатывается только в клиенте, то безопасность действительно страдает, независимо от наличия или отсутствия фич-флагов. Но если важные решения принимает бэкенд — например, проверяет, действительно ли пользователь может вызвать ту или иную функцию, — тогда проверка фича-флага на стороне сервера даёт гарантию, что его подмена «на клиенте» не даст злоумышленнику несанкционированного доступа.
В этом смысле «мнимая безопасность» возникает, когда флаг используют как единственный рубеж защиты, не дублируя проверку на бэкенде. В таких случаях согласен, если вся логика только на фронтенде, то действительно любой «мамкин хакер» может увидеть флаг и нажать на нерабочую кнопку, не получив при этом никаких реальных полномочий. Но в серьёзных проектах, где критичные действия исполняются на сервере (выдача прав, проведение транзакций, доступ к данным), наличие проверки флага на бэкенде исключает риск того, что «включённая кнопка» приведёт к обходу бизнес-логики. Ведь если сервер видит, что у пользователя нет прав (или флаг у него неактивен), он вернёт ошибку.
Что же касается высоконагруженных систем и «реалтайма», то речь не о запросах флагов каждые 5 мс. Главный смысл в том, что при масштабной распределённой архитектуре мы не хотим, чтобы каждый микросервис, мобильный клиент или фронтенд сам хранил состояние всех флагов в статичных конфигах. Мы предпочитаем их обновлять в едином месте и распространять изменения, не дожидаясь перезапуска приложения. Если ваши флаги меняются редко и вы готовы перезапускать сервис, всё может отлично работать и с локальной конфигурацией. Но в крупных проектах флаги часто переключают «на лету» (для тестов, экспериментов, отката или постепенного выкатывания). В таком сценарии они перестают быть лишь частью стартовой конфигурации, и тогда централизованное решение действительно упрощает жизнь команде и снижает риски.
К примеру, при работе в условиях санкций, ваше мобильное приложение может быть удалено из app store, в таком случае фича флаги позволяют включать или выключать некий функционал в мобильном приложении «на лету», что довольно удобно.
Понимаю, что развернутый текст может восприниматься как «водный», но хотелось подробно раскрыть тему для тех, кто впервые сталкивается с централизованными фич-флагами. По поводу проверок на бэкенде: если фича меняет бизнес-логику, доступы или безопасность, то проверять флаг на сервере надежнее, чем на клиенте, поскольку злоумышленник может модифицировать фронтенд-код. К тому же, кэшировать фичи на клиенте не всегда уместно — при недоступности нашего основного API значения флагов там, скорее всего, собьются в отключенное состояние. А если мы говорим о высоконагруженных системах, то отдавать клиентам флаги прямо из «центра» может быть и вовсе нежелательно, так как это небезопасно и создаёт риски утечек. В итоге каждая команда решает, что им подходит: иногда флаги удобно проверять на фронте (особенно когда всё сводится к UI), но в более сложных сценариях или при жёстких требованиях к безопасности серверные проверки оказываются надёжнее. И да, регулярное удаление устаревших флагов действительно необходимо, иначе кодовая база зарастает условностями и приносит больше вреда, чем пользы.
На практике это решается так, что сервис фич-флагов не «дёргается» при каждом запросе к вашему приложению. Большинство SDK один раз загружает и периодически обновляет состояние флагов, храня их локально в памяти. Таким образом, реальный оверхед сводится к минимуму, а преимущества — динамическое и централизованное управление.
Конечно, все это актуально только в том случае, если ИТ отдел довольно большой.
Я имел в виду не буквальный отказ от операторов «if» в коде, а уход от локальных «зашитых» переключателей, разбросанных по проекту и не связанных между собой. Короткий if, завязанный на централизованный флаг, остаётся, но сам флаг и логика его включения/выключения уезжают в единое управляемое место. Так мы можем гибко и безопасно менять поведение приложения, не меняя код ради каждой правки.