[2.x] Major refactoring

[rennokki]

Rewritten from scratch

The project got re-written from scratch as stated the reasons in #519

The contributors are going to remain the same, including @francislavoie with the awesome starting point to horizontally-scale the running servers.

Rewrite changelog

• The migration file suffered a small modification. Run vendor:publish to get the second migration file that changes the fields to plural.
• The configuration file got itself re-written as well with simplicity in mind (the initial 2.x was still a mess). Get a new copy of it.
• Interfaces moved to Beyondcode\LaravelWebSockets\Contracts\*. If you extend certain functionalities, makes sure to use the right namespaced interfaces.
• The replication driver is now called replication mode. Env's WEBSOCKETS_REPLICATION_MODE variable now can be set to local or redis.
• Replicators got merged into Channel Managers. If you added your own custom replicator, you now should implement the BeyondCode\LaravelWebSockets\Contracts\ChannelManager interface.
• Statistics Loggers are now called Statistics Collectors. Their job is to temporarily store the data between dumps into the database (by default).
• Handlers for the WebSocket, as well as the HTTP API Server, got re-written. They are still found in the config, but make sure to check them if you extend one of them.
• The vast majority functions of the channel managers now use PromiseInterfaces for consistencies. This means that instead of returning int or strings, you may now return a FulfilledPromise($value) to easily get resolved. If you don't implement your own channel manager (or now defunct, replicator), it's totally fine.
• Presence channels now properly trigger the .here() methods.
• Dashboard got broadcasting fixes. If you still encounter issues with sending events from the dashboard, open an issue.

Pre-Rewrite changelog

