Development Tools: Python SDK

[QVidal]

Description

We are looking for teams interested in building SDKs for Accumulate to make it easier for software developers to integrate the Accumulate protocol into their software.

The Python SDK should make interaction with the Accumulate protocol simple and straightforward using the Python programming language.

Requirements

The Python SDK should support all available Accumulate Operations. Please see the Accumulate API Documentation or the CLI Reference for information on the available operations.

Accumulate SDKs should be accessible, consistent, and reliable. The source code should be publicly available and include easy-to-follow and concise documentation.

Build the SDK with the expectation that it will be used in production by other developers. It should be secure, performant, and ready to use out of the box with minimal configuration.

[PraveenMathew92]

So we have to come up with a wrapper on the JSON-RPC API as part of this issue. Correct? Or is there something more that is expected?

[firelizzard18]

For query methods and the faucet, yes. Methods that submit transactions require considerably more work. In order to submit a transaction, the client must sign it. In order to sign it, the client must binary marshal it. For the signature to be valid, the transaction as marshaled by the client must be byte-for-byte identical to the transaction as marshaled by the API.

IMO the best strategy for marshaling is to build a type generator for Python to match the type generator for Go (internal/cmd/gentypes, moving to tools/cmd/gentypes) using the type definitions in protocol/types.yml. We would like to refactor the Go type generator to support other languages, but that might not be in the scope of a hackathon.

I would prefer for the API wrapper to be generated from internal/api/v2/methods.yml, which is added in AccumulateNetwork/accumulate#351. Generating the wrapper will reduce the maintenance burden as we update the API.

[PraveenMathew92]

Sorry, am not able to find internal/api/v2/methods.yml is internal/api/v2/types.yml what you meant?

[firelizzard18]

The PR hasn't been merged yet. Here is the current version in the PR.

[PraveenMathew92]

Thanks @firelizzard18. I have stated working on it. Here is a sample of the wrapper json_rpc_client.py. Also have written the tests for the same here.
Please let me know if this is what is expected.

[firelizzard18]

@PraveenMathew92 Generally, yes. However, I recommend using types.yml to generate data types. If you do that and use the equivalent of a switch statement on result['type'], you can unmarshal result['data'] directly into the appropriate data type.

[firelizzard18]

AccumulateNetwork/accumulate#351 has been merged

[PraveenMathew92]

Sure @firelizzard18 . I have been going through the types.yml and the methods.yml.

Is there any schema like the Open API Specification that you follow for the ymls?

I want to know what all data types to expect and in general how are the ymls structured.

[firelizzard18]

types.yml and methods.yml do not have any schema beyond the implicit contract of the Go types they are unmarshalled into, which now live here. These are designed specifically for our needs; I have no intention of conforming to an external schema. We can discuss creating a custom schema.

Some of the fields in types.yml are fairly Go-specific: marshal-as, pointer, keep-empty. Perhaps we should rename slice to element-type. The field type names could definitely be cleaned up.

output in methods.yml is not well developed. That needs to be expanded into something closer to a JSON schema. Ultimately, I want to use methods.yml and types.yml to generate OpenRPC and OpenAPI specs.

[ratnesh93]

Do we have implement only endpoints mentioned in the https://docs.accumulatenetwork.io/accumulate/developers/api/api-reference ?

[firelizzard18]

@QVidal do you have an answer for @ratnesh93's question?

@PraveenMathew92, in this MR on GitLab, I've refactored the type generator to use the Go template language instead of everything being hard coded. This may make it easier to follow. Long term, I would like to have a template for every language we have an SDK for, so that the marshallers are all generated by the same generator.