Collect feedback about SDK

[shumkov]

We want to collect your feedback on using RS SDK / DPP in one place for our upcoming work to improve user experience. Please share your feelings, pain points, places you like, “nice to have” things, and other suggestions. Thank you!

[shumkov]

From @HashEngineering

Some things were or are missing from rs-sdk:

• Replace document
• Delete document
• Core endpoints such as get_transaction
• get status endpoint

The API is simple with a common interface for all queries and for submitting state transitions (though the client doesn't need to consider state transitions but instead identities, documents, data contracts and votes)
the fetch and fetch_many methods work quite well and have _with_settings variants to allow the client to specify their own request_settings for different retry parameters.
The Put* interfaces are missing some things. In my system, I prefer a put_to_platform and a wait_for_result method rather than a single method that does both. The reason for this is that I want to wait on several different EvoNodes to return the state transition result. I found this to ensure that the state transition was propogated during the username creation process which requires putting an identity, then two documents and in some cases, retrieving the vote information on contested domain documents.
Even for put_to_platform , I have some extra retry that I have added to handle the cases of bad nodes. Previously on testnet, I encountered EvoNodes that said the dpns contract did not exist. In such cases, I would need to try again with a different EvoNode. The ban features in the Sdk are hidden, so the client cannot ban such nodes. Perhaps this could also be resolved with other checks in the SDK or dapi-cleint to retry. Not sure if this happens anymore; it was first discovered with Platform 1.1 or 1.0 on testnet -- it may not happen anymore.

[shumkov]

From @QuantumExplorer

Generics for fetch and fetch_many are a bit tricky because you don't know what to pass, and you don't have autocomplete for this.

[shumkov]

@lklimek :

On my side, the data model (aka dpp needs some review / tidying up. Of course these are strongly opinionated, I'm open to your opinions. Examples:
There should be only one type for various stuff, for example ExtendedEpochInfo should be renamed to EpochInfo. Same applies to other types, like Document/ExtendedDocument, Contender/ContenderWithSerializedDocument, ... - we should only have one type, others should be hidden unless someone uses some low-level crate / separate feature.
Types should be self-contained, I mean - to put a Document, you should only provide the Document. Of course there must be some way to mark dependencies between Document, document type and DataContract - not sure how, but current approach is hard to use.
implement serde (as per API guidelines) and then derive our encoding from it if possible
documentation of DPP
2. In terms of DAPI, we should also have REST responding with JSON for proof-less mode; that will make debugging much easier.
3. In SDK , we might try to unify all the Put traits somehow, I didn't think about details.
4. SDK should handle all the asset locks, etc., internally. I should just do Identity::create(amount) and it should do the job. We might give an option (builder pattern?) to specify additional params, but basic approach should be as above.
5. It means SDK MUST be integrated with some kind of wallet, to be able to sign and exec txs on both L1 and L2, so that the hello world example that creates an identity with some registered name and sends some funds takes just a few screens.
6. We should have much less features in Cargo.toml. Like max 5 per crate. Otherwise nobody will understand them and will simply use full.
7. We need separate versioning of Sdk and DPP (and whatever we see as "public API"), to let us notify on breaking changes.
8. Bindings to JS and other technologies. Not sure if it even makes sense (how big will be a JS SDK created with bindings be?)