Skip to content

Latest commit

 

History

History
99 lines (71 loc) · 5.37 KB

aip-42.md

File metadata and controls

99 lines (71 loc) · 5.37 KB
Raw
aip title author discussions-to Status last-call-end-date (*optional) type created updated (*optional) requires (*optional)
42
Aptos TypeScript SDK V2
0xmaayan
Draft
Standard
07/07/2023

AIP-42 - Aptos TypeScript SDK V2

Summary

This AIP introduces the development of a new version for the Aptos TypeScript SDK.

Motivation

We have embarked on the development of a new version for our TS SDK due to several significant issues that have been identified in the current version. The current version suffers from problems with its overall structure and design, which has hindered the efficiency and effectiveness of its usage. Moreover, there have been inconsistencies in the naming conventions and types used within the SDK, leading to confusion and decreased productivity among developers. Furthermore, the existing SDK client support lack of customization, limited support for advanced client features and making debugging and troubleshooting more challenging.

Ultimately, these issues have collectively resulted in a less than optimal development experience for our users. Therefore, the new version of the SDK aims to address these problems and provide an improved, streamlined, and more user-friendly development experience for developers.

Impact

The new version would be under a release tag ^2.0.0. TS SDK users that upgrade their package to this version will need to make code changes to be compitable with TS SDK V2. The current and existing ^1.x.x version will be available to use but will not get new features.

Specification

The changes are:

  1. Usage - Introduce a global AptosConfig config file as a convenient and flexible way for end users to configure and customize a project without directly initalize different classes in the SDK. This reduces the chances of introducing errors and simplifies maintenance. It also makes it easier to share and distribute project configurations across different environments
class AptosConfig = {
  readonly network: string;

  constructor(config: AptosConfig){
    this.network = config.network ?? DEFAULT_NETWORK
  }
}

class Aptos {
  readonly transaction: Transaction;
  readonly account: AptosAccount;

  constructor(settings?: AptosConfig){
    this.config = new AptosConfig(settings);
    this.transaction = new Transaction(this.config)
    this.account = new AptosAccount(this.config);
  }
}

// Usage
const settings: AptosConfig = {
  network: Network.DEVNET,
};

const aptos = new Aptos(settings);
const transactions = await aptos.transaction.getTransactions()
  1. Client - Currently all client requests are under AptosClient or IndexerClient class and the Provider class that extends both classes. As we keep adding more and more requests to both classes they get huge and confusing. Moreover, the end user shouldn't care or know what service is used to execute the request and don't need to figure out what class to use. We will deprecate both classes and get each request to a relevant file/context. For example, all transaction requests will be under a Transaction interface that holds operations related to a transaction (read/write).
const transactions = await aptos.transaction.getTransactions();

  1. Types - The SDK encompasses a diverse range of types utilized for the representation of objects, requests, and responses. However, the current method of defining these types within the SDK has proven to be confusing. The inclusion of both types generated by a server schema and locally defined, such as Types and TxnBuilderTypes, has contributed to this confusion. Furthermore, there is room for improvement in the naming conventions for these types, such as introducing more descriptive and intuitive names other than MaybeHexString.

  2. Generate Transaction Payload - TS SDK provides feature plugins where users can simply call and submit a transaction by passing in expected arguments. This is a bit difficult to wallets where they first need to generate a transaction, simulate and then sign+submit it. For feature plugin classes, define a class with static functions that accept related function arguments and return a transaction payload that can be used to generate a raw transaction and simulate/submit to chain.

const createCollectionPayload: TransactionPayload = AptosToken.generateCreateCollectionPayload(...);
// simulate
const rawTransaction = aptos.transaction.generateRawTransaction(createCollectionPayload)
const txn = await aptos.transaction.simulate(sender, rawTransaction)
// submit
const rawTransaction = aptos.transaction.generateRawTransaction(createCollectionPayload)
const signedTransaction = aptos.transaction.sign(sender,generateCreateCollectionPayload)
const hash = await aptos.transaction.submit(signedTransaction)
  1. Log Service - By providing support for a log service within the SDK, we empower developers with a powerful tool to enhance their application's performance, troubleshoot issues, ensure compliance, and deliver a more robust and reliable software experience to end-users.
  • Print full stack trace
  • Support different log types (info, warning, error, debug)
  • Support a switch to disable/enable logging

Risks and Drawbacks

  • TS SDK version ^1.x.x will not get new features.
  • Existing users that upgrade to the new version would need to make code changes to be compatible with the new version.

Testing

TS SDK test suite