Discussion: Improve view-calls usability

[frol]

This topic is quite high-level and I see several different approaches useful in different situations. Let's consider the problem @ilblackdragon bumped into with the lockup contract:

It is impossible to view the raw lockup_information (there is no method)

The solution at this point is to dump the state (through query("view_state") JSON RPC) and parse it either recreating the Borsh schema in JS [or whichever language you use on the client side], or go completely mad parsing the message without any framework at all byte by byte.

Thus, missing a single method may cast you into a really unfortunate situation.

I see the following solutions:

1. Automatically implement a view method for the whole state on the SDK level for state structure

• Pros:
  • You never end up in a situation like that
  • You can query the latest data all the time (online)
  • There is no complex setup (plain HTTP calls to the JSON RPC)
  • If the state is big, and the response is small, you win
• Cons:
  • The contract size is going to be inevitably bigger even if you don't want to have this feature since you need JSON serialization there (you pay for what you don't use)
  • Every view call is an HTTP request with the latency in response and gas limits on the execution
  • If the state is small, and the response is big, you loose

2. Provide tooling to execute contracts on the client-side (download the Wasm binary from the chain or compile the contract code without change methods and with additional view methods, as Wasm-compiled code can be re-used on the client-side):

• Pros:
  • The deployed contract may be as lightweight as just implementing the change methods (providing the view methods as a separate binary)
  • No limits on the complexity (gas usage is limited on RPC), number, and frequency of view methods (RPC server has to limit those)
  • No RPC latency and outage due to DoS
  • Offline mode once you have the Wasm and the necessary state
• Cons:
  • The code is decoupled from the actual contract, so it might get out of sync
  • If the state is big, you spend more time downloading the state
  • You need the tooling and some runtime context to execute the contract

3. Provide tooling that generates the code in the target programming language to parse the state into some objects (basically, Borsh-to-objects like Illia did in the lookup-contract):

• Pros:
  • The source code is light-weight and only does minimal parsing
• Cons:
  • Too low-level, so anything from near_sdk::collections::* will be just random pieces that you have to match yourself
  • There are tons of "target" languages, and there potentially tons of different near-sdk-* libraries

/cc @evgenykuzyakov @nearmax @vgrichina