• Restructured the config file ([2.x] Config Changes #446)
• Redis PubSub driver support for Horizontally-scaled WebSocket servers (Redis as a replication backend for scalability #140, Apply fixes from StyleCI #448, Add some extra ENV variables for the config file #477, 5b6bdf4) Rewritten, Channel Managers now do all the jobs on tracking the channels and connections
• Rename the AppProvider to AppManager to avoid conflicts with Larave's App Providers ([2.x] Refactor App Providers #451)
• Remove Laravel 5.8.x ([2.x] Remove support for Laravel 5.8 #452)
• Extendable hooks as in Exist a way to implement webhooks? #80 ([2.x] Extendable hook #465, 3e239a0) The extendable hooks' place in config file got changed. Get a new copy of the config file.
• Refactor dashboard with Tailwind ([2.x] Refactoring dashboard #467)
• Add per-app CORS settings ([2.x] Per-app CORS #469)
• Docblocks ([2.x] Docblocks #471) Rewritten from scratch.
• Custom statistics loggers (including the already-provided Database using ORM) ([2.x] Custom statistics drivers #473, 714cc5b, 108a717) Statistics Loggers now are called Statistics Collectors and their job is to store the data temporarily between dumps. When the amount of time in seconds pass, they are dumped into a Statistics Store. Defaults to Database.
• More use cases tests ([2.x] Test Refactoring #450, [refactor/tests] Added tests for Redis PubSub replication #453, [2.x] Redis connector tests #464, [2.x] Code coverage fixes #482) TDD-ed the entire project while keeping in mind the functionality tests.
• Update docs to reflect changes ([2.x] Docs #468)
• • Using WebSockets with Cloudflare (does not support 6001 as default port)
• • Setting up the websockets broadcaster for the horizontal scaling function
• • Restarting the server with websockets:restart

[lionslair]

So So happy to see these things finally progressing. Will try and update this during the week and will test it out on staging.

[rennokki]

@lionslair Lovely!!! Hit the issues board for suggestions/issues.

[lionslair]

@lionslair Lovely!!! Hit the issues board for suggestions/issues.

I will have not had a chance to enable yet. 2 / 12hr days. will do my best to get it turned on tomorrow. Thanks for putting the work in on these topics

[codecov-commenter]

Codecov Report

Merging #447 into master will increase coverage by 41.38%.
The diff coverage is 93.27%.

@@              Coverage Diff              @@
##             master     #447       +/-   ##
=============================================
+ Coverage     48.57%   89.96%   +41.38%     
=============================================
  Files            50       60       +10     
  Lines          1126     1545      +419     
=============================================
+ Hits            547     1390      +843     
+ Misses          579      155      -424     

Impacted Files	Coverage Δ	Complexity Δ
src/Facades/WebSocketRouter.php	100.00% <ø> (ø)	0.00 <0.00> (?)
src/Server/HttpServer.php	100.00% <ø> (+100.00%)	0.00 <0.00> (-1.00)	⬆️
src/Server/Loggers/ConnectionLogger.php	0.00% <ø> (ø)	0.00 <0.00> (?)
src/Server/Loggers/HttpLogger.php	31.57% <ø> (ø)	0.00 <0.00> (?)
src/Server/Loggers/WebSocketsLogger.php	24.00% <ø> (ø)	0.00 <0.00> (?)
src/Server/Messages/PusherMessageFactory.php	100.00% <ø> (ø)	0.00 <0.00> (?)
src/Server/QueryParameters.php	100.00% <ø> (ø)	0.00 <0.00> (?)
src/Dashboard/Http/Controllers/SendMessage.php	34.78% <31.81%> (+34.78%)	0.00 <0.00> (-2.00)	⬆️
src/Server/Loggers/Logger.php	47.82% <47.82%> (ø)	0.00 <0.00> (?)
src/Server/HealthHandler.php	66.66% <66.66%> (ø)	0.00 <0.00> (?)
... and 102 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c85ec38...2839d4c. Read the comment docs.

[rennokki]

@lionslair It seems like the event.error does not exist. Can you post here the value of event? 🤔

[lionslair]

@lionslair It seems like the event.error does not exist. Can you post here the value of event? thinking

Solved. I edited the secret somehow this afternoon. I have spent all day trying to get this running on staging. I don't think the broadcaster websockets is working when using pubsub setup. I can see no messages in the dashboard being sent by laravel

[rennokki]

@lionslair The messages are being sent by the laravel's event classes or by using the dashboard form?

[lionslair]

@lionslair The messages are being sent by the laravel's event classes or by using the dashboard form?

nope

[lionslair]

@lionslair The messages are being sent by the laravel's event classes or by using the dashboard form?

nope

I get that message from friday still.

message: Argument 3 passed to BeyondCode\LaravelWebSockets\PubSub\Broadcasters\RedisPusherBroadcaster::broadcast() must be of the type array, null given, called in /home/PATH/vendor/beyondcode/laravel-websockets/src/Dashboard/Http/Controllers/SendMessage.php on line 41
Exception: TypeError
vendor/beyondcode/laravel-websockets/src/PubSub/Broadcasters/RedisPusherBroadcaster.php
line: 134

[lionslair]

Hmm then others I do it but not showing in the activity. So I do not think the pubsub is working correctly.

[rennokki]

@lionslair Try updating to latest 2.0.0-beta.10, I have added more functional tests and there are fixed a few issues with the dashboard broadcasting & event listening.

[lionslair]

@lionslair Try updating to latest 2.0.0-beta.10, I have added more functional tests and there are fixed a few issues with the dashboard broadcasting & event listening.

Been sticking to
"beyondcode/laravel-websockets": "2.x-dev",
apart from when I am trying to debug. just pulled

[lionslair]

does it need to clear the channel and event name on every submit but leave the data. Can it leave it and have a reset button to clear it?

[lionslair]

@lionslair Try updating to latest 2.0.0-beta.10, I have added more functional tests and there are fixed a few issues with the dashboard broadcasting & event listening.

Seems to post from the dashboard ok now but no events appear to be getting received from laravel that are being broadcast

[lionslair]

@rennokki does it make any sense why or how $connection can be empty?

[rennokki]

If it's null then it uses the default Redis connection for the Pub/Sub:

However, I think the connection name should be replaced with the one configured in the replication config.

[lionslair]

If it's null then it uses the default Redis connection for the Pub/Sub:

However, I think the connection name should be replaced with the one configured in the replication config.

Hmm we are using phpredis but I don't think that matters.

[rennokki]

This feature is the pong tracker that was implemented just like Pusher docs explains it (120s time to ping the connection): 55f1332
, actual logic here: https://github.com/beyondcode/laravel-websockets/blob/2.x/src/ChannelManagers/RedisChannelManager.php#L427-L441

The problem inflicted here is "what happens if the local connection suddenly drops"? If some VPS provider employee trips over a cable and the whole instance goes down without being able to SIGTERM/SIGINT the websockets process? The connections cannot be serialized to be safely stored, so-to-speak to have a stateful way of doing things. Once the connection falls down, it cannot be retrieved.

However, we do keep presence channels' users and we can know when the user last connected, but that requires more logic to cleanup any socket ids stored and their members data for sockets that are not found on any server.

[francislavoie]

That code is for handling dead websocket client connections. My suggestion was about dead websocket servers. All servers should keep an eye on whether each server has checked in with redis within a certain time period. If not, they should clear out any data that server was managing.

[zakriyarahman]

@rennokki Am I missing something?

[rennokki]

The artisan command websockets:flush was removed and we'll find a workaround in the next versions. Try upgrading to the latest beta version.

[rmundel]

Any more testing needed to release the kraken?

[rennokki]

Guess we're good to go. 👀

[morloderex]

Would it be worth it to wait for #644 sense it has many more breaking changes to app managers and and i personally would love to see you support MySql managers out of the box.

cc @mpociot

[rennokki]

@morloderex This PR has become too large to handle at this point, so maybe it's a good idea to schedule it for a possible 3.x, since 2.x brings great improvements that might be worth pushing.

[rennokki]

I have talked with @mpociot and decided to take Laravel's way of doing things:

• we'll have 1.x support for the current master branch, so any apps that still use 1.x package will still be patched in case of security issues
• 1.x will become the main branch for now, until a 2.x is released; upon release, 2.x branch is going to be the main branch
• from now on, master will take only breaking changes commits for the upcoming versions (see https://laravel.com/docs/8.x/contributions#which-branch for more info)

[radudiaconu0]

@rennokki i see you merged all tfrom 2.x branch into master branch nad delted 2.x branch. So how i install laravel-websockets 2 then ? :)

[rennokki]

@radudiaconu0 2.x is still under dev but i merged it into master to be able to handle the future prs better. This PR became too large to handle even for github (that threw unicorns when i tried to make a 2.x pr)

2.x is still available under latest beta.

[radudiaconu0]

@rennokki so when i run composer require beyondcode/laravel-websockets this should install 1.x branch or master? :)) ( i guess 1.x)

[rennokki]

It will install latest 1.x release. The 1.x release is still on the 1.x branch