Introduce Valkey client overview

[asafpamzn]

• Created a new document that provides an overview of recommended Valkey clients across various programming languages.
• Included mandatory features required for each client, such as Cluster Support and TLS/SSL Support.
• Detailed advanced features supported by the clients, including:
  • Read from Replica
  • Exponential Backoff to Prevent Storm
  • Valkey Version Compatibility
  • PubSub State Restoration
  • Cluster Scan
  • Latency-Based Read from Replica
  • Client-Side Caching
• Added feature comparison tables for each programming language (Python, JavaScript/Node.js, Java, Go, PHP, C#) to highlight the unique capabilities of each client.
• Placeholder sections for Ruby and other languages marked as TODO for future updates.
• References section includes a link to the official Valkey documentation.

[ranshid]

@asafpamzn Thank you for that initiative. it was discussed several times that we need some feature support metric for known clients.

Several high level remarks:

1. our new process for introducing new features/documentations which will require some discussion is to create a suggestion in valkey-rfc first. I suggest you create one there.
2. I am wondering if a separate table for each language is better than a single flat table also indicating the supported language? (eg. for glide it would state comma separated list of languages and a single one for others)?
3. I would think we need to discuss which features are important to indicate. For example inline protocol support, binary protocol, functions, client algorithms etc... WDYT?

[asafpamzn]

@ranshid , thanks for the feedback.

1. Sure, will do.
2. I think that usually users are having a single language or 2, it will be more convenient to jump to the relevant part at the doc.
3. This is just a draft PR and proposal. I agree that we should discuss, what should be the forum? Can we discuss in this PR or do we need additional process?

[asafpamzn]

@ranshid , @zuiderkwast ,

I updated the PR according to your comments.
Who should I work with on this PR to merge it to the website?

[madolson]

I like the summary overall. @rueian @yangbodong22011 Would also be great if you can review this.

[yangbodong22011]

I think we can put all clients Feature Comparison Table in one tables.

Name	Language	Mode Support	Recommend Version	Connection Mode	SSL Support	Cluster Advanced Command	Read from replica	Exponential backoff to prevent storm	Valkey version compatibility	PubSub state restoration	Cluster Scan	Latency-Based Read from Replica	Client Side Caching	RESP3	Async API	Auto reconnect when network down
valkey-java	Java	standalone/sentinel/cluster	5.3.0+	connection pool	Yes	No	No	No	7.2	No	No	No	No	Yes	No	Yes
...

[zuiderkwast]

I think we can put all clients Feature Comparison Table in one tables.

I like this idea.

If the table is large, it can be messy to maintain it as Markdown.

If we have one JSON file per client (like we have for the old redis clients still in this repo), we could add this information in the JSON files and render the table on the website.

[yangbodong22011]

I think we can put all clients Feature Comparison Table in one tables.

I like this idea.

If the table is large, it can be messy to maintain it as Markdown.

If we have one JSON file per client (like we have for the old redis clients still in this repo), we could add this information in the JSON files and render the table on the website.

agree👍

[asafpamzn]

I think we can put all clients Feature Comparison Table in one tables.

I like this idea.
If the table is large, it can be messy to maintain it as Markdown.
If we have one JSON file per client (like we have for the old redis clients still in this repo), we could add this information in the JSON files and render the table on the website.

agree👍

I don't agree, usually customers are first choosing the language and next the client, the client is a small part at the application, basically a driver. I don't think that the average reader will care about clients in other languages. I do agree that for the valkey maintainers it is a better view.

[mcollina]

lgtm

[zuiderkwast]

We need to decide where to put this document.

[stockholmux]

I think this will become very difficult to maintain if we have it as hand-written markdown.

I'm generally in favour of having it generated from JSON @zuiderkwast suggested.

The question for me is does that get generated as part of docs or website. Related: should this be in the man pages? The information could be useful but if they're mostly links out to GitHub repos it feels like that's more typically something someone would browse from the web, not from a terminal.

[asafpamzn]

'm generally in favour of having it generated from JSON @zuiderkwast suggested.

The question for me is does that get generated as part of docs or website. Related: should this be in the man pages? The information could be useful but if they're mostly links out to GitHub repos it feels like that's more typically something someone would browse from the web, not from a terminal.

@stockholmux , why do you think that it will be hard to maintain? It is up on the clients maintainers to update it once new feature is added. It does not happen that frequently.

It should be part of the website, I agree

[stockholmux]

@asafpamzn If something is represented as data (i.e. JSON), it's far more maintainable than hand written markdown which is difficult/time consuming to review and audit. As an example, some of the hand written markdown in the content we inherited in this repo was literally a decade out-of-date. No one reported this for years. Data we can query and answer questions quickly.

Additionally, markdown fixes the format in markdown tables which is not sortable or filterable. If it's data, that we have more options.

Finally, If we have it stored as data we can do represent of the data in different ways and in different places not just fixed into a single markdown file.

[madolson]

The question for me is does that get generated as part of docs or website. Related: should this be in the man pages? The information could be useful but if they're mostly links out to GitHub repos it feels like that's more typically something someone would browse from the web, not from a terminal.

My intuition is that all the specific client information shouldn't be part of the man pages. I feel like that is getting too low level to be materially useful to most individuals, and the clients are also updated independently from the rest of the code.

Additionally, markdown fixes the format in markdown tables which is not sortable or filterable. If it's data, that we have more options.

I suppose to extend this, we already have JSON files for all of the clients. We could simply extend them to also include all these extra fields which can be used during the render.