Update Go client miniflux.app/client to allow options and to pass context.Context?

[kellegous]

Hey folks,

I'm starting to use the Go miniflux.app/client module to build on the API of my miniflux instance, but I'm missing a couple of things and I'd like to add them. Curious to hear any reservations.

First, I would like to be able to pass an http.Client to the client. This allows me to keep track of some metrics and it's also pretty common for Go clients. In order to do this, I was considering using the common functional options pattern. So we would end up with a function like,

func NewClientWithOptions(endpoint string, auth Authentication, options ...Option) *Client

and the common usage would be

client := miniflux.NewClientWithOptions(
  "https:https://api.example.org",
  miniflux.WithApiKey("my-secret-token"),
  miniflux.WithHttpClient(myClient))

I would also update NewClient to call this new function under the hood.

Second, I'd like to be able to have a proper context.Context for each of the methods on Client. This is very common in Go clients, of course, and it enables the usual benefits of having a context, including finer grained control of timeouts.

In order to do this, I'm proposing that we add a *Context variant of every method that takes in a context.Context as the first parameter. For instance,

func (c *Client) Feeds() (Feeds, error)

would get a sibling method,

func (c *Client) FeedsContext(ctx context.Context) (Feeds, error)

In fact, Feeds would now be implemented as,

// Feeds gets all feeds.
func (c *Client) Feeds() (Feeds, error) {
	ctx, cancel := withDefaultTimeout()
	defer cancel()
	return c.FeedsContext(ctx)
}

I have started a branch with these changes but since it ends up being a reasonably sized diff, I wanted to reach out before I get too far.

[fguillot]

Sounds good. Maybe start with a small pull request. Avoid breaking changes if possible.

[kellegous]

Sounds good. I currently have a sizeable PR (yet to be posted) that includes the changes I describe plus a test for Client, since WithHttpClient makes Client testable. I'll probably upload the entire pull request, but I can break it up into smaller PR's if needed. It's fairly big, but also very repetitive.

Also, there should be no breaking changes, the old methods are easily implemented/supported using the new ones.