Roadmap - 3.0.0

[OrahKokos]

Why?

Main reason: Design flaw.
Rational: Currently this lib is being used to communicate with Coinpayments API server. This communication is done via nodejs native module (https) and this is the fatal flaw. This lib has opinionated in HOW we communicate, but its scope should be WHAT we communicate. When we are writing production ready software it is not uncommon to have a pre-configured agent that the project in question WANTS to use, this use case is denied by the current implementation.
By removing the API call itself from this lib, this would open the door for custom agents where projects can implement metrics/logs with more ease. This is usually an important topic around business ops.

What to expect

Goal: Curried functions with constructed payload.
Rational: Currently this lib has a very outdated code style, it was written back-in-the-day, when tools were not as good as today. The standard class OOP approach works well enough for 95% of the use cases. The use case which is not taken into account is when projects have N merchant accounts. Given that a project is managing N accounts it becomes cumbersome to initialize each object for each merchant, even if we might only need 1-2 method calls from merchant X, and 5-6 from merchant Y... so on.
If the lib changes to a curried function style, all use cases can be met.

TL;DR

From 3.0.0.

• This lib will only construct HTTP request payload based on input. So payload, headers, HMAC...
• This lib will provide curried functions instead of object methods. (credentials) => (...options): CoinpaymentsHTTPStuff
• Calling of the API itself is expected to be done OUTSIDE of this lib.
• Error handling is expected to be done OUTSIDE of this lib, however the lib WILL provide helper functions isCoinpaymentsError(response).

TL:DR EXTRA

• Essentially this will become a coinpayments-api-toolbelt lib.