Go: rearrange entry package name and path

[marcind]

The current Go package name of api has some problems, including not following naming conventions.

• It is too generic (like util or similar names).
• It causes the primary entry point to "stutter": api.NewGlideClusterClient(api.NewGlideClusterClientOptions())
• The import path is unnecessarily deep (particularly once you consider that Go GA will ship as part of v2): import "github.com/valkey-io/valkey-glide/go/v2/api"

Once you consider that Go GA will ship as part of v2, the current layout requires this usage:

import "github.com/valkey-io/valkey-glide/go/v2/api"

func ExampleClient() {
    api.NewGlideClusterClient(api.NewGlideClusterClientOptions())
}

A more idiomatic way would be the following:

• move client constructors and other entrypoint types/functions up a folder level into https://github.com/valkey-io/valkey-glide/tree/main/go instead of https://github.com/valkey-io/valkey-glide/tree/main/go/api
• update moved files to use package name glide
• remove "Glide" from types/constructors that don't need it

Then typical code looks like this:

import "github.com/valkey-io/valkey-glide/go/v2"

func ExampleClient() {
    glide.NewClusterClient(glide.NewClusterClientOptions())
}

[asafpamzn]

@jbrinkman please see the feedback.

Thanks @marcind.

[jbrinkman]

Thanks for the feedback. This is one of the tasks that I am currently working on. Issue #3334 is meant to address this issue (although the issue description could use some updating to more fully encapsulate the true scope)

[marcind]

Ah, sorry about the overlap, that issue didn't show up in my issue search results for the few keywords I used.

[jbrinkman]

Not a problem. The extra detail and input is much appreciated.

[jbrinkman]

I haven't done the API folder refactor yet, but it is coming. I am currently refactoring purely private code into the internal folder. We have a number of files and code which should not be public but because everything was dumped into API early on, it made any sort of functional structure difficult. We are also aiming to better structure the code so that major features like PubSub don't have to live in the main package. There are a few places where we were able to put some structure in place earlier, like our options models, but other places where that was difficult because so many helper functions lived in API. I should have a PR ready for review early this next week and would definitely welcome your feedback.

[marcind]

That's great. Apologies if I'm pointing out things that are already obvious and planned for. I did notice and appreciate the thoughtful design of the options package which caused me to be confused by some of the untidiness in the api package.

[jbrinkman]

The problem with major refactors is that they can be difficult to do when the project is under daily flux. We have been averaging 2 or 3 PR merges daily, so there hasn't been a good time to do this work. The intent for the past couple of months has been to do this once the 2.0 features were pretty much complete which is why we are just getting to this work.

On a related note, we have a lot of experienced developers working on the Go implementation, but we are not all as well versed on Go idioms or best practices. As a result we appreciate community members who provide feedback on where we can improve, even if it might seem obvious or redundant.

[jbrinkman]

This discussion is addressed in PR #3860