Комментарии 20
Визуально — это очередная поверхностно подтюнингованная AdminLTE
На главном скриншоте опечатка «груп». Еще одну П потеряли.
Тоже не работает. Вы хоть проверяйте что-ли. И надо отключать дебаг режим)
in Collection.php line 1045
at HandleExceptions->handleError('8', 'Undefined offset: 0', Collection.php line 1045
at Collection->offsetGet('0') in DashboardController.php line 123
Так совпало, что вы выкатили релиз первой версии в то время, как у нас на работе было решено внедрить хелпдеск. Большинство функционала пересекалось, поэтому было решено взять вашу версию за основу, но в итоге большая часть была переписана и добавлен новый функционал. Была добавлена авторизация по лдап + привязка еще к одной внутренней БД. Также полностью перерисовал интерфейс.
Сейчас подумываю также переписать все с использованием какого-нибудь фреймворка =)
А почему использовали Apple PUSH-server? Или у Вас не планируется клиент под Android? Почему для синхронизации с мобильной версией не использовали, например, Rabbit-MQ, или AWS DynamoDB / Google Firebase? Я почему интересуюсь оффлайн-синхронизацией, потому что столкнулся с подобным вопросом в своем проекте.
У нас не используется пока клиент под Android, но мы планируем его использование. Даже при этом, так как у нас единый сервер отправки PUSH-уведомлений, проблем с отправкой параллельно на Android-устройства не возникнет.
Мы используем https://github.com/davibennun/laravel-push-notification на нашем PUSH-сервере, а с него уже возможна отправка и на Apple Push, и на Android Push серверы.
Для синхронизации мы решили использовать именно API/json-обмен данными по запросу мобильного клиента. Не совсем понятно, каким образом можно использовать тот же Rabbit-MQ для синхронизации?
Мы используем https://github.com/davibennun/laravel-push-notification на нашем PUSH-сервере, а с него уже возможна отправка и на Apple Push, и на Android Push серверы.
Для синхронизации мы решили использовать именно API/json-обмен данными по запросу мобильного клиента. Не совсем понятно, каким образом можно использовать тот же Rabbit-MQ для синхронизации?
С помощью очередей и «потребителей». При добавлении/изменении/удалении объекта в очередь отправляется сообщение либо с ID объекта, либо объект целиком. Всё в json-формате. Удобно в том плане, что сообщение не пропадает, а лежит в очереди, пока его не прочитают веб/мобильные клиенты.
Мы это реализовали с помощью REDIS+NodeJS/Socket.IO для веб-нотификации. Нам не важны были оффлайн нотификации, они итак отражены в логах в связи со структурой проекта.
Мы хотим использовать beanstalkd для очередей, я не могу сказать поддерживает ли он весь тот функционал, как тот же Rabbit-MQ, но идея отличная.
Мы хотим использовать beanstalkd для очередей, я не могу сказать поддерживает ли он весь тот функционал, как тот же Rabbit-MQ, но идея отличная.
Не страшно было делать проект с высокой нагрузкой на PHP-фреймворке? Если уже используете Node.js, почему не сделали весь Backend на нем (express.js, sequelize.js...)? Я сейчас делаю один проект на Laravel 5.1, но интересует Ваше мнение относительно выбранной технологии не только потому, что у Вас уже есть PHP разработчики. Была ли еще какая то причина?
Извините, если много вопросов задаю. Ищу полезные аргументы.
Извините, если много вопросов задаю. Ищу полезные аргументы.
Спасибо за вопросы, наоборот задавайте, нам так же важно и Ваше мнение.
1. На данный момент проблем с использованием NodeJS — нет, это очень маленькая часть кода и функционала которая отвечает только за веб-уведомления. Поэтому затрат на дополнительные силы разработки nodejs — нет. На данный момент это не критический функционал системы, поэтому мы его не так сильно развиваем.
Если сравнивать прошлую версию 2.95 — там было его больше, например активности комментариев на странице заявок (автодобавление новых комментариев по тем же nodejs/socket.io push-событиям).
2. СтОит понимать, что для очереди сообщений мы используем БД (планируем либо REDIS, либо BeanstalkD). Для рассылки всплывающих уведомлений используем REDIS+NodeJS/Socket.IO.
Сама тема рассылки уведомлений и обработка их статусов для нас так же является важной. Мы например используем функционал уведомлений о последних событиях, но он отражается в БД, в качестве логов. Теперь будем смотреть в сторону rabbitMQ.
1. На данный момент проблем с использованием NodeJS — нет, это очень маленькая часть кода и функционала которая отвечает только за веб-уведомления. Поэтому затрат на дополнительные силы разработки nodejs — нет. На данный момент это не критический функционал системы, поэтому мы его не так сильно развиваем.
Если сравнивать прошлую версию 2.95 — там было его больше, например активности комментариев на странице заявок (автодобавление новых комментариев по тем же nodejs/socket.io push-событиям).
2. СтОит понимать, что для очереди сообщений мы используем БД (планируем либо REDIS, либо BeanstalkD). Для рассылки всплывающих уведомлений используем REDIS+NodeJS/Socket.IO.
Сама тема рассылки уведомлений и обработка их статусов для нас так же является важной. Мы например используем функционал уведомлений о последних событиях, но он отражается в БД, в качестве логов. Теперь будем смотреть в сторону rabbitMQ.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы написали helpdesk (часть 3)