Еще месяц назад в Ably появилась идея провести ежемесячную серию мастер-классов, и вчера я провел первый эпизод, где я учил аудиторию, как они могут создать приложение для голосования в реальном времени менее чем за час.
Итак, в этом посте я кратко излагаю то, что произошло, а также ссылки на некоторые полезные ресурсы для ознакомления.
Я разместил слайды в Интернете, чтобы вы могли проверить их!
Поскольку это был первый эпизод серии, я подумал, что было бы лучше начать с вступления к тому, что означает «в реальном времени», и демистифицировать некоторые модные слова, такие как Pub / Sub, постоянные соединения, системы, управляемые событиями и т. Д. объяснил это ниже:
Супер краткое введение в концепции реального времени
С момента появления Интернета его участвующие субъекты общались по общеизвестному протоколу передачи гипертекста (HTTP) . У вас есть запросы и ответы, а также новые циклы подключения для каждого стиля запроса-ответа. Это сработало невероятно хорошо для приложений, где основная цель — получить некоторые данные, отправить некоторые данные или выполнить некоторые вычисления на стороне сервера.
Но в последние пару лет обмен данными перешел к более ориентированному на события подходу. Это означает, что участвующие субъекты заинтересованы в получении уведомления о чем-либо, как только это произошло. Это тот тип общения, который в народе называют «в реальном времени». Примерами таких приложений являются приложения для отслеживания местоположения в режиме реального времени, приложения для чата, приложения для викторин в стиле HQ, потоки данных в реальном времени с ценами на биткойны, фондовые рынки и новости, и многие другие.
Если вы думаете о таких приложениях, традиционная связь на основе HTTP с использованием запросов REST не дотягивает. Необходимость устанавливать новые циклы соединения каждый раз, инициируемые клиентом связи, не говоря уже о перегрузке данных, приводит к большой задержке — и если есть одна важная вещь для приложения, которое является «в реальном времени», это то, что оно способно общения с минимально возможной задержкой.
Так что если не HTTP, то, возможно,
Long Polling ? Ну, длинный опрос имеет почти те же недостатки, что и HTTP-связь, когда речь идет о приложениях реального времени. Конечно, они могут держать соединение открытым до тех пор, пока у сервера не будет данных для возврата в ответ, но нам нужно что-то, что может позволить серверу взаимодействовать с клиентом в любое время. Другими словами, сервер инициировал связь. Таким образом, длинный опрос тоже не вариант.
Именно здесь в игру вступает понятие «подписки в реальном времени». Существуют определенные протоколы реального времени, такие как WebSockets, MQTT и SSE, которые позволяют осуществлять передачу на основе push (в отличие от способа получения обновлений через HTTP на основе pull). Давайте кратко рассмотрим WebSockets:
Связь начинается как HTTP-запрос, но с дополнительным заголовком обновления. Если другая сторона также совместима с WebSockets, соединение обновляется, что приводит к полнодуплексному (связь возможна в обоих направлениях) и постоянному (соединение может оставаться открытым столько, сколько вам нужно). Это прекрасно работает для приложений, управляемых событиями, так как любой объект, желающий поделиться и обновить, просто передает данные другим клиентам, и они немедленно получают уведомление (задержка составляет порядка нескольких миллисекунд).
Так вступает в игру концепция издателей и подписчиков. Теперь, когда все стало более понятно, давайте перейдем к приложению, которое я создал во время вебинара. Опять же, помните, я делаю только краткое изложение вещей, которые я рассмотрел в мастер-классе здесь. Вы действительно должны смотреть на запись для получения подробной информации о концепциях в реальном времени, а также о приложении для голосования.
Кодирование приложения для голосования с нуля
Таким образом, конечный результат приложения, которое я создал, выглядел примерно так:
Как вы можете видеть, это две отдельные сущности или приложения: один — интерфейс голосования для голосования с использованием основных кнопок HTML, а другой — диаграмма, показывающая итоговые голоса для разных вариантов выбора в форме диаграммы. И о чем я упоминал? Этот график обновляется в режиме реального времени по мере того, как пользователи получают новые голоса.
Эти два приложения взаимодействуют в реальном времени через Ably , мы используем Fusioncharts для удобного построения диаграммы с нашими данными, и все это приложение открыто размещается с помощью Glitch .
Начиная с приложения с интерфейсом голосования, он представляет собой базовый макет HTML, использует начальную загрузку, чтобы выглядеть красиво, и имеет несколько строк кода для подключения к каналу Ably и публикации голосов по мере их подачи. Вы должны проверить это непосредственно на GitHub, поскольку сообщение в блоге не является хорошим местом для размещения кода. Но опять же, просто подведем итог: способ инициализации Ably, подключения к каналу и начала публикации данных — это всего лишь несколько строк кода:
Джава
xxxxxxxxxx
1
// Init Ably library
2
var realtime = new Ably.Realtime({ key: '<YOUR-ABLY-API-KEY>' });
3
// Attach to a channel
4
var myVotingChannel = realtime.channels.get('voting-channel')
5
// Publish data on the channel
6
var castVote = function(choice){
7
myVotingChannel.publish('vote', choice, (err)=>{
8
console.log(err);
9
});
10
}
Теперь в приложении для диаграмм это также базовый HTML-макет с <div>тегом- заполнителем для размещения диаграммы, которая будет отображаться по мере поступления данных. Основные вещи, которые необходимо сделать в этом приложении:
- Ити Аблы
- Присоединить к каналу голосования
- Подписаться на этот канал
- Передайте входящие данные на график
Джава
x
1
var realtime = new Ably.Realtime({key: '<YOUR-ABLY-API-KEY>'});
2
var myVotingChannel = realtime.channels.get('voting-channel');
3
myVotingChannel.subscribe('vote', (msg)=>{
4
console.log(msg.data);
5
// pass this onto the chart
6
}
А для самой диаграммы основные вещи, которые необходимо сделать:
- Подготовить данные в формате массива объектов
- Укажите метаданные для диаграммы, такие как тип, размеры, подписи, оси и т. Д.
- Инициируйте FusionCharts и визуализируйте диаграмму с указанными ниже атрибутами.
Джава
xxxxxxxxxx
1
// Preparing the chart data
3
const chartData = []
4
// Chart Configuration
6
const chartConfig = {
7
type: "pie2d",
8
renderAt: 'chart-container',
9
id: 'vote-chart',
10
width: "100%",
11
height: "400",
12
dataFormat: "json",
13
dataSource: {
14
"chart": {
15
"caption": "If age is only a state of mind",
16
"subCaption": "Which category best describes YOUR state of mind right now?",
17
"theme": "fusion",
18
},
19
// Chart Data from Step 2
20
"data": chartData
21
}
22
};
23
// Render the chart
25
FusionCharts.ready(function(){
26
var fusioncharts = new FusionCharts(chartConfig);
27
fusioncharts.render();
28
});
Как уже упоминалось, приведенный здесь код является лишь кратким примером, полный исходный код приложения результатов голосования можно найти в репозитории GitHub .
Одно быстрое замечание: FusionCharts не совсем учитывает, что данные могут измениться после визуализации диаграммы, поэтому для обеспечения этого вам потребуется специальный метод, который они предлагают, который называется setJSONData(). Это в основном требует от вас указать dataSourceобъект в конфигурации диаграммы, указанной выше.
Джава
xxxxxxxxxx
1
FusionCharts.items['vote-chart'].setJSONData({
2
"chart": {},
3
"data": []
4
});
Вот и все!
Полезные ресурсы
- Репозиторий GitHub с полным исходным кодом
- Презентационные слайды
- Записанное видео мастеркласса
- Демонстрационная версия приложения интерфейса голосования
- Демонстрационная версия приложения с результатами голосования
- Ably Документы в реальном времени
- FusionCharts документы
Следующий будет про IoT, WebHooks, Zapier и другие супер забавные вещи. Вы можете найти всю информацию об этом на сайте.
Дальнейшее чтение
WebSockets против Long Polling
Приложения зависят от потоковой передачи данных в режиме реального времени, вот как ими управлять