Add websocket support for swoole

[deanmcpherson]

Seeing as Swoole supports websockets out of the box, it would be cool to have this as a configurable option.

I had a quick play and simply changing Swoole\Http\Server to Swoole\Websocket\Server in bin/createSwooleServer.php appears to mostly work - I also had to define at least a single on("message") handler as well in bin/swoole-server before the server is started.

The only roadblock I can think of is that I imagine @taylorotwell you may prefer it if websockets were tied in with native laravel auth/ event stuff? Currently it would be only raw socket messaging.

[forestlovewood]

In case anyone wants any reference, I've begun implementing this functionality in a fork forestlovewood/octane – I'm aiming to achieve integration with Broadcasting/Notifications, utilising native authentication and event handling.

[Namoshek]

@forestlovewood Are you also thinking about implementing a backplane (like Redis) to support replication and HA-scenarios?

[forestlovewood]

@forestlovewood Are you also thinking about implementing a backplane (like Redis) to support replication and HA-scenarios?

That should be reasonably straightforward, I was going to use Swoole Tables but I should be able to use Redis as well with little modification. I've actually never used replicated WebSocket servers, though, so I don't know if there's any gotchas.

[barryvdh]

Maybe easier to use https://github.com/beyondcode/laravel-websockets as base? Not sure how hard it would be to create an alternative server for it, besides React? (cc @mpociot)

[forestlovewood]

Maybe easier to use https://github.com/beyondcode/laravel-websockets as base? Not sure how hard it would be to create an alternative server for it, besides React? (cc @mpociot)

Agreed, at this point I'm just implementing the basic functionality and event handling in Octane, so it might make sense to also fork Laravel WebSockets and see if I could add Octane integration.

[mpociot]

I actually started working on an Octane compatible version of Laravel WebSockets myself 😅 My idea is to make this work as a package though, so that it can be included into Octane without too many modifications on Octane itself (mostly to keep the maintenance burden on Octane low). This would also allow users to switch between multiple WebSocket server implementations if required.

[barryvdh]

Cool :) Yeah that's what I meant. No real reason for it to be in Octane, more likely to be in Laravel Websockets where you can start it with php artisan websockets:serve --server=swoole if you have that already for extra speed :)

[Namoshek]

Cool :) Yeah that's what I meant. No real reason for it to be in Octane, more likely to be in Laravel Websockets where you can start it with php artisan websockets:serve --server=swoole if you have that already for extra speed :)

Well, the question is if two processes are really required. Especially in a containerized environment, a single process would be a lot easier to setup and maintain. Two processes means you'd need an extra (public) port or a reverse proxy to split HTTP from WS traffic. Whether it makes sense to put both into a single process and container depends heavily on the exact use case though. High-traffic sites may have an argument to split these use cases for independent scalability.

I support the idea of a separate package (even if that makes the upgrade harder), but I would prefer a plug-in solution where Octane runs the package implementation.

[forestlovewood]

I like the idea of both options – perhaps having some basic functionality built into Octane, but also having the ability to have a distinct server running just for Laravel Websockets? I still like the idea of a simple Broadcasting driver built into Octane, though, along with a Queue driver and a Scheduler driver. It'd be nice to be able to use it nearly self-contained like that.

My idea is to make this work as a package though, so that it can be included into Octane without too many modifications on Octane itself (mostly to keep the maintenance burden on Octane low).

Yeah, that's the changes I've made so far in my fork, working on integrating the raw events with Octane in a way that could likely be hooked into fairly easily by a package like Laravel Websockets.

[taylorotwell]

Since a few people are working on this as a package I will close this for now - I would be very interested in checking out any packages that support it!

[goodevilgenius]

@taylorotwell It might make more sense for it to be in Octane itself.

This is because Swoole\WebSocket\Server extends Swoole\Http\Server, and, as I understand it, the correct way to do this is to instantiate only the Websocket Server, and use that for both WebSockets and traditional HTTP.

This seems to be the approach that @forestlovewood was using in his fork, although I'm not sure if he's actively working on it.

If this were implemented as an external package, it wouldn't be able to run both traditional HTTP and WebSockets on the same connection (over the same port). This would decrease the usefulness, and might make it more difficult to implement on some cloud providers.

One approach might be to make it possible to customize in the configuration which Swoole server class to use, and then it would be simpler to implement as a third-party plugin. This would still require some changes to Octane itself, though.

Would you be open to a PR to that effect?

[goodevilgenius]

It might even make sense for the Swoole\Http\Server itself to be instantiated in a service provider, so that that provider could simply be overriden by another package which would instantiate a Swoole\WebSocket\Server, and register the necessary callbacks.

[kingIZZZY]

+1 🙏 need WebSockets in octane @forestlovewood any hope?

[kingIZZZY2]

My solution so far (from a 2nd github account) based on @forestlovewood's initial work: Commit: https://github.com/kingIZZZY2/octane/commit/33c90bb178552e70f8f49aa58c0c62f677b2fe0b Branch: kingIZZZY2 / octane / forestlovewood-websockets

No guarantees that I will keep maintaining this fork/branch. You're welcome to clone/fork/maintain your own.

You'll need to tweak your composer.json to use the forked repo & branch instead of the laravel/octane source. Mine has something like;

...
"require": {
    ...
    "laravel/octane": "dev-forestlovewood-websockets",
    ...
},
...
"repositories": {
    "0": {
        "url": "https://github.com/kingIZZZY2/octane",
        "type": "vcs"
    },
    ...
}
...

Don't forget to composer update

[Forsakenrox]

We are in dire need of a bi-directional websocket solution to build amazing applications. Some solutions exist, such as laravel-swoole and laravel-s, but they have terrible support and outdated or missing documentation. We must to move things around somehow

[kingIZZZY]

I switched from Laravel to Hyperf I might be wrong but I see Hyperf as basically Laravel re-created in Swoole technology Best of all worlds I wish Laravel project would go all-in with Swoole like that

Until then, it's Hyperf for me