valkey-io/valkey-glide

Java-Client Commands Interface: discussion

Closed this issue · 1 comments

acarbonetto commented

Describe the feature

According to the API discussion, the topic of offering a separate Commands interface was discussed. With a commands interface, we would offer calls to Java-client users like so:

// example calls
babushka.client.api.RedisClient redisClient = RedisClient.ConnectToRedis(host, port); 

// get async command set
babushka.client.api.Commands commands = redisClient.getCommands();

// string set 
commands.set("foo", "bar").get().isOk(); // true

This allows us to consolidate all supported commands in a Commands object defined for the strict purpose of delivering requests.

The RedisClient, on the other hand, is defined for the strict purpose of delivering connection requests (with configuration) and saving the connected state.

Pros:

  • This splits the responsibilities of the Client and Commands interfaces.
  • Variants of the Commands interface can be provided to the customer (Transactions, Async vs Sync, RESP2 vs RESP3, etc)

Cons:

  • Users have to make a separate and extra call to get the Commands interface after connecting.
shachlanAmazon commented

We discussed this, and decided against. From our experience it's less ergonomic - the user doesn't expect to add another call/object between the client and the commands, and it adds lifetime/correctness considerations which are hard to express - for example, how would a Commands object behave once a client is disposed?

Variants of the Commands interface can be provided to the customer ([...], RESP2 vs RESP3, etc)

this isn't true - RESP format is decided at connection time, and a single client can use only one of them.

  • 👍1