Data gathering for best effort API similarity with the leading client of a new lnaguage for ease of migration and use.

[avifenesh]

Important

If you are a user of glide, consider to be one, or waiting for your language to get its binding already, please comment your input.

Best effort API similarity

In the contributors meeting, we had a discussion on whether we should put some effort on trying to keep our API similar to the main client that exists in the ecosystem of the specific language.
In the current state, we are referring to C# and .NET, so the main existing client is StackExchange.Redis. -- C# clients stats in the comments.
While there's a lot of strong opinions around it, we need to have a data backed decision.

Understanding the implications:

We can't start the discussion without understanding what we're discussing.
We might understand that we are having the same API or that it is not feasible at all, but probably it will be somewhere in the middle, and we should understand where.

1. Find the 10-15 most used commands used in valkey.
2. Identify the differences between our general API to those of the compared client.
3. Assess what are the implications if we try, what will get to break, and if we try to keep the API decision that important to us, how different it will be if we do half-and-half.
4. Development cost to build a forced API on top of the core API.

Understanding the users

After understanding the above question, we should understand how what we find feasible will affect users.
We need to understand how each one of the options we find feasible will impact users' adoption and ease of use.
Ways to gather information: (Please add yours)

1. Directly reach out to current users and ask how much weight the differences had in their decision to migrate.
   It's relevant for any of the languages.
2. Reach out to those we know that decided not to migrate because of the differences and get their input.
3. Reach out to potential users of the C# binding
4. Reaching out to the SA's and TAM's of GCP and AWS to check with theirs customers.

Please add points if you find some missing.

After we will have the data, we can keep iterating over the discussion.

[avifenesh]

The three existing clients are StackExchange.Redis, ServiceStack.Redis, NRedisStack.
Stats:

Metric	StackExchange.Redis	ServiceStack.Redis	NRedisStack
GitHub Stars	6,000	2,300	266
GitHub Forks	1,500	872	41
GitHub Contributors	206	67	22
NuGet Total Downloads	597.2M	18.7M	3.5M
NuGet Latest Stable Version Downloads	300,062	24,059	41,666
Community Mentions (Qualitative)	Very Frequent	Frequent	Moderately Frequent
Update Frequency (Qualitative)	Active	Active (NuGet)	Active
Community Support Channels	Stack Overflow	Forums	Redis Community, Stack Overflow (via StackExchange.Redis), Semantic Kernel Discord (related)

[Sa1Gur]

The three existing clients are StackExchange.Redis, ServiceStack.Redis, NRedisStack. Stats:

Metric StackExchange.Redis ServiceStack.Redis NRedisStack
GitHub Stars 6,000 2,300 266
GitHub Forks 1,500 872 41
GitHub Contributors 206 67 22
NuGet Total Downloads 597.2M 18.7M 3.5M
NuGet Latest Stable Version Downloads 300,062 24,059 41,666
Community Mentions (Qualitative) Very Frequent Frequent Moderately Frequent
Update Frequency (Qualitative) Active Active (NuGet) Active
Community Support Channels Stack Overflow Forums Redis Community, Stack Overflow (via StackExchange.Redis), Semantic Kernel Discord (related)

How did we decided on this list? If we including 2k stars one, why https://github.com/2881099/csredis is not listed?

[avifenesh]

please list it, im not familiar enough with the ecosystem, did a fast search, but I'm pretty sure the relevant one is only stackexchange

[ikolomi]

"Best effort" is meaningless - you dont get a race car performance by putting a spoiler on a family car and vice versa.

This whole discussion does not make sense - Glide is a software product, implementing some functionality (semantics) and exposing it via language-specific interfaces (syntax). Semantics and Syntax work together. Even if it is possible to translate the current Syntax to other library Syntax (see the spoiler analogy), this still wont make client code compatible.

Moreover, it will harm GLIDE a lot - GLIDE was built upon the idea of having a common functionality code, which exposed by thin, idiomatic, minimum-effort bindings. This means that if we had a sufficient RPC technology (e.g. GRPC) the binding would be generated automatically. This also means that all the bindings look and feel the same. Taking an foreign interface and implementing it for a selected binding BREAKS this tenant.

If we want truly make the client's migration easier, we should do it not by messing the GLIDE code but via a dedicated Adapters which will translate a foreign interface to a unified GLIDE interface. This will also make the migration truly convenient since the Adapter will implement the entire foreign interface.

@asafpamzn

[Sa1Gur]

If we want truly make the client's migration easier, we should do it not by messing the GLIDE code but via a dedicated Adapters which will translate a foreign interface to a unified GLIDE interface. This will also make the migration truly convenient since the Adapter will implement the entire foreign interface.

Could you elaborate more on this idea, cause I don't understand it

[jbrinkman]

While I like the idea of a common "feel" to each of the libraries, what is the benefit to the user for this common feel? How many users will use a library in Python and Node and Go? The vast majority will only experience it in a single language. So is it better to have an idiomatic Glide experience or an idiomatic language experience? The way I write code in Node, and the idioms in Node are very very different from the idioms in Java. The way you write async code in Go looks very different from async code in .Net and I think there is real value in leaning into the each language, even if it means that every Glide language wrapper feels different.

[X39]

Creating Drop-In packages for .NET should be relatively straightforward, provided there are no licensing conflicts. However, ongoing maintenance is also necessary.

Personally, I would prefer a .NET tool that facilitates upgrading to Glide. However, this would require that most, if not all, of the library semantics can be effectively translated to Glide.

Roslyn platform can already be used for that: https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/get-started/syntax-transformation

[avifenesh]

that actually look cool, ill dive into it

[Sa1Gur]

If the customer wants to move to new client, how many lines of code needs to be changed? I'm not sure it is a lot. Probably makes sense to check out heavy users code. Cause having the compatibility is huge constrain and benefit yet unclear

[avifenesh]

Valid question. What do you mean by heavy users?

[Dustin4444]

Important

If you are a user of glide, consider to be one, or waiting for your language to get its binding already, please comment your input.

Best effort API similarity

In the contributors meeting, we had a discussion on whether we should put some effort on trying to keep our API similar to the main client that exists in the ecosystem of the specific language. In the current state, we are referring to C# and .NET, so the main existing client is StackExchange.Redis. -- C# clients stats in the comments. While there's a lot of strong opinions around it, we need to have a data backed decision.

Understanding the implications:

We can't start the discussion without understanding what we're discussing. We might understand that we are having the same API or that it is not feasible at all, but probably it will be somewhere in the middle, and we should understand where.

1. Find the 10-15 most used commands used in valkey.
2. Identify the differences between our general API to those of the compared client.
3. Assess what are the implications if we try, what will get to break, and if we try to keep the API decision that important to us, how different it will be if we do half-and-half.
4. Development cost to build a forced API on top of the core API.

Understanding the users

After understanding the above question, we should understand how what we find feasible will affect users. We need to understand how each one of the options we find feasible will impact users' adoption and ease of use. Ways to gather information: (Please add yours)

1. Directly reach out to current users and ask how much weight the differences had in their decision to migrate.
   It's relevant for any of the languages.
2. Reach out to those we know that decided not to migrate because of the differences and get their input.
3. Reach out to potential users of the C# binding
4. Reaching out to the SA's and TAM's of GCP and AWS to check with theirs customers.

Please add points if you find some missing.

After we will have the data, we can keep iterating over the discussion.

[avifenesh]

?