Enabling a custom client for Algod and Indexer #477
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently the only way for a dApp to use the SDK with an API service is to know the URL and token of the API service. This prevents dApps from using API services / algod / indexer provided by the user or by a wallet such as AlgoSigner. In particular: * When using a wallet such as AlgoSigner, a dApp either need to manually serialize data and write path for endpoints (https://github.com/PureStake/algosigner/blob/develop/docs/dApp-integration.md#algosigneralgod-ledger-mainnettestnet-path-algod-v2-path--) or need to not use at all the provided API service. * A user cannot use their preferred (potentially more trusted) API service / algod / index / API services * A dApp cannot easily connect to a private network of the user (See also algorandfoundation/ARCs#8 for more details on wallets and discussion around them.) The goal of this PR is to allow the above scenarios. It does so by introducing an intermediate interface `BaseHTTPClient` and to allow to construct `Algodv2Client` and `IndexerClient` from such a `BaseHTTPClient`. A `BaseHTTPClient` is minimal: it does not perform any serialization/de-serialization, does not fix `accept` headers, does not even try to utf8-decode strings. Its only purpose is to execute directly REST queries and return the raw responses. `BaseHTTPClient` is meant to be stable over releases of algosdk.
jasonpaulos
reviewed
Dec 3, 2021
|
Thanks! I've done all the proposed changes. |
fabrice102
added a commit
to fabrice102/ARCs
that referenced
this pull request
Dec 7, 2021
From algorandfoundation#8 with the following changes: * use of `genesisID`/`genesisHash` instead of `network` for `enable` * enforce main networks' hashes from genesisID * allow `enable` to return no account for just access to blockchain * support of list of group of transactions in posting * clarify error handling in many cases * add security considerations in many places * add optional `signTxns` and `postTxns` to wallet standard * clarify requirements for confirmation when posting transactions * use `BaseHTTPClient` from algorand/js-algorand-sdk#477 for `getAlgodv2Client` and `getIndexerClient` * other minor changes Main points to discuss: * splitting the error standards out of ARC-0001 and make it a living standard * allow optional argument to post without waiting for confirmation (dangerous)
This was referenced Dec 28, 2021
aldur
pushed a commit
that referenced
this pull request
Jan 20, 2022
* Enabling a custom client for Algod and Indexer Currently the only way for a dApp to use the SDK with an API service is to know the URL and token of the API service. This prevents dApps from using API services / algod / indexer provided by the user or by a wallet such as AlgoSigner. In particular: * When using a wallet such as AlgoSigner, a dApp either need to manually serialize data and write path for endpoints (https://github.com/PureStake/algosigner/blob/develop/docs/dApp-integration.md#algosigneralgod-ledger-mainnettestnet-path-algod-v2-path--) or need to not use at all the provided API service. * A user cannot use their preferred (potentially more trusted) API service / algod / index / API services * A dApp cannot easily connect to a private network of the user (See also algorandfoundation/ARCs#8 for more details on wallets and discussion around them.) The goal of this PR is to allow the above scenarios. It does so by introducing an intermediate interface `BaseHTTPClient` and to allow to construct `Algodv2Client` and `IndexerClient` from such a `BaseHTTPClient`. A `BaseHTTPClient` is minimal: it does not perform any serialization/de-serialization, does not fix `accept` headers, does not even try to utf8-decode strings. Its only purpose is to execute directly REST queries and return the raw responses. `BaseHTTPClient` is meant to be stable over releases of algosdk. * improvements followging review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently the only way for a dApp to use the SDK with an API service is to know the URL and token of the API service.
This prevents dApps from using API services / algod / indexer provided by the user or by a wallet such as AlgoSigner.
In particular:
(See also algorandfoundation/ARCs#8 for more details on wallets and discussion around them.)
The goal of this PR is to allow the above scenarios.
It does so by introducing an intermediate interface
BaseHTTPClientand to allow to constructAlgodv2ClientandIndexerClientfrom such aBaseHTTPClient.A
BaseHTTPClientis minimal: it does not perform any serialization/de-serialization, does not fixacceptheaders, does not even try to utf8-decode strings. Its only purpose is to execute directly REST queries and return the raw responses.BaseHTTPClientis meant to be stable over releases of algosdk.