rPman, websockets - это не http. Это совершенно другой протокол. Соединение только инициируется через http с заголовком Upgrade: websocket. И далее общение по http заменяется общением по websocket по тому же самому TCP/IP соединению.
А в SSE используется тот же http.
И хоть поддержка в браузере есть и у того и у другого, но обрабатывать SSE на клиенте всё равно значительно проще. В SSE можно подписываться на конкретные события. А у вебсокетов один общий хэндлер. Реконнект у SSE автоматический, а не ручной, как у websockets.
rPman, Вебсокеты сложнее вообще для всех. И для клиента и для сервера. А зачем? Просто чтобы получить сигнал о том, что данные изменились? Их надо выбирать, если вы пишете чат в реальном времени для кучи народу, игру или аналог Google Docs. Для большинства остальных случаев это чудовищный оверкилл.
SSE работает тупо на HTTP. EventSource API поддерживается напрямую браузером со всеми ретраями, реконнектами и стандартными сообщениями об ошибках. Нужен просто Javascript и ничего более.
Shurik, Погуглите, как правильно настраивать nginx location под вебсокеты. Там есть ряд особенностей, на которые стоит обратить внимание. В таком конкретном вопросе вам Гугл поможет больше меня
Shurik, Вот я попросил у ИИ накидать как объединить всё что вам нужно в докере. Не проверял ничего, глянул по-быстрому, вроде всё там норм. Но идея вам должна быть понятна.
Shurik, Не надо вам лезть в unix сокеты.
У вас несколько контейнеров на одном сервере. У каждого контейнера открыты свои специфические порты.
Nginx у вас должен работать в качестве reverse-proxy для ваших внутренних контейнеров с разными частями приложения.
Поэтому Nginx желательно вынести в отдельный контейнер. PHP-FPM - еще один контейнер. А вебсокеты - третий контейнер, которому в докере нужно будет назначить автоматический рестарт.
reverse-proxy в контейнере Nginx будет заниматься пробросом данных в тот или иной контейнер с теми или иными параметрами соединения в зависимости от урла.
Рекомендую все три конейнера объединить в docker-compose, который создаёт между контейнерами внутреннюю сеть, и тогда вам даже порты открывать не придётся, а слать запросы на хостнеймы, описанные в docker-compose.yaml
Shurik, Очень часто люди влезают в вебсокеты, даже не зная о существовании такой прекрасной технологии, как SSE (Server-Sent Events). Это вебсокеты "для бедных". Канал связи однонаправленный, с сервера в браузер. Работает через HTTP
Браузер подписывается на получение событий от SSE-сервера. PHP шлёт на SSE-сервер запрос о том, что событие возникло, и SSE-сервер уже рассылает это событие всем подписанным на него браузерам.
Таким образом: Если один человек изменяет список, то всем подписанным на это событие браузерам сообщается, что список изменился, и они могут получить новые данные обычным HTTP-запросом. Либо можно даже новые данные передавать в этом же событии.
Рекомендую освоить сначала этот подход. Вы поймёте, как работает эта схема асинхронного общения, отшлифуете её, а потом, если понадобится, вникнете уже в вебсокеты. Понимание самой сути асинхронной работы с сервером поможет вам потом и в некоторых аспектах эффективного использования весбокетов. Вы наработаете для себя паттерны этих процессов обмена данными.
Вот описание процесса для Symfony. Нужно будет дополнительно установить Mercure Hub. Это сервис, написанный на Go, который как раз занимается реализацией схемы publish/subscribe для SSE https://symfony.com/doc/current/mercure.html
У себя в PHP приложении вы будете отправлять сообщения через банальшейший Symfony messenger, а Mercure Hub автоматом разошлёт его всем клиентам
Shurik, Мне интересен один момент. А вам именно вебсокеты нужны? Какую задачу вы решаете.
Потому как если вам нужно только периодически отправлять какие-то сообщения с сервера на фронтенд, то есть гораздо более простое решение.
Shurik, Тогда вам желательно использовать именно Ratchet. Можете либо напрямую его имплементить у себя, либо нагуглить уже готовый бандл, который вам подойдёт.
Иван Родичев, Умеешь видеть чужой код на расстоянии даже в приватном репозитории? Зря теряешь тут время, тебе надо в ФСБ работать. Иначе такой уверенности ничем не объяснить. Помог бы уже тогда человеку вместо болтовни.
А вот я кода не видел... И ну вот не знаю я где и как там id генерируется, ничего не вижу кроме слов.
Илья, Я вам дам подсказку, которая очень сильно вам поможет, если вы будете где-то работать начинающим программистом в команде с очень опытным сеньором, которому в обязанности вменили вам помогать профессионально расти. Постарайтесь вникнуть в то, как другие люди думают.
Если у вас что-то не будет получаться, и вы просто с разбегу подойдёте к этому человеку с вопросом: "у меня тут не работает, помоги", то, в зависимости от характера человека либо от его настроения, вы можете получить очень разные вариации крайне токсичных и даже до слёз обидных ответов.
Почему так происходит? Потому что у человека куча своих дел, проект горит и т.д. и т.п., и кого он видит перед глазами? Очень ленивого человека, которому было влом сделать даже ряд простых действий перед обращением. И все эти действия теперь придётся делать ему самому, а вы будете у окна ворон считать.
Что должен сделать начинающий перед обращением к сеньору?
- Загуглить гугл до 125-й страницы выдачи, пока там уже порно не появится.
- Запромтить ChatGPT до тяжёлых галлюцинаций и отказа работать с вами.
- Затрейсить вашу программу до значений в регистрах процессора.
- Перепробовать 100500 раз переписать забагованный участок кода в разных парадигмах программирования на трёх разных языках программирования.
Я, конечно, преувеличиваю, но смысл вы, надеюсь поняли.
Скорей всего, после такого процесса вы сами найдёте баг. Но если даже не найдёте, то смело идите на консультацию.
И тогда вы не поверите! Если вы подойдёте к тому же самому человеку, находящемуся в том же самом настроении с такой кучей информации, то, скорей всего, он через несколько секунд сможет найти баг, а потом с улыбкой расскажет вам, что это за баг, почему он происходит, и как его избегать в будущем. И станет потом вас больше уважать.
Почему так происходит? Мы, люди, существа общественные. И что бы вам не вещали вокруг в духе "человек человеку волк", но нам очень нравится помогать другим людям, которые находятся в беде или затруднении. Даже безвозмездно. За одним редким исключением: когда человек этот ленивый халявщик. Не воспринимайте на свой счёт, просто именно в таком свете зачастую видят человека, который предоставляет крайне недостаточно информации для помощи ему же.
Илья, Это ничего не значит. Браузер может кэшировать preflight запросы.
Может быть, ваш бэкенд устанавливает в ответе хедер Access-Control-Max-Age. Там содержится время, в течение которого не будут повторно отправляться OPTIONS запросы для одного и того же запроса.
Михаил Ливач, Т.е. вы даже шаблонизаторами не пользуетесь, насколько я понимаю? Потому как у twig, например, точно такая же ситуация в IDE в плане подсветки.
Проблемы с шаблонами возникают у людей, пытающихся пихать в них тонны логики. И тогда в них действительно невозможно разобраться. В шаблоне должны использоваться только переменные, простейшие условия и простейшие циклы. Также шаблоны должны быть разбиты на небольшие блоки.
Я, вообще, считаю, что плохая репутация PHP в сообществе большей частью вызвана именно решением сделать PHP так же и шаблонизатором HTML. Да, это помогло очень быстро и просто клепать сайты, но это же и породило такие тонны го*нокода, что у людей, занимавшихся рефакторингом, случился пост-травматический синдром после работы с PHP. Когда я вижу, что React с их JSX наступает со всей силы на те же грабли, мне плохо становится. Потому что люди ничему не учатся...
Twig как раз и создавался с целью максимально усложнить создание хитрой логики в шаблонах. И это позволило сделать код чистым и простым. Но до сих пор убеждать людей, что PHP - неплохой язык программирования, крайне тяжело.
Vitsliputsli, Баги в программах появляются только потому, что мы люди. А чем больше всего программисту нужно держать в голове при написании программы, тем выше шансы внесения бага. Мы как LLM, можем держать в голове только определенное количество контекста. И если этот контекст переполняется, мы начинаем галлюцинировать багами в программе.
Задайте себе вопрос: зачем придумали Rust? Главная цель создания этого языка была в том, чтобы сделать работу с памятью безопасной. А почему это так сильно нужно было? Потому что программистам оказалось очень тяжело держать в голове информацию о том, где и когда они выделяли память, и где и когда надо её освобождать. Это чуть ли не главная проблема современности. Rust заставляет это делать при помощи своих механизмов, у человека теперь просто нет возможности внести такой баг.
Точно такая же логика касается языков с динамической типизацией. Человеку надо столько всего учитывать, что он просто иногда не справляется. Строгая типизация полностью исключает такие баги. Не зря потрачено столько времени и денег на создание Typescript. Этот язык чуть ли не стал стандартом в мире JavaScript на бэкенде.
PHP не пошёл таким радикальным путём, как Typescript, и я считаю это большой ошибкой. Совершенно понятно, что такое половинчатое решение было сделано ради совместимости. Но компромиссы редко приводят к чему-то толковому.
Совет на будущее: создавайте всегда для сайтов их собственные учётки.
Вот сейчас вы пытаетесь перепривязать капчу на свою учётку. А представьте, что наступят тяжёлые времена, и вам надо будет сайт продать. Это будет означать, что снова надо будет проводить работы на сайте.
Ваши личные учётки могут по разным причинам забанить, взломать и т.д.
Даже если вам удобно собирать email с сайта на свою личную почту, то лучше переадресовать все письма с ящика сайта на свой личный ящик, чем использовать свой аккаунт
В любой беседе всегда нужно сперва договориться о терминах. И если преподаватель бросается какими-то терминами, то их определение он либо объяснял ранее на занятиях, либо вы должны потребовать от него определение термина "утилита для автоматизированного проектирования".
Он должен перечислить вам критерии, по которым вы должны понимать, что перед вами именно эта хрень, а не что-то другое.
Например, я могу любую ORM, поддерживающую миграции, назвать такой утилитой. Ведь там ты описываешь классы, которые можно назвать проектом, а оно тебе автоматически создаёт нужные миграции для создания базы.
А в SSE используется тот же http.
И хоть поддержка в браузере есть и у того и у другого, но обрабатывать SSE на клиенте всё равно значительно проще. В SSE можно подписываться на конкретные события. А у вебсокетов один общий хэндлер. Реконнект у SSE автоматический, а не ручной, как у websockets.