Как сделать свой SDK для Remote Config

Если вы используете Firebase Remote Config для работы с фиче-флагами, то, возможно, для вас он станет платным, и кто-то начнёт искать альтернативу.

Мы, на самом деле, уже давно с него мигрировали на другое стороннее решение из-за высоких рисков блокировки, а теперь полностью переходим на собственный сервис. Хочется поделиться особенностями разработки такого SDK.

Начать стоит с выделения фасада с базовыми методами fetch, activate и get<Type> с Timber-подобным API. Тогда вы сможете с лёгкостью заменить одно решение другим.

При реализации собственного SDK нужно учесть несколько важных моментов.

1. Понадобятся три вида хранилища данных: персистентное для хранения актуальных значений, персистентное для хранения временных значений (после fetch и до activate) и memory cache для моментального получения актуальных значений.

2. Нужно хорошо продумать, как исключить race condition и data race. Первичную инициализацию memory cache лучше сделать блокирующей, чтобы не потерять данные. Для методов fetch и activate лучше использовать общий mutex, чтобы не допустить рассинхронизации значений.

3. Предусмотрите throttle-механизм, чтобы не перегружать ваш бэкенд. При этом заранее продумайте, как будете реализовывать force fetch, когда значения нужно обновить как можно скорее, а также фоновое обновление, если пользователь долго не выгружает приложение из памяти.

В общем, на первый взгляд кажется, что задача простая, но в ней очень много подводных камней. Так что это вполне хороший кейс для собеседования по System Design для мобильных разработчиков.