[2.x] Asynchronous app managers

[mpociot]

This PR adds the ability of asynchronous application managers.
The default application manager only stores the apps in a configuration file, but if you want to store your applications in a database, the application managers need to resolve them asynchronously.

As this PR introduces quite a lot of breaking changes, due to the fact that application managers now return promises, instead of app instances, we need to refactor most of the API related tests. I would suggest that we actually start the WebSocket server in our tests and then perform actual HTTP requests on the internally started server - rather than just faking HTTP requests, as we do it right now.

The SQLite application manager still has one pending issue that needs to be resolved: clue/reactphp-sqlite#35

• SQLite application manager
• MySQL application manager
• Refactor tests
• Documentation

[vdauchy]

Hi @mpociot ,

I was just starting to dig into having the Apps in MySql too when I found your PR, so after looking at your code I'm super excited about it :-)

I just have one question about the AppManager::all(): array interface:

Do you think we could make it support pagination ?

I'm asking as I feel this would be the next step as when Apps are in db we could have quite a few in them :-)

Thank you and @rennokki as the code of this package is of a rare quality.

[mpociot]

@vdauchy Do you think that'll be necessary? The all method is only needed within the Dashboard for the dropdown.
But I'd love some help on the MySQL part of this PR :)

[zek]

I think we should consider adding Swoole support instead ReactPHP.

[mpociot]

I think we should consider adding Swoole support instead ReactPHP.

This is something that #756 is trying to implement, and way out of the scope of the current 2.x version

[DarkGhostHunter]

The final goal of that PR is to have drivers for each async library that enables non-blocking WebSockets: Amphp, React, Ratchet, Swoole and Roadrunner (yes, WS should be landing soon on RR 2.0).

For that, major rework has to be done as it's possible to abstract as contracts each part of the WebSocket implementation, meaning, we only need to "wire" connection events and their data to their respective handler, router, and controller. In other words, abstract the client connected, the server, and the message.

It's not a small feat, but it allows the package to separate the exposed functionality from the driver itself. This could diagnose problems and bugs easier as you could just swap the driver and see if happens again.

For the case of Async Redis, use Amphp Redis unless the driver comes with its own, like Swoole does, but I haven't checked if it's mandatory for performance reasons. Since the next version could abstract the loop from the driver, calls to Redis (or even the Database) could use the loop using the default Laravel/PHP driver.

I don't know why I posted this here, but anyway...

[vdauchy]

@DarkGhostHunter Thanks for sharing your thoughts here, I need to look at the mysql implementation for myself and will share what I find. I just cannot share any timelines right now as I have not much time to spare, but will as soon as I can...

@mpociot For the pagination, in a multi-tenants with multi-db this may not be needed as each db/stats table would have only one app id. However if you decide to bring all your stats to one db and one big table, then pagination might be useful if you start to have tens or hundred app ids.