Транспортировка API сообщений посредством socket.io в мобильных приложениях: хорошо или плохо?
Собственно, мучаюсь вопросом, как лучше реализовать API:
1) Сделать все (api + отправление данных/евентов/etc с сервера на клиент) посредством socket.io
2) Сделать api отдельно, обычным REST / JSONRPC + опционально, на десктопах запускать и socket.io, для подгрузки данных в реальном времени
С одной стороны, socket.io позволяет пушить с сервера данные на клиент в реальном времени и имеет кучу фэллбеков. С другой стороны - если я еду в метро / использую медленный GPRS - не будет ли socket.io большим оверхедом?
@begemot_sun необходимо показывать местонахождение gps навигаторов, в приложении показываю текущее местонахождение и прошлые точки. socket.io нужен для подгрузки новых координат в реальном времени.
В таком случае выбор верен. Вы конечно можете использовать HTTP. Но в данном случае от него большой оверхед, т.к. соединение каждый раз сбрасывается.
То, что где-то у кого-то в метро рвется связь, так это проблемы этого чела, да и порвется связь -- сразу восстановится когда надо.
Согласно этой статистике: caniuse.com/websockets поддержка веб-сокетов вроде есть во всех современных браузерах, т.е. в теории на современных девайсах должны использоваться только веб-сокеты.
Меня смущает возможность использования GPRS: как будут веб-сокеты чувствовать себя работая в таких условиях? Допустим, еду я с ноутбуком где-нибудь за городом.
HTTP запрос - ушел / пришел, в одном запросе в теории можно отправить и получить сразу несколько API запросов.
А socket.io пытается висеть, постоянно делая реконнекты, на что тратится интернет и что может вылиться в копеечку.
Ваш сокет.ио это обычный сокет, который также устанавливается при HTTP-cоединении, и также обрывается при HTTP-соединении. Только сокет.ио не обрывается.
Ну оборвется, востановится. Трафика будет меньше, поверьте ;)
Средний
