Вы читаете пятый пост цикла "дизайнеру – о технологиях". Цикла, в котором я рассказываю про базовые технические вещи из мира IT-разработки. Ссылки на остальные статьи цикла вы найдёте, когда дочитаете до конца этот пост – и крайне рекомендую это сделать, будет весело.
О чём пост?
Данные передаются. А кто из вас может уверенно сказать, что знает если не все, то хотя бы самые популярные способы передачи данных в Сети? Как работает форма комментариев на медиуме и хабре? Что такое асинхронная передача и почему она – де-факто стандарт отправки данных из форм? А как браузер определяет, что вам пора получить веб-пуш о новом посте из любимого блога? Столько вопросов… Отвечать на них я, конечно, не буду.
Ну или не на все. Давайте я расскажу только о разнице между синхронными и асинхронными запросами, плюс немного углублюсь в последние.
Передача данных
Вообще, дизайнер/проектировщик должен иметь хотя бы базовые представления о том, как крутятся данные в Интернете. От способа передачи и получения данных с сервера напрямую зависит поведение интерфейсов: например, будет ли график перестраиваться в реальном времени, раз в секунду или придется перезагружать страницу.
Придумать можно всё что угодно – но если выбранный вашей командой фреймворк поддерживает из коробки веб-сокеты, странно этим не воспользоваться.
Синхронная передача
Синхронная передача – это просто. Нажали на кнопку отправки формы, данные улетели на другой URL, вас перекинуло на новую страницу. По факту, когда вы открываете новую страницу в браузере – он как раз выполняет синхронный запрос данных.
Вот как это выглядит, если перенести на схему:
Как видите, данные гонятся только в одну сторону и только один раз. Ответа от сервера нет, потому что ответ – и есть та страница, которую вы видите в своём браузере после отправки синхронного запроса.
Асинхронная передача
Асинхронная передача данных позволяет отправить и получить данные без необходимости перезагружать страницу.
Самые распространенные сейчас способы асинхронной передачи - это Ajax и WebSockets. Есть еще тьма всяких других, синхронных и асинхронных, но они либо редки, либо вы и так о них знаете.
Ajax. Есть клиент с чатом, например, и есть сервер. Клиент открывает соединение к серверу, запрашивает какие-то данные, какие-то отправляет. Допустим, клиент отправляет на сервер сообщение в чат, и запрашивает информацию о новых сообщениях в этом чате. Сервер ответил, все, закрыто соединение. Для следующего нужно еще раз сделать запрос.
Как это работает? Примерно вот так:
А есть WebSockets. Тут тоже клиент с чатом и тоже сервер. Только здесь клиент один раз открывает двусторонний “канал”, а дальше данные гоняются до посинения в обе стороны. То есть, в отличии от Ajax, сервер сам может инициировать отправку сообщений. Оборвался интернет – сервис дождётся восстановления и сам откроет сокет снова. Сказка.
В случае с чатом, веб-сокеты, конечно, предпочтительнее. А вот, например, в случае с формой обратной связи – вовсе нет, тут незачем держать канал – можно и простым одноразовым аяксом обойтись.
Пример
Представьте, что у вас есть два контент-менеджера, которые вознамерились одновременно править одну и ту же статью в корпоративном блоге. Если один что-то поправит (например, ошибки), потом – второй (картинки добавит), то после того, как второй сохранит результат, он перезатрёт работу первого.
Чтобы этого не допустить, умный интерфейс должен "слушать" браузеры менеджеров, и, как только первый зашёл в статью, закрывать к ней доступ второму. А как только этот первый закончил редактировать, мгновенно подтягивать изменения и снимать блокировку.
То есть, по факту, система должна пробросить тоннель между менеджерами через сервер. И слушать его в реальном времени. А так можно вообще технологически? Теперь вы знаете, что можно. И что это "можно" называется веб-сокетами.
Ещё из цикла
Если вы не нашли в цикле чего-то, что ожидали или хотели бы там увидеть – обязательно пишите в комментариях. Буду дополнять.
- Фреймворки – что это такое и какие бывают.
--
Все свои посты я аккумулирую в небольшом телеграм-канале, подписывайтесь.