SyncHub
Чанкинг больших контент-фидов
У крупных клиентов фид — это десятки мегабайт: новостная лента с медиа-метаданными или каталог с полными карточками. Монолитный ответ в один сетевой проход неудобен мобильным сетям: соединение рвётся — начинаем всё заново. Рассказываем, как мы это решаем, не ломая контракт.
Секционирование внутри тела
Ответ остаётся одним GET-запросом и одним снапшотом — но тело секционировано: внутри фиксированный порядок секций, каждая упакована независимо. Клиентская библиотека применяет секции лениво: первый экран контента отрисовывается до полной загрузки тела, а обрыв соединения повторяется точечно — с той же идемпотентностью GET, что и раньше.
Атомарные версии
Каждая секция несёт номер версии снапшота. Публикация новой версии пересобирает все секции атомарно: клиент никогда не видит смесь двух версий контента — либо целиком старый снапшот, либо целиком новый. Это позволяет нам переупаковывать секции между релизами, не меняя контракт.
Почему не пагинация в API
Пагинация дробит контракт: страницы «уезжают» между запросами, идемпотентность теряется, кэшировать такое нельзя (а наши ответы и так персональные — no-store). Один GET — один полный снапшот: предсказуемо для клиента, для ретраев и для логов. Крупность фида — внутреннее дело формата тела, а не параметров запроса.
Метрики
- Время до первого экрана контента: −42% на тестовой матрице устройств.
- Секции по ~512 КБ после упаковки — комфортно для мобильных сетей.
- Доля оборванных синхронизаций, требующих полного повтора: 3.1% → 0.4%.
Контракт запроса не изменился — см. документацию.