Skip to content

Latest commit

 

History

History
29 lines (21 loc) · 2.56 KB

TODO.md

File metadata and controls

29 lines (21 loc) · 2.56 KB

TODOs

  1. Using Data Class to classify JSON response dynamically. Upside: immutable, better performance (maybe?), less work. However it may be best for objects to be explicitiy defined. Can punt this for now. Ideally CoinBase has a standardized API manifest that can be pulled so objects can be autogenerated.
  2. separate JWT logic as mixin / concern?
  3. need someone to help test perpetual resource endpoints
  4. yard documentation of endpoints would be nice
  5. support sandbox mode
  6. make logger "globally" accessible. @config.log("abc", :info)
  7. keep constants.rb ?
  8. Docker devcontainer would be nice
  9. move test.rb to examples directory
  10. Meditate on and finalize base_response <-> rest_base design 14b. Handle HTTP statuses (2xx - 5xx) appropriately with hints to user especially 4xx, 5xx responses.
  11. Security audit: Oauth2 support (assuming it works with Advanced API) will have to be built on top of wrapper as it requires browser + JS. Mimicking all of that from command line will be a pain in the ass.

DONE

  1. substitute puts with logger + debug / verbose mode generally

Done-ish. The prints have been removed, verbose mode is configurable, but still need to (intelligently) pepper in additional debug logging.

  1. Would be nice to have helper function for futures to see whether futures market is open or not (hopefully coinbase provides one at some point). Otherwise up to SDK user to query + cache product endpoint for open status. Maybe beyond scope of API wrapper?
  2. For orders: include helper methods for market / limit orders? or beyond scope of wrapper?

^ executive decision is it is beyond scope. helpers / concerns / decorators / whatever will be contained in separate repo / gem.

  1. following TODO #2, need to make executive decision regarding namespacing resources, "orders" being the main culprit as some methods are ambiguous. e.g. - due to being rails-brained - "get_orders" redundant vs just "orders". but then under rails paradigm create_order is also redundant (GET:order vs POST:order). not to mention coinbase API reference using "GET", "LIST", "CREATE" kinda loosely is ... annoying. aliasing methods for now to avoid existential crisis and coding paralysis.

^ Executive decision: to avoid confusion go full explicit and map 1:1 with API reference. No aliasing. Coinbase already achieved a mind-boggling level of incoherence between endpoint namespacing, verbiage, and mapping endpoint names to API reference that - although I almost feel an obligation to in the spirit of coinbase - I will spare the brave souls using this library the additional layer of complication.