Passing Existing Valkey Client to valkeyaside, valkeylimiter, etc

[jacobdrury]

Hi! I’ve noticed that packages like valkeyaside, valkeylimiter, etc., create their own Valkey connections internally, rather than accepting an existing client instance. Is there a technical or architectural reason for this design choice? Would you consider supporting direct client injection in the future?

I see that these packages accept a ClientBuilder, which seems like it could be used as a workaround to pass in an existing client by ignoring the options parameter. For example:

valkeyClient, err := valkey.NewClient(...)

locker, err := NewLocker(LockerOption{
    ClientBuilder: func(valkey.ClientOption) (valkey.Client, error) {
        return valkeyClient, nil
    },
})

Is this an intended use case, or just a workaround?

Also, is my understanding correct that, in most cases, a single Valkey server should only have one client instance per application? I’m just starting to learn and use Valkey, so any guidance would be appreciated.

Thanks!

[rueian]

Hi @jacobdrury,

Yes, the technical reason is that those specialized wrappers may require special setup. Take valkeyaside as an example:

valkey-go/valkeyaside/aside.go

Line 41 in d4865cb

option.ClientOption.OnInvalidations = ca.onInvalidation

It needs its own OnInvalidations handler to be registered, so if you inject an existing client with the ClientBuilder, it won't work correctly. When you use the ClientBuilder, you must use the options it gives you to construct a new client.

Also, is my understanding correct that, in most cases, a single Valkey server should only have one client instance per application?

Yes, it is correct, and most wrappers will allow you to access the underlying client directly with the Client() method. Take valkeyaside as an example again:

valkey-go/valkeyaside/aside.go

Line 28 in d4865cb

Client() valkey.Client