Improving presence API

[ScreamZ]

Hi,

I found the current presence API a bit too "large", as you're listening to everybody or just specific name.

Maybe we could take into consideration of what https://supabase.com/docs/guides/realtime/presence do ? Seems really nice.

Presence could be on a per topic/pattern, just like Listening somehow allow.

Currently, I can use Listening feature to mimic some kind of presence per topic, by just listening to a thread where I'm not pushing anything. But i guess we could do better

[jaime-ez]

Hi, thanks for the suggestion!

As I see from the supabase docs their presence feature is per channel, in deepstream is per server, so it's a different concept.

I agree that it could be a useful feature to add a subscribers method per topic in order to know who/how many are subscribed to that topic.

However at a server level the current subscriber implementation only keeps track of local sockets (users) who are subscribed, it's not at a cluster level. The cluster only knows if a server has a subscription to the topic or not. So if a server does not have that provider locally (or local providers reject the request), it asks the cluster. I'm not in favour of changing such logic because its a core characteristic, it keeps cluster messages small and reduces the shared state.

An equivalent subscribers feature could be implemented with a plugin that could listen to monitoring messages and from there keep a record that tracks who's subscribed to which event or channel.

In general the spirit should be to add any new feature as a plugin, thats one of the great selling points of deepstream (at least to me), that you can create a plugin almost for everything. Monitoring messages are a great tool, because everything goes through there.

Let me know what you think, best

[ScreamZ]

So what you mean basically is that https://deepstreamio.github.io/docs/tutorials/core/presence/query-clients is just subscribed to the same user that is on the same server in a cluster. Let me illustrate with an example:

Example :

• Clients 1 and 2 are connected to server 1.
• Client 3 is connected to server 2.

If client 1 use presence, it will only see client 2?

Further discussion Depending on what you say about my schema above:

If this is true

About the fact of writing a new plugin to handle presence, generally speaking, I agree with you, however, sometimes I don't like when we are overwhelmed with thousands of plugins because after that it becomes so hard to compose and you need to remember that there is a plugin for that. Exception if this is well documented in the software manual and the user doesn't have to rely on an external searching process.

❓So one good tradeoff could be to make a such plugin and add this as core documentation for the presence API.

If this is false

I think the presence API is really strange and I don't get the utility of that

[jaime-ez]

Hi, now I realize that I wasn't accurate on the presence description, it is per cluster (not per server as I said before), and there is a shared state between the cluster servers that keeps track of connected clients.

I agree that plugins can be overwhelming, but it's the only way of keeping a slim core, and thus minimize bugs. Take a look at the plugins guide and try to make a simple monitoring one.

I'll share some code later on a plugin I use that could be relevant.

[ScreamZ]

Here is a quick sketch of how the plugin can work: