1. Скажите, чем лучше Viber в плане Push? Он ведь так же получает сообщения через Push (когда приложение в бэкграунде), или я ошибаюсь? Разве там есть API именно для авторизации, кодов, TTL запроса авторизации или сообщения?
2. Надёжность сертификатов обеспечивают APN, GCM, если Вы о Push.
3. А почему «без firebase» cloud messaging?
Спасибо за вопросы, наоборот задавайте, нам так же важно и Ваше мнение.
1. На данный момент проблем с использованием NodeJS — нет, это очень маленькая часть кода и функционала которая отвечает только за веб-уведомления. Поэтому затрат на дополнительные силы разработки nodejs — нет. На данный момент это не критический функционал системы, поэтому мы его не так сильно развиваем.
Если сравнивать прошлую версию 2.95 — там было его больше, например активности комментариев на странице заявок (автодобавление новых комментариев по тем же nodejs/socket.io push-событиям).
2. СтОит понимать, что для очереди сообщений мы используем БД (планируем либо REDIS, либо BeanstalkD). Для рассылки всплывающих уведомлений используем REDIS+NodeJS/Socket.IO.
Сама тема рассылки уведомлений и обработка их статусов для нас так же является важной. Мы например используем функционал уведомлений о последних событиях, но он отражается в БД, в качестве логов. Теперь будем смотреть в сторону rabbitMQ.
Мы это реализовали с помощью REDIS+NodeJS/Socket.IO для веб-нотификации. Нам не важны были оффлайн нотификации, они итак отражены в логах в связи со структурой проекта.
Мы хотим использовать beanstalkd для очередей, я не могу сказать поддерживает ли он весь тот функционал, как тот же Rabbit-MQ, но идея отличная.
У нас не используется пока клиент под Android, но мы планируем его использование. Даже при этом, так как у нас единый сервер отправки PUSH-уведомлений, проблем с отправкой параллельно на Android-устройства не возникнет.
Мы используем https://github.com/davibennun/laravel-push-notification на нашем PUSH-сервере, а с него уже возможна отправка и на Apple Push, и на Android Push серверы.
Для синхронизации мы решили использовать именно API/json-обмен данными по запросу мобильного клиента. Не совсем понятно, каким образом можно использовать тот же Rabbit-MQ для синхронизации?
Мне очень жаль, что среди порядочных Хабра-Пользователей находятся те, которые пишут матерные выражения в названиях групп и пишут политические тексты. Мы вынуждены закрыть демо. Если у кого-то есть прямое желание ознакомиться с новой версией — пишите на почту и мы любезно предоставим доступ.
Payoneer — отличный сервис. Рекомендую, кроме того, очень радует тех. поддержка:
Русская тех поддержка
RealTime-chat
Быстрое решение всех вопросов в том числе и касающихся безопастности
Честно сказать, доволен очень сервисом.
НО, хотелось бы всё-таки иметь возможность подключать оплату через сайт, или хотя бы API, для автоматизации выставления счёта.
Я Вам скажу, как владелец IT-интернет магазина по продаже бубнов (http://habrahabr.ru/post/226361/), что использую такую библиотеку.
К примеру, когда клиент оформляет заказ на сайте и указывает адрес доставки склада Новой Почты, данная библиотека вытягивает актуальный список населённых пунктов, и уже по ним список отделений в этих населённых пунктах. Ввиду нестабильной географической (политической) ситуации в Украине, есть место поддерживать актуальный список населённых пунктов в которые осуществляется доставка.
Одна серйозная проблема — это время отклика работы самого сервера API. Порою бывают такие задержки, когда много клиентов хотят получить запрос отделений разных городов, что мне кажется что сам API включает какую-то защиту от DDOS, либо имеет ограничение на к-во запросов в период времени. Так что пока боремся путём кеширования (ввиде локального хранения списка отделений/городов и обновления через API).
Нет, всё ясно, спасибо за ответы.
Но разве WS поддерживает longpolling?
Насколько мне известно socket.io поддерживает всё, а вот WS, только websocket?
поправьте если ошибаюсь.
Спасибо за ответы :)
Хотелось бы больше деталей увидеть. Например,
— почему ws, а не socket.io?
— почему всё-таки ушли от pm2?
— c чем именно связано равное к-во использования клиентами long polling & websocket?
К сожалению, пока нет.
Мы за эту недели реализовали две важные функции, которые слышали так часто в запросах наших клиентов.
Это: поддержка крайнего срока выполнения заявки и приём заявок через e-mail.
В понедельник планируем выпустить релиз + обновление.
2. Надёжность сертификатов обеспечивают APN, GCM, если Вы о Push.
3. А почему «без firebase» cloud messaging?
PS. Спасибо за замечания.
1. На данный момент проблем с использованием NodeJS — нет, это очень маленькая часть кода и функционала которая отвечает только за веб-уведомления. Поэтому затрат на дополнительные силы разработки nodejs — нет. На данный момент это не критический функционал системы, поэтому мы его не так сильно развиваем.
Если сравнивать прошлую версию 2.95 — там было его больше, например активности комментариев на странице заявок (автодобавление новых комментариев по тем же nodejs/socket.io push-событиям).
2. СтОит понимать, что для очереди сообщений мы используем БД (планируем либо REDIS, либо BeanstalkD). Для рассылки всплывающих уведомлений используем REDIS+NodeJS/Socket.IO.
Сама тема рассылки уведомлений и обработка их статусов для нас так же является важной. Мы например используем функционал уведомлений о последних событиях, но он отражается в БД, в качестве логов. Теперь будем смотреть в сторону rabbitMQ.
Мы хотим использовать beanstalkd для очередей, я не могу сказать поддерживает ли он весь тот функционал, как тот же Rabbit-MQ, но идея отличная.
Мы используем https://github.com/davibennun/laravel-push-notification на нашем PUSH-сервере, а с него уже возможна отправка и на Apple Push, и на Android Push серверы.
Для синхронизации мы решили использовать именно API/json-обмен данными по запросу мобильного клиента. Не совсем понятно, каким образом можно использовать тот же Rabbit-MQ для синхронизации?
https://demo2.zenlix.com/
Login: admin@local
Password: p@ssw0rd
Честно сказать, доволен очень сервисом.
НО, хотелось бы всё-таки иметь возможность подключать оплату через сайт, или хотя бы API, для автоматизации выставления счёта.
К примеру, когда клиент оформляет заказ на сайте и указывает адрес доставки склада Новой Почты, данная библиотека вытягивает актуальный список населённых пунктов, и уже по ним список отделений в этих населённых пунктах. Ввиду нестабильной географической (политической) ситуации в Украине, есть место поддерживать актуальный список населённых пунктов в которые осуществляется доставка.
Одна серйозная проблема — это время отклика работы самого сервера API. Порою бывают такие задержки, когда много клиентов хотят получить запрос отделений разных городов, что мне кажется что сам API включает какую-то защиту от DDOS, либо имеет ограничение на к-во запросов в период времени. Так что пока боремся путём кеширования (ввиде локального хранения списка отделений/городов и обновления через API).
Но разве WS поддерживает longpolling?
Насколько мне известно socket.io поддерживает всё, а вот WS, только websocket?
поправьте если ошибаюсь.
Спасибо за ответы :)
— почему ws, а не socket.io?
— почему всё-таки ушли от pm2?
— c чем именно связано равное к-во использования клиентами long polling & websocket?
Мы за эту недели реализовали две важные функции, которые слышали так часто в запросах наших клиентов.
Это: поддержка крайнего срока выполнения заявки и приём заявок через e-mail.
В понедельник планируем выпустить релиз + обновление.
В ближайшее время будет релиз.