GetExchangeCodes is missing from the library

[gcatlin]

https://docs.alpaca.markets/reference/stockmetaexchanges-1

Need to add a new marketdata.Client method.

Two potential approaches:

• call it GetExchanges and return []Exchange (requires a new Exchange entity with e.g. Code and Name fields)
• call it GetExchangeCodes and return map[string]string (with the code as the key and the name as the value)

I prefer GetExchanges but GetExchangeCodes might fit better with the library.

@gnvk what do you prefer?

Example API response body:

{
  "A": "NYSE American (AMEX)",
  "B": "NASDAQ OMX BX",
  "C": "National Stock Exchange",
  "D": "FINRA ADF",
  "E": "Market Independent",
  "H": "MIAX",
  "I": "International Securities Exchange",
  "J": "Cboe EDGA",
  "K": "Cboe EDGX",
  "L": "Long Term Stock Exchange",
  "M": "Chicago Stock Exchange",
  "N": "New York Stock Exchange",
  "P": "NYSE Arca",
  "Q": "NASDAQ OMX",
  "S": "NASDAQ Small Cap",
  "T": "NASDAQ Int",
  "U": "Members Exchange",
  "V": "IEX",
  "W": "CBOE",
  "X": "NASDAQ OMX PSX",
  "Y": "Cboe BYX",
  "Z": "Cboe BZ"
}

[brendisurfs]

@gcatlin I am happy to take this one over if that is ok :)

[gcatlin]

Absolutely. Thanks @brendisurfs!

[brendisurfs]

Rad! Just to confirm, any new structs/types would go in entities.go, correct?

And there could be a solid middle ground between the two ideas too, perhaps a map[ExchangeCode]ExchangeName? Where both the keys and values are typed (using structs as enum-like). That way, you still get the concept of having Name and Code fields, while still being flexible as a map for various use cases.

[gcatlin]

Just to confirm, any new structs/types would go in entities.go, correct?

That's right.

perhaps a map[ExchangeCode]ExchangeName? Where both the keys and values are typed (using structs as enum-like).

I'm not sure what you mean by "using structs as enum-like". Were you thinking of something like this?

type ExchangeCode string
type ExchangeName string

func (c *Client) GetExchangeCodes() (map[ExchangeCode]ExchangeName, error) { ... }

If so, that's equivalent to what I was suggesting for GetExchangeCodes in my first post, though having the types instead of strings may be nicer for type safety.

[brendisurfs]

Yup, seems like we are on the same page!