Предположим, у нас есть мобильный тонкий клиент, слабенький, с плохим каналом связи, и нам нужно с его помощью показывать один из статусов сложной системы. Такой, которая определяется большим количеством независимых параметров и имеет сильно распределённую архитектуру. Например, вы заказали строительство дома и с помощью приложения отслеживаете текущее состояние стройки, которое определяется статусами работ подрядчиков: электриков, юристов, отделочников, монтажников… У каждого из них своя инфраструктура, не всегда хорошо работающая. 

Чтобы понять общий статус, нам нужно опросить все базы всех подрядчиков, получить от них данные, обработать их и показать сводный статус пользователю. Даже если мы кэшируем данные на бэке и не опрашиваем подрядчиков каждый раз, клиент получает и обрабатывает много данных. Это может стать проблемой при слабом клиенте и плохом канале. Долгие обновления статуса особенно обидны, когда выясняется, что ничего не произошло. Как быть? Ещё, казалось бы, нам в любом случае нужно получать все данные при изменении статуса, ведь пользователь захочет узнать подробности, что поменялось. Будем запрашивать все данные и подсвечивать изменившиеся? 

Оказавшись в подобной ситуации, я предложил команде принцип решения, при котором мы передаём на клиент минимум данных, отображаем общий статус и можем подгружать только те частные подробности, которые интересны пользователю. Поскольку я дизайнер UI/UX, решение тоже будет лежать скорее в поле UX, а статья ограничится описательной частью – про код я вам ничего рассказать по понятным причинам не смогу. Тем не менее, этот способ может стать полезным инструментом в арсенале дизайнеров и архитекторов (ребят, отвечающих за принципиальное устройство продукта), поэтому я и решил о нём рассказать. Он помог нам, может быть, поможет и вам. 

Поехали.