Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pub/sub message queue wss push updates #365

Open
raffis opened this issue Jul 18, 2019 · 3 comments
Open

pub/sub message queue wss push updates #365

raffis opened this issue Jul 18, 2019 · 3 comments

Comments

@raffis
Copy link
Contributor

raffis commented Jul 18, 2019

Is your feature request related to a problem? Please describe

Currently there is no possibility to push updates to clients.

V3 will integrate long polling #122 but this will be too resource intensive for various reasons if there are too many connections. Long polling is more resource intensive in general, MongoDB is not asynchronous in PHP (even with swoole #338 ).

Describe the solution you'd like

An async message broker should get implemented in the stack while resource changes via the rest api (or internal changes) will get pushed to the queue by the balloon server.
V3 will implement swoole #338 as http server with an event loop and should also implement a websocket server. The websocket server loop should subscribe changes from the message queue and publish all resources to receivers.

The resource factories (which will get implemented in v3, with the concept from tubee) should determine what resources should get published to what users and this information must be stored in the queue as well. With that information the websocket loop can push those resources to the connected clients and determine what resources must be pushed to what clients.

Possible messages queues:

  • redis (Has swoole support!)
  • RabbitMQ (There are async clients for PHP around, not sure if they're compatible to swoole)
  • MongoDB (As described bellow as alternative)
  • Something bigger like kafka, but I don't see need for that and is probably a too heavy design and feels not lightweight at all.

A working implementation of this will also mean the end of the delta /api/v2/delta endpoint. However the delta endpoint will still be supported in the apiv1.

Note that long polling #122 will still get implemented, #365 can be seen as better alternative to long polling and should be preferred by most clients which require a persistent connection for as long as possible.
Long polling might be better if one wants to watch updates of a single resource pool over a short period of time.

Describe alternatives you've considered

Using the existing MongoDB and the loop may watch over all collections. This however has several disadvantages:

  • MongoDB implementation is not async in PHP, even not with swoole.
  • What users see what resources is not stored in any resources directly.

An alternative possibility however could be to only subscribe to events and publish only those to clients. But not all resources (updates,create,delete) are currently represented as events.

Additional context

Add any other context or screenshots about the feature request here.

@raffis
Copy link
Contributor Author

raffis commented Jul 18, 2019

RFC-2 pending.

@raffis
Copy link
Contributor Author

raffis commented Oct 18, 2019

Might also look into sse. But probably not much different to long pulling.

@raffis
Copy link
Contributor Author

raffis commented Nov 14, 2019

Actually Using Swoole #338 and MongoDB does work. I've implemented a mongodb changestream within a swoole process which pushes events to connected clients (ws).

raffis added a commit that referenced this issue Dec 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant