В анонсе серии статей "Интерактивные сайты" я постарался максимально доходчиво изложить свою мотивацию к ей созданию, да и актуальность самой темы, так что сразу к делу!

Итак, мы хотим сделать так, чтобы с точки зрения пользователя наш сайт выглядел интерактивным. То есть воспринимался не как набор отдельно загружающихся страниц, а скорее как обычное приложение для компьютера. Ему, в целом, не важно как именно мы этого добьемся, главное чтобы при этом браузер вел себя как обычно и визуально все реагировало почти мгновенно.

Сразу хочу предупредить, что далеко не всем сайтам такая глобальная интерактивность пойдет на пользу. Если пользователи сайта редко что-либо делают и большую часть времени читают длинные тексты, то, вероятно, этот проект как раз из этой категории: быстрота реакции на клик не так радует, когда большую часть времени приходится работать скроллом. Если Ваш интернет-проект является сайтом с длинным контентом в формате блога, новостей или вики - подумайте лишний раз, прежде чем переделывать весь сайт, вероятно будет достаточно интерактивных комментариев и голосований на AJAX. Для социальных сетей, сайтов знакомств, интернет-магазинов, поисковых систем, корпоративных сайтов и многих других визуально заметная интерактивность определенно станет одним из ключевых конкурентных преимуществ.

В этом посте я постараюсь нарисовать крупными мазками картину того, как этого можно достичь. Визуально её я представил следующим образом:

Общие замечания

• Здесь и далее я буду описывать "среднестатистический" интернет-проект, в зависимости от специфики могут появляться дополнительные компоненты или убираться за ненадобностью упомянутые. Например, если известно, что пользоваться сайтом будут только сотрудники какой-то компании, то помимо замены Интернета на Интранет, можно запросто избавиться и от HTML-интерфейса и всего, что с ним связано - никаким роботам доступ к нему не нужен.

• Наверное стоит прямым текстом сказать, что:

  • Голубые элементы - компоненты проекта, а серые - внешние.
  • Связи в виде прямых линий означают двусторонний обмен данными, транспорт и формат пока особо не важны.
  • Схема логическая, так что вопросы балансировки нагрузки, отказоустойчивости, репликации и т.п. остались в стороне; за каждым блоком может стоять произвольное количество серверов.

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

• В этом посте не будет никаких конкретных примеров реализации и технологий, оставим это на следующие статьи.

Клиентская часть

• Начнем наше путешествие. Пользователь вводит в адресной строке браузера адрес нашего сайта и жмет Enter, инициируя тем самым сначала определение IP-адреса через DNS, а затем и HTTP-запрос к нашему HTML-интерфейсу.
• Получив в ответ страницу в формате HTML браузер начинает загружать указанные в нем внешние ресурсы, в том числе и Javascript-клиент, которому и передается слово. Сама страница параллельно отрисовывается как и в статичном сайте.
• Как уже упоминалось выше, некоторые проекты решают не тратить силы на поддержку двух интерфейсов к сайту, жертвуя тем самым доступом большинства роботов и браузеров без поддержки JavaScript. Стартовый HTML-документ в этом случае превращается просто в практически пустой статичный файл, который служит лишь для загрузки клиента.
• Так как наша цель стоит в интерактивном взаимодействии пользователем, повторять эти действия при каждом переходе на другую страницу - непозволительная роскошь. Кстати, можно начинать думать и общаться не в терминах страниц, а в терминах экранов, которые видит пользователь.
• Для обеспечения этого JavaScript-клиент должен переопределить стандартные обработчики событий перехода по внутренним ссылкам сайта и отправки форм. Ему нужно отменить стандартный механизм перехода на другую страницу и вместо него отправить запрос через интерфейс сериализованных данных. На основе полученного в ответ сообщения он меняет какую-то часть загруженного ранее HTML-документа, чтобы он соответствовал тому экрану, который ожидал увидеть пользователь. В итоге пользователь видит в браузере ровно ту же картинку, как если бы он ввел тот адрес, на который вела нажатая ссылка, или просто нажал на нее с отключенным JavaScript.
• Важно не сломать при этом поведение браузера: кнопка "назад" должна работать как обычно, а в адресной строке должны меняться ссылки (это актуально, например, когда пользователь отправляет содержимое адресной строки кому-то по почте или через мессенджер).
• При ожидании ответа от сервера стоит эмулировать курсор и иконку загрузки страницы, чтобы пользователь не паниковал в случае (пускай и редком) визуально заметных задержек.

