GrimJack: Я так понимаю схема следующая:
1) Стартуем сокет на ратчете
2) Сокет слушает аэроспайк, редиску, бенсталк и проч. (далее 3rd-service)
3) Консольная команда стратует очередь
4) Таск пушит в 3rd-service сообщеньку
5) Сокет подхватывает и пушит в браузер
avtorlego: самым грамотным решением было бы, имхо, создание файлика (или лучше его touch), к примеру ".restart" средставми пыха\питонки\перла\чего_угодно, а другой процесс, который запущен от рута, как-нибудь так:
мониторит его и рестартует сервак. Таким образом можно отделить сервисный рутовый слой (т.е. скрипт, который имеет доступ ко всему, но может выполнять только одно действие) от относительно изолированной пользовательской среды (все, кому надо рестартануть сервак - просто меняют файл). Да и руками можно будет рестартовать сервак или ещё что, выполняя `touch .restart` из под какого-нибудь ssh.
С другой стороны - не понятна предметная область, на кой фиг это всё надо делать.
Максим Тимофеев: никто не спорит. У битрикса тоже своя ниша и он крут для своих задач. Только, например, сравнивать Symfony vs Битрикс мало кто будет. А данное видео примерно с таким же сравнением. Да ещё и с итогом, что: "это примерно одно и то же".
Максим Тимофеев: с точки зрения чего угодно. Расскажите почему, например, битрикс - это плохо. Он же выполняет свои задачи и зачастую делает это лучше того же Yii.
Если судить именно по критерию адекватности сырков (это же всё же фрейм, а не CMS), то в Laravel нет таких фатальных проблем, как в Yii. Все зависимости делегированы через интерфейсы (даже в симфони зачастую грешат сервис-локацией для этого, хотя не в исходниках фрейма, конечно, в standard edition том же). Классы отвечают принципам SRP и своей доменной, если так можно говорить, области. Не идеально, конечно, но этим все грешат, как симфони, так и зенд.
Т.е. если подытожить мою мысль, то я хочу сказать, что сравнивать Yii vs Laravel имеет смысл на начальных этапах разработки или простых проектах. Если на перспективу, то уже скорее Symfony vs Laravel, Yii не настолько гибок, это скорее "коробочное решение".
Максим Тимофеев: это не эквивалентные фреймы. У них пересекается ЦА, тут только идиот будет обратное доказывать, да. Но качество исходников и возможности несопоставимы. Yii - это откровенный говнокод, невероятно круто выполняющий свои задачи одним движением руки. Laravel, начиная с 5ой версии (это важно) - имеет довольно качественный уровень исходников, что позволяет подстраивать его для задач любого уровня и местами уделывает в хлам и Symfony. Т.е. это скорее фрейм для перспективы развития, нежели для "быстрого страта", как Yii.
Так что автор видео - имеет откровенно мало опыта и просто решил "хайпануть на волне" без объективного опыта, иначе бы так не выражался.
Максим Тимофеев: Скрытые зависимости, синглтоны, eval'ы и прочие "радости жизни". Т.е. о Yii можно говорить как о крайне плохой вещи с точки зрения, как качества исходников, так и возможностей.
Я не буду углубляться, просто поверхностно пробегусь и в качестве примера приведу, мой любимый объект реквеста (https://github.com/yiisoft/yii2/blob/master/framew... Мы наблюдаем:
1) Код http-реквеста
2) Который зависит от контейнера
3) Который зависит от секьюрити
4) Секуьрити, который заранее определён, не как элемент DI, а получаемый через метод-геттер
5) Который, в свою очередь зависит от валидатора
6) Который, внезапно, валидирует кукисы изнутри реквеста!
7) Который зависит от i18n
8) и так далее
Причём, прошу заметить, никакого делегирования. Высокосвязный компонент, который невозможно тестировать и невозможно использовать отдельно, от HTTP окружения и браузера, который содержит кучу скрытых зависимостей, требующих использования всего стека "фрейма", что, скорее ближе к подходам современных CMS, нежели к фреймам.
Это очень плохие исходники и рассматривать такое поделие, как профессиональную работу крайне проблематично. Но всё это не значит, что Yii не выполняет свою работу, более чем выполняет, тот же самый Gii из коробки даст фору любой CMS. Только надо учитывать, что Yii не способен на грамотно масштабируемые, крупные и качественные решения без соплей и костылей.
Как раз надо для реализации stateless имплементации. В данном случае делегирование - это более чем грамотное решение. Всё правильно реализовано.
Единственная ошибка - аффект сессии (т.е. непосредственно передача оной по ссылке), вместо реализации отдельной сущности, которая будет обрабатывать сессии. Ну т.е. в некотором роде нарушение SRP.
SZV: никак. Указанный заголовок говорит о том, что документ не является html файлом, а является тестовым (т.е. надо его выводить как есть, включая переносы строк).
Так что верно сказали выше - надо идти учить html.
Виталий: есть точно такое же 100% рабочее решение: php + ratchet + jwt. Работает нынче на проде и жрёт на несколько порядков меньше ноды (16 метров против 60). gg wp
А учитывая то, что основное ПО написано на php, тем более на Laravel - кусок кода будет переиспользованный.
Виталий: на асме это будет невероятно долго и неудобно. А на пыхе быстро и эффективнее, нежели на JS (благо на дворе 2017ый, инструменты есть, а экосистема у пыха на порядок качественнее и мощнее, нежели чем у npm).
1) Черезжопная интерполция
2) Платформозависимый EOL
Сами ищите что из этого.