Проектирование реальных фич: Feed App ч 2

В первой части мы поговорили про требования и про главный выбор: pull vs push. Во второй спускаемся на уровень "а что конкретно проектируем?".

Какие экраны, какие API, какие модели, как пагинировать, как устроить клиент, чтобы все было быстрым и живым.

1️⃣ Все начинается с уточнения скоупа работ:
- Feed: бесконечный скролл, лайк и шаринг, тапы, детальная страница, форма для создания поста.
- Create Post: текст + вложения (картинки/видео)
- Post Detail: полный контент + действия

И отдельно важная скрытая фича, которую часто ждут на интервью — это prefetching (подгрузить посты заранее, чтобы открыть ленту быстрее)

2️⃣ API

Дальше идем в проектирования API-контракта. Смысл API-дизайна в интервью простой. Вот вы договорились как клиент и сервер будут говорить, и дальше не спорите “а откуда это берется”. Здесь очень важно не перезагружать данными модели. Нужно их обрезать чтобы не перегружать сеть; не убивать память/CPU клиента; не тянуть тяжелые вложения без необходимости

Особенно когда с интернетом беда.

3️⃣ Пагинация

Для ленты почти всегда выбирают cursor-based pagination. Я еще делился прикольным докладом про пагинацию тут.

Почему offset не идеальный вариант:
- лента часто обновляется: пока ты листаешь, сверху приходят новые посты, а окно может смещаться
- чем глубже offset, тем хуже производительность запросов на больших объёмах данных

Cursor-подход лучше, потому что опирается на индексируемое поле и дает стабильный следующий блок даже если сверху добавились новые посты

4️⃣ Архитектура клиента: слои и поток данных

Классический подход в структуре — разделять на слои

UI layer — это экраны (Feed / Detail / Create). А за состояниями овечаются ViewModel и Presentor. Навигация должна быть в отдельном компоненте.

Data layer — желательно разделять все на репозитории, data source'ы, а медиа хранить на CDN.

5️⃣ Offline-first и “Single Source of Truth” на клиенте

В той самой книге по проектированию автор говорит, что для мобильной ленты это прям must-have, потому что сеть бывает медленная, нестабильная и пропадает во время скролла. Автор советует:
- все, что пришло с бэка, нужно сразу писать в локальную БД
- UI читает данные из локальной БД, даже когда интернет есть
- при оффлайне показываем кэш и аккуратно сообщаем, что обновиться не можем. Это и есть "Backend -> Local Storage -> UI" как единый стабильный пайплайн

✅ Что интервьюер хочет услышать?
- Нужно отдавать в ленту Preview, чтобы не тянуть тяжелые данные
- Пагинация cursor, потому что лента часто обновляется
- Клиент offline-first, local DB — SSOT, UI читает из нее
- Статику раздаем через CDN, чтобы ускорить ленту и снять нагрузку

Кстати, по ленте. Еще около года назад скинули фотку как результаты опроса из нашего канала использовали в докладе

Тогда это был доклад Саши Сычева @headOfMobile. Он был кросс-лидом Feed в Яндекс Го

По выбранному ответу можно сделать все же выводы, что не всегда Feed можно комфортно сделать на BDUI 🫣

📺 Swift Concurrency + Swift 6 на практике

Предновогодний подгон. Опубликовали в открытый доступ видос по Swift 6 + Swift Councurrency.

Пообщались о том, как в реальной практике живется на современном стэке.

В выпуске:
🟣с какими неожиданностями пришлось столкнуться при переводе боевоего проекта
🟣насколько документация Swift Councurrency помогает в реальных задачах
🟣что изменилось в правилах языка и почему об этом важно знать
🟣практическими советами и лайфхаками для разработки
🟣лучшие материалы для обучения

Доступ к другим видео и материалам 💰тут или ⭐️ тут