• На резонный вопрос "Почему, собственно, этот трюк обеспечит интерактивность?", ответ хоть и не всегда однозначен, но он все же есть:

  • Сериализованные изменения страницы занимают меньший объем, чем полный HTML со всеми связанными ресурсами, заголовками, версткой и прочим - значительно меньше данных нужно передавать по сети.
  • Как правило, есть возможность держать постоянное соединение между браузером и интерфейсом сериализованных данных, что позволяет не делать лишние HTTP-запросы. Обратная сторона медали - это самое соединение постоянно же использует часть серверных ресурсов, но есть способы минимизировать эти издержки.
  • Для некоторых действий изменения HTML не требуют ответа сервера и могут быть сделаны параллельно с отправкой запроса (например  различные вариации на тему +1 или написание комментария, текст которого можно взять из формы).
  • Как правило, можно предсказать наиболее вероятные переходы по экранам и загрузить необходимые изменения заранее. Хотя этот вопрос скорее из области оптимизации.
  • Таким образом, в большинстве случаев есть техническая возможность снизить время отклика  на действие пользователя с 500-2000 мс в случае неплохо сделанного статического сайта до 20-200 мс., что вполне сопоставимо с откликом десктопного приложения.

• Как все это сделать на практике - тема следующей статьи из серии.

Серверная часть

• С серверной точки зрения основным отличием является четкое разделение двух входных точек:
  • HTML-интерфейс отдает готовые документы в ответ на HTTP-запросы.
  • Интерфейс сериализованных данных использует какое-то постоянное соединение, хотя в некоторых случаях целесообразно ограничиться просто асинхронными HTTP-запросами.
• Если для статичных сайтов полное выделение бизнес-логики в отдельные сервисы - просто хорошее архитектурное решение, то для интерактивных сайтов - это практически необхохимо. Иначе придется реализовывать и поддерживать две копии кода для каждого интерфейса и надеяться, что они постоянно будут оставаться совместимыми и выдавать одинаковый результат.
• Хорошей практикой является использование какого-то одного протокола общения между компонентами системы, в частности пользовательских интерфейсов с сервисами бизнес-логики и последних друг с другом. Желательно использовать что-то бинарное и с поддержкой разных языков программирования, хотя если весь проект на одной платформе и не планирует это менять - можно использовать и стандартный для этой платформы протокол.
• Чтобы не включать элементы верстки при передаче через интерфейс сериализованных данных, рекомендую использовать кроссплатформенный формат HTML-шаблонов. Об этом будет отдельная статья.
• Интерфейс сериализованных данных при необходимости легко может быть адаптирован для использования в роли API для сторонних сервисов или собственных приложений для мобильных платформ или настольных компьютеров.
• В целом внутренние сервисы общаются с остальными располагающимися на серверной части компонентами системы вполне обычным образом.
• В статье про серверную часть подробно будет рассматриваться использование брокера сообщений для уведомлений пользователей в реальном времени.

Подводим итоги

• Глобальная интерактивность сайта требует использования достаточно сложного и комплексного JavaScript-клиента и создания дополнительного более легковесного внешнего инетрфейса на серверной части.
• По-настоящему мгновенной реакцией сайта смогут насладиться лишь пользователи с современным браузером и относительно широким интернет-каналом. Из-за возможных сетевых задержек или особенностей устаревших браузеров эффект мгновенного перехода все же может теряться, но при должном тестировании реально добиться нормального поведения сайта и в таких ситуациях. Хотя зачастую "проваливание" до обычного режима статичных страниц в подобных ситуациях - вполне резонное решение.
• Архитектура серверной части проекта в большинстве случаев не требует существенных изменений. Хотя если в ней все было хаотично и не продумано, то создание интерактивного клиента может послужить неплохим поводом пересмотреть и привести в порядок и её.
• Кроме очевидной потребности в использовании JavaScript для клиента, особых ограничений на используемые технологии и языки программирования, обсуждаемая схема не накладывает.