Комментарии 20
В целом неплохо, но хотелось бы больше конкретики. Я был на 100% уверен, что в конце будет реализация. И был довольно сильно разочарован. В частности, становится непонятно, к чему здесь вообще притянуты хабы Симфони и Доктрина. Ну хоть кусочек кода и оттуда и оттуда можно было привести, хотя бы для приличия?
поставил плюс статье и карме, потому что очень нравится идея, мне нравится PHP и я поддерживаю любые начинания каждого в этом направлении, но, соглашусь, мало конкретики, давайте примеры хотя бы с гитхаба или тут ссылочки скиньте, плес)
если вы уже пробовали поднимать веб-сокет скиньте, если не сложно, пет-проект ну или то что получилось и реально работает, какие реальные минусы и сложности были у вас, с чем смогли справиться, с чем нет. Лично мне интересен ваш путь, ваш опыт и как вы справлялись с трудностями, я бы посмотрел с удовольствием как это работает, развернул бы, глянул как устроена ваша архитектура и тд (ну если это не суперсекретное и вам не жалко)
--- Поскольку сервер веб-сокетов - это отдельное от основного бэкенда приложение, он ничего не знает о существующей базе данных.
одно это говорито том, что предстоит пройти велосипедостроение. php - обработчик запросом от клиента, но не ws . оно конечно похвально, что php стремится расширить своё применение, но увы .... это не серверные приложения, и всю прелесть ws просто теряют....
---PHP все еще может быть не первым вариантом для работы с веб-сокетами
это хорошо, что автор признался...
одно это говорит о том, что предстоит пройти велосипедостроение. php — обработчик запросом от клиента, но не ws
Если честно, то не вижу здесь логики. Да — отдельное, да — не знает. Но при чем тут велосипедостроение-то? Что имеется в виду под велосипедом? Использование РНР в качестве демона? Это давно уже не велосипед, а сложившаяся практика. О чем говорит, в частности, наличие описываемой в данной заметке библиотеки.
PHP - едва ли первое, что придет в голову, когда стоит задача поднять сервер веб-сокетов.
Но поскольку PHP - это однозначно первое, что приходит в голову, когда речь идет о веб-приложениях
Откуда столько пафоса? Почему так однозначно? У меня например уже года 3 как пхп в голову не приходит, судя по вакансиям компаний чуть больших чем "рога и копыта" тоже. В статье это никак не объясняется.
php рано списывать, на нем буквально пол интернета работает. Если 7я версия освежила язык, то 8я с добавлением нормального JIT гарантировала ему место в ТОПе ещё много лет.
Никогда не понимал хейта php, если дело в говнокоде - посмотрите на Кресты. Там его больше и само по себе понятие зарождалось благодаря гибкости именно этого языка. Но это не делает язык плохим.
Согласен. Я изучаю JS и у меня всегда в голову на тему бэкенда приходит только JS, ну или Python, Go, Java или C#. А про PHP я уже давно забыл, потому что ассоциируется он у меня с чем-то медленным и непрофессиональным.
Вы лучше лечитесь, не забывайте)
Мне кажется, это немного грубовато. Нападать на человека просто за то что он высказал свое мнение — это как-то не очень.
Тем более что мнение совершенно оправданное. Каждый человек живет в своем информационном пузыре. И вполне логично предположить, что есть немало таких пузырей, в который РНР вообще отсутствует. Это нормально.
С одной стороны вы правы и я согласен с вами. Но с другой, мне кажется мы стали слишком толерантными к подобным персонам, которые позволяют открыто высказывать критику в отношении той или иной сферы, основываясь сугубо на своем личном опыте. Тем самым он косвенно оскорбляет всех тех людей, которые выбрали PHP в качестве своего основного инструмента. Я думаю в таких ситуациях, с подобными личностями, нужно быть менее толерантным и ставить их на место. В любом случае это мое личное мнение
Вопрос не в толерантности, а в конечном эффекте.
Для начала надо понять, что в интернете вы никого никуда не поставите. По определению. Срач устроить — это да. А поставить на место человека, на которого у вас нет никаких рычагов воздействия — это, извините фантазии.
Кроме того, надо определиться, что вы на самом деле хотите. Потому что ставить на место и хамить — это совершенно разные вещи. Если будете хамить, то добьетесь эффекта, противоположного ожидаемому. Никто ни на какое место уж точно не встанет.
Тем самым он косвенно оскорбляет всех тех людей
Оскорбляться за других людей тоже следует с осторожностью. Все мы видели, к каким последствиям это приводит.
PHP - едва ли первое, что придет в голову, когда стоит задача поднять сервер веб-сокетов.
Я тоже так думал пару лет назад. Но когда количество подключении возросло до 4-5к пожалел. Успешно перешли на NodeJS с использованием пакета WS. Бэкэнд (Rest API) остался на PHP, и через RabbitMQ шлются мессаджи на websoket. Пока полет нормальный. А главное сообщения аккумулируются в очередях, и после перезагрузки или падения websoket сервиса не исчезают.
Не проще реализовать все через centrifugo. Она написан на go и умеет держать много ws подключений.
А из пхп отправлять события/сообщения через gRPC в centrifugo.
Не думали над таким решением?
На проекте смотрели и на ратчет и на свуле, свуле по-лучше как мне кажется. Но в итоге нам не подошла ни одна из них. Сейчас используем ASP.NET + SignalR
Для всего есть свои инструменты и php как по мне не очень подходит для написания веб сокет сервера, например если вырасте нагиузка, то нужно будет думать над масштабированием системы. При этом есть коробочные решения, например centrifugo, при этом это не единственное решение, которое работает в связке с пхп
На одном проекте видел фитчу - сокеты триггерят фронт, а он уже по апихе тащит данные обновленные себе) без заморочек, если сокеты нужны в паре мест
Если говорить про Symfony, то у них есть официальная интеграция с mercure в виде отдельного бандла.
Писать собственные веб-сокет серверы крайне не рекомендую. Особенно на пхп. Особенно с нуля.
P.S. Это конечно не полноценный WS, но покрывает множество случаев, когда требуется реалтайм с PHP бекендом.
Работа с Веб-сокетами на PHP