Зачем нам нужны такие продукты, как Pusher и Socket.io, для установления соединения через веб-сокет?

Это не нужно.

Эти части программного обеспечения просто упрощают работу с протоколом Websocket.

Помните, Laravel - это самоуверенный фреймворк. Это означает, что он будет выбирать свои собственные библиотеки, чтобы абстрагироваться от таких концепций для вас, чтобы вам не приходилось так сильно беспокоиться о том, что происходит под капотом.

По сути, для работы с Websockets вам понадобятся два компонента:

1. Сервер Websocket
2. Клиент Websocket

Причина, по которой Laravel не взаимодействует напрямую с интерфейсом через Websockets, заключается в том, что сам Laravel не является сервером Websocket. По крайней мере, не совсем. И хотя в PHP есть поддержка для работы с протоколом Websocket - и даже некоторыми библиотеками для более удобного использования - он просто не используется для обработки долгоживущих процессов так часто, как другие языки.

Вместо этого Laravel использует функциональность Pub / Sub, которую Redis предоставляет для прослушивания событий, происходящих через Redis и библиотека Predis. Причина, по которой он это делает, заключается в том, что Laravel лучше подходит в качестве посредника для сервера веб-сокетов и всех подключенных клиентов.

Таким образом, Laravel может передавать информацию на сервер Websocket, используя широковещательные события. as получать информацию о событиях от сервера Websocket и определять, есть ли у пользователей возможность или разрешение на их получение.

Если вы не хотите использовать Pusher, существует библиотека, которая позволит вам запускать собственный Websocket Server специально для Laravel под названием Laravel Echo Server.

Под капотом эта библиотека по-прежнему использует Socket.io и Redis, чтобы все движущиеся части могли беспрепятственно взаимодействовать друг с другом в веб-приложении Laravel. Преимущество здесь в том, что вам не нужно беспокоиться о количестве сообщений, отправляемых сервером.

Обратной стороной является то, что теперь вы должны знать, как управлять и поддерживать этот процесс на своем сервере, чтобы сервер Websocket знал, что он должен включаться каждый раз, когда вы перезагружаете свой сервер, или если произойдет сбой и т. Д.

Ознакомьтесь с PM2, чтобы узнать больше о запуске и обслуживании серверных демонов.

Если вы не согласны с мнением Laravel о том, как обрабатывать веб-сокеты, то теоретически вы можете использовать любой другой серверный язык для обработки протокола веб-сокетов. Просто потребуется более глубокое практическое знание самого протокола; и если Laravel нужно с этим работать, вам нужно знать, как написать соответствующие классы Service и Provider, чтобы иметь возможность справиться с этим.

Короткий ответ? Вам не обязательно их использовать. Выберитесь, написав собственную реализацию веб-сокета на стороне клиента и на стороне клиента.

Более длинный ответ.

Зачем использовать Laravel? Я могу сделать все это с помощью PHP.

Зачем использовать Vue? Я могу сделать все это с помощью ванильного javascript.

Мы используем библиотеки и фреймворки, потому что они абстрагируются от деталей реализации и упрощают создание продуктов. Они обрабатывают крайние случаи, о которых вы не думаете, или вещи, которых вы даже не знаете, о которых вы не знаете, потому что они используются тысячами или миллионами разработчиков и всеми знаниями и ошибками, которые у них есть. обнаруженные и исправленные ошибки встроены в реализацию.

Это одна из отличительных черт разработки программного обеспечения, повторное использование кода. Не повторяйтесь и не пишите ненужное программное обеспечение. Это позволяет вам сосредоточиться на создании решения для ваших конкретных требований, а не на создании большого количества инфраструктуры, прежде чем вы даже сможете создать свое решение.

Я никогда не использовал Pusher, но похоже, да, это продукт SaaS. Но Socket.io имеет открытый исходный код.