Inconsistent strategies for managing options when creating new client instances

[ndewet]

NewClient in alpaca/rest.go accepts a ClientOpts struct, where as NewStocksClient in marketdata/stream/client.go accepts a variadic list of stock options.

NewClient:

	key, secret, err := GetAlpacaCredentials()
	if err != nil {
		return nil, err
	}
	market := alpaca.NewClient(
		alpaca.ClientOpts{
			APIKey:    key,
			APISecret: secret,
			BaseURL:   "https://paper-api.alpaca.markets"},
	)

NewStocksClient:

	key, secret, err := GetAlpacaCredentials()
	if err != nil {
		return nil, err
	}
	processors, err := GetProcessorCount()
	if err != nil {
		return nil, err
	}
	stocks := stream.NewStocksClient(
		marketdata.IEX,
		stream.WithBufferSize(1000),
		stream.WithProcessors(processors),
		stream.WithCredentials(key, secret),
		stream.WithReconnectSettings(0, 500*time.Millisecond),
		stream.WithLogger(&AlpacaStreamLogger{}),
	)

Please note that WithCredentials and APIKey + APISecret are just different enough to cause confusion.

I by far prefer the variadic list approach.

[ndewet]

In the land of dreams and ideas, I'd like an approach where some of the option types, such as credentials, were re-usable across different client types.

[gnvk]

@ndewet You are absolutely right, this duality is indeed unfortunate. Honestly, I'm not sure if it's worth the effort to fix this though. That being said, I'll list some suggestions if we / anyone ever wants to pick this up:

• This can be fixed in a backward-compatible way by adding new constructors for the non-stream clients, e.g. alpaca.NewClientWithOptions().
• The difficulty with using the same option types is that we have 3 packages (alpaca, marketdata and stream). Probably the best way to cope with this would be to define the base option type and any common options (e.g. WithCredentials) in the alpaca package and use them in marketdata and stream.