Статьи

Ably Masterclass, Episode 1 – Создание приложения для голосования в реальном времени менее чем за час

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

Итак, в этом посте я кратко излагаю то, что произошло, а также ссылки на некоторые полезные ресурсы для ознакомления.

Я разместил слайды в Интернете, чтобы вы могли проверить их!

Поскольку это был первый эпизод серии, я подумал, что было бы лучше начать с вступления к тому, что означает «в реальном времени», и демистифицировать некоторые модные слова, такие как Pub / Sub, постоянные соединения, системы, управляемые событиями и т. Д. объяснил это ниже:

Супер краткое введение в концепции реального времени

С момента появления Интернета его участвующие субъекты общались по общеизвестному протоколу передачи гипертекста (HTTP) . У вас есть запросы и ответы, а также новые циклы подключения для каждого стиля запроса-ответа. Это сработало невероятно хорошо для приложений, где основная цель — получить некоторые данные, отправить некоторые данные или выполнить некоторые вычисления на стороне сервера.

REST-запросы

Но в последние пару лет обмен данными перешел к более ориентированному на события подходу. Это означает, что участвующие субъекты заинтересованы в получении уведомления о чем-либо, как только это произошло. Это тот тип общения, который в народе называют «в реальном времени». Примерами таких приложений являются приложения для отслеживания местоположения в режиме реального времени, приложения для чата, приложения для викторин в стиле HQ, потоки данных в реальном времени с ценами на биткойны, фондовые рынки и новости, и многие другие.

Примеры потоковой передачи в реальном времени


Если вы думаете о таких приложениях, традиционная связь на основе HTTP с использованием запросов REST не дотягивает. Необходимость устанавливать новые циклы соединения каждый раз, инициируемые клиентом связи, не говоря уже о перегрузке данных, приводит к большой задержке — и если есть одна важная вещь для приложения, которое является «в реальном времени», это то, что оно способно общения с минимально возможной задержкой.

Так что если не HTTP, то, возможно,
Long Polling ? Ну, длинный опрос имеет почти те же недостатки, что и HTTP-связь, когда речь идет о приложениях реального времени. Конечно, они могут держать соединение открытым до тех пор, пока у сервера не будет данных для возврата в ответ, но нам нужно что-то, что может позволить серверу взаимодействовать с клиентом в любое время. Другими словами, сервер инициировал связь. Таким образом, длинный опрос тоже не вариант.

Именно здесь в игру вступает понятие «подписки в реальном времени». Существуют определенные протоколы реального времени, такие как WebSockets, MQTT и SSE, которые позволяют осуществлять передачу на основе push (в отличие от способа получения обновлений через HTTP на основе pull). Давайте кратко рассмотрим WebSockets:

WebSockets

Связь начинается как HTTP-запрос, но с дополнительным заголовком обновления. Если другая сторона также совместима с WebSockets, соединение обновляется, что приводит к полнодуплексному (связь возможна в обоих направлениях) и постоянному (соединение может оставаться открытым столько, сколько вам нужно). Это прекрасно работает для приложений, управляемых событиями, так как любой объект, желающий поделиться и обновить, просто передает данные другим клиентам, и они немедленно получают уведомление (задержка составляет порядка нескольких миллисекунд).

Так вступает в игру концепция издателей и подписчиков. Теперь, когда все стало более понятно, давайте перейдем к приложению, которое я создал во время вебинара. Опять же, помните, я делаю только краткое изложение вещей, которые я рассмотрел в мастер-классе здесь. Вы действительно должны смотреть на запись для получения подробной информации о концепциях в реальном времени, а также о приложении для голосования.

Кодирование приложения для голосования с нуля

Таким образом, конечный результат приложения, которое я создал, выглядел примерно так:

Окончательная заявка

Как вы можете видеть, это две отдельные сущности или приложения: один — интерфейс голосования для голосования с использованием основных кнопок HTML, а другой — диаграмма, показывающая итоговые голоса для разных вариантов выбора в форме диаграммы. И о чем я упоминал? Этот график обновляется в режиме реального времени по мере того, как пользователи получают новые голоса.

Эти два приложения взаимодействуют в реальном времени через Ably , мы используем Fusioncharts для удобного построения диаграммы с нашими данными, и все это приложение открыто размещается с помощью Glitch .

Начиная с приложения с интерфейсом голосования, он представляет собой базовый макет HTML, использует начальную загрузку, чтобы выглядеть красиво, и имеет несколько строк кода для подключения к каналу Ably и публикации голосов по мере их подачи. Вы должны проверить это непосредственно на GitHub, поскольку сообщение в блоге не является хорошим местом для размещения кода. Но опять же, просто подведем итог: способ инициализации Ably, подключения к каналу и начала публикации данных — это всего лишь несколько строк кода:


Джава