search

hyperledger-archives / indy-sdk

indy-sdk
https://wiki.hyperledger.org/display/indy
Apache License 2.0
668 stars 735 forks source link

higher level API #908

Closed AxelNennker closed 6 years ago

AxelNennker commented 6 years ago

Developers have to go through some repetitive code when using libindy.

The pattern is build request, send request, sometimes parse response. Like here: https://github.com/hyperledger/indy-sdk/blob/master/samples/nodejs/gettingStarted.js#L715

These are only small snippets but why repeat them in all applications using libindy?

I heard this several time from different developers adn suggest to move these methods up and expose them in the API (maybe even deprecating the low-level methods?)

vimmerru commented 6 years ago

I believe vcx library that was open sourced few days ago is all about this. As i know there are plans to merge it with libindy.

AxelNennker commented 6 years ago

Not sure if that is what is want. I am not opposed to Typescript but pure nodejs might be easier for many. https://github.com/evernym/sdk/blob/master/vcx/wrappers/node/src/api/proof.ts

So I would still like to hide this boilerplate build, send, parse and like to have that higher level nodejs API.

vimmerru commented 6 years ago

So I would still like to hide this boilerplate build, send, parse and like to have that higher level nodejs API.

Each thier-1 wrapper must provide exactly the same abstraction layer as libindy. It can provide additional interfaces, but it is better to have them outside of indy-sdk repos as we can't support and test a lot of custom code. Some use cases require build be separated from signing and sending and performed in a different process for example.

If you want to change behavior of libindy for better devX and all wrappers consider to raise corresponded HIPE.