Typescript subscribe / mutating a subscription

[cbschuld]

Hey All, attempting to understand the design of the Typescript client. If you are looking to do pub/sub with the valkey pub/sub it does not appear that you can adjust the subscription after connection.

In the code it shows:

**Pub/Sub Subscriptions**: Predefine Pub/Sub channels and patterns to subscribe to upon connection establishment. 

Is the intended design for one connection per subscription? Are there future plans to modify a subscription or have a subscribe action?

[avifenesh]

Hi :)
@ikolomi can you take a look?

[asafpamzn]

The goal of the pub/sub and sharded pub/sub design in GLIDE was to make it robust. GLIDE resubscribes on connection failure/failover, scaling events, and slot migration. That is, as a user, you can be assured that your subscription is always valid, and you don't have to handle it at the application level.

As a result of this design decision, we created a non-mutable subscription scheme, which simplifies the code, which is already quite complex as it has to handle many scenarios.

We released it as the initial version, and we are waiting for user feedback to see if the ability to add more subscriptions on the fly is something that many users would like. Alternatively, most applications may be fine with this immutable scheme.

Please describe your specific scenario and why the current approach is not sufficient. We'd be happy to enhance the pub/sub implementation to be more flexible.

Our recommendation is to create a separate client for pub/sub, and not use the same client for both pub/sub and other traffic.
For more info see https://github.com/valkey-io/valkey-glide/wiki/General-Concepts#pubsub-support

@ikolomi will be able to answer more in depth if required as he designed the pub/sub in GLIDE

[avifenesh]

@cbschuld ⬆️

[cbschuld]

Hey @asafpamzn thanks, that clarifies the reasoning behind the immutable connection design:

Our use case involves users subscribing to numerous topics (e.g., via GraphQL subscriptions for UI updates), but typically only needing a few specific topics at any given time based on their current view in the application. These needed subscriptions change frequently and are often short-lived as users navigate.

The current design forces a choice between:

• Inefficiently managing short-lived Valkey client connections.
• Inefficiently subscribing to everything and filtering at the application level, wasting bandwidth and processing.

Allowing dynamic SUBSCRIBE / UNSUBSCRIBE commands on an existing connection would directly address this by enabling efficient, fine-grained subscription management within the clien itself, which would be ideal for our use case.

Furthermore, considering that dynamic subscription management via SUBSCRIBE / UNSUBSCRIBE is a fairly fundamental feature in most established Redis clients, its absence feels like a gap for a library intended as a next-generation client or replacement.

[asafpor]

Thanks,
@ikolomi can you please estimate the effort of adding it and lets see if when we can add it

[ikolomi]

@cbschuld
The mutable subscriptions are absolutely feasible and can be achieved by the means of

    public async customCommand(
        args: GlideString[],
        options?: DecoderOption,
    ): Promise<GlideReturnType> {
        return this.createWritePromise(createCustomCommand(args), options);
    }

In that regard GLIDE is not less flexible than other clients, although it does not model the pubsub commands idiomatically.
The downside of this approach is the degraded robustness (as opposed to the immutable approach) in a sense that the topology changes and disconnections will not resubscribe automatically on behalf of the client. Thus, we opted not to model the mutable pubsub commands, and rely on customCommand api for the cases like yours. By the way, the lack of automatic re subscriptions is also no different from the other client solutions.

Having said that, the full and mutable pubsub APIs in our backlog which might be delivered in foreseeable future.

[cbschuld]

@ikolomi (and @asafpamzn), thank you for the response and explaining the customCommand approach. 👍

I see the value in the robust resubscription for the initial, immutable set. I also understand using customCommand for dynamic changes mirrors the manual resubscription required by applications using other clients.

This actually highlights a key opportunity for your project: what if it didn't just mirror other clients in this aspect? By providing idiomatic subscribe / unsubscribe methods and extending the automatic resubscription logic to cover the entire current set of subscriptions (which would need to be dynamically managed), the Glide client could offer superior robustness and developer experience compared to the status quo.

While applications can build this layer, handling subscription state persistence through reconnects seems like a core function that a client library should handle. Implementing this would make Glide significantly more compelling for dynamic use cases like ours and truly position it as a "better" client, rather than requiring developers to reimplement this common pattern over customCommand.

Obviously my opinion but wanted to share.