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

Introducing Sessions & Channels? #195

Open
alangecker opened this issue Nov 12, 2022 · 0 comments
Open

Introducing Sessions & Channels? #195

alangecker opened this issue Nov 12, 2022 · 0 comments
Labels
enhancement New feature or request

Comments

@alangecker
Copy link

alangecker commented Nov 12, 2022

while working on live updates for deck utilizing notify_push, I reached some limitations and was generally wondering whether lot of the work could be somehow abstracted from the individual app (I already copied a lot of code from text)

Current limitations / issues

  • only possible to target clients by userId, not individual sessions (for example required for excluding the causing session from an update event)
  • Each app, which wants to implement something like real-time updates (hopefully many more in the future!), must take care of its own list of active sessions (creation of sessions, closing - not trivial, expiration, cleanup, documentation,...) even though it is always more or less the same task

After much deliberation, I think to abstract/unify this task of tracking active users introducing the following two concepts within notify_push does make sense:

Proposals

1. Concept of "sessions"
  • each client could get an unique session identifier (either randomly client generated and sent to the rust backend or generated by the backend and sent to the client)
  • IQueue::push() accepts user or session as selector
  • notify_push should be responsible for closing the session (an API endpoint which gets called on visibilitychange by the client library or when the session expires by the rust backend), broadcasting an event which an app can listen to:
    $context->registerEventListener(SessionClosedEvent::class, MyParticipantsCleanupListener::class);
  • After a reconnect (for example when a tab has been paused for a while) for minimized complexity it should be considered a fresh session. This requires the possibility, that an app frontend can listen to this happening and can then call the appropriate api endpoints again.
2. Concept of "channels" (requires sessions)
  • option to subscribe sessions to an "channel" identifier
    $queue->subscribeChannel($session, "deck:board:16");
    $queue->unsubscribeChannel($session, "deck:board:16");
  • notify_push is responsible to keep track of the list of sessions and automatically "unsubscribe" expired/closed sessions
  • app is responsible to call subscribeChannel() when it is needed and the client is authorized
  • IQueue::push() also accepts channel as a selector
    $queue->push('notify_custom', [
      'channel' => "deck:board:16",
      'message' => "card_update",
      'body' => ["foo" => "bar"]
    ])
  • Allowing to specify multiple channel could be sometimes really handy. It could be ensured, that a session listening to more than one of the channels doesn't get the event multiple times
    $queue->push('notify_custom', [
      'channel' => ["deck:board:16", "deck:dashboard:admin"],
      'message' => "card_update",
      'body' => ["foo" => "bar"],
    ])

Not yet considered

  • can this also handle guests without an account?
@joshtrichards joshtrichards added the enhancement New feature or request label Oct 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants