API / RPC refactor

[snowypowers]

This refactor will split the NeonDB's API methods away from NEO RPC methods, allowing this library to be more flexible and less biased. NeonDB's methods can be seen as examples on how to use NeonJS methods.

RPC

• Exposed as Neon.rpc or import {rpc} from 'neon-js

• RPCClient

  • Class pointing towards a specific NEO node. Instantiate with node URL (optional version can be used to guard against new implementation methods)
  • Has RPC methods implemented using Query class. eg. Client.getBlock(1)
  • Accepts a custom RPC request through Client.query(customRequest).
  • Accepts a custom Query through Client.execute(customQueryObject)
  • Contains history of past queries made, accessed through Client.history

• Query

  • Class to serve as wrapper around request and response.
  • Attach a parser method with parseWith(parsingMethod) to parse the response.
  • Has static RPC methods for quick init. eg Query.getBlock(1) is equivalent to new Query({method: 'getBlock, params: [1]})
  • Quick querying without RPCClient : Query.getBlock(1).execute('https://seed1.neo.org:10332)

API

• Exposed as import {api} from 'neon-js'
• NeonDB
  • Shift all methods for Neon wallet to here.
  • Separation of custom logic from general logic makes the library more readable. (I always mess up getAPIEndpoint with getRPCEndpoint)
  • API folder can contain other APIs from external sources (eg. coinmarketcap for prices?)

[Ejhfast]

Sounds great! One way we might want to generalize API is to give it enough flexibility to support multiple light wallet backends (e.g., maybe neoscan in addition to api.neonwallet). Not to be implemented now per se, but to make such integration easy in future. This would dramatically reduce the probability of the library (and wallet) breaking for end users