Stateful Client Libraries: Part 1
Update: This library is deprecated with the Chrysalis network upgrade. The rust libraries will be more heavily maintained. Documentation can be found in our latest docs.
Today, we are officially releasing the beta versions of our new stateful client libraries, which contain what we call an ‘Account module’. The name does not do justice to what is a very substantial update, so we will try to summarize the changes in the two blog posts we will be releasing about the libraries. This post is part 1.
Client libraries have always been an important part of the puzzle when building applications on top of IOTA. They are designed to make implementing your ideas simpler, in the language of your choice.
The IOTA Foundation has been maintaining Java, JavaScript, and Golang versions of client libraries for quite some time now. And while we see you building great things using the libraries, we were always aware that they are far from the ideal developer experience that we would like you to have.
A couple of months back we set out to redesign the client libraries completely and try to abstract away as many complicated operations as possible. So that developers would only have to care about what they really care about: sending transactions and receiving transactions. All without the complicated bits and pieces that require an in-depth knowledge of the IOTA protocol.
Previously when working with our client libraries, developers had to implement many components themselves from scratch. This required an advanced knowledge of many IOTA concepts. For example, you had to be quite intimate with:
- Transactions
- Bundles and how to construct them
- Knowing which addresses are safe to use for a deposit and which can be used for input selection
- Promotion and re-attachment of pending transactions
- and much more
As the client libraries had no state, the developer had to manage or fully rely on the network. Even operations like getting transaction data required a network call, and the pruning of old ledger data by snapshots had to be taken into account.
All this made building on top of IOTA unnecessarily complicated. The upfront investment you had to make before being able to send a transaction was a real issue.
Especially when you wanted to experiment with simple applications on top of IOTA.With the new libraries however, most of the low-level aspects are abstracted away.A developer can create an account and start sending and receiving transactions with much less effort.
The new client libraries store the account information locally, removing the need to call nodes for information like address state or balances. They are also resilient to snapshots. The libraries now:
- Store the account information and settings locally. You can also export and import existing accounts.
- Store pending transactions locally.
- Handle the promotion and reattachment of pending transactions via a predefined strategy. You can also define your own strategy. The reattachment and promotion functionality is supported via a plug-in and you can develop your own plug-ins that extend the library functionality.
- Have a notion of which addresses from your account have been deposited to and spent from, and which should be used for input selection. So whenever you request a deposit, you are doing so in a safe manner.
- Provide event handling functionality. You can now listen out for different events, for example every new deposit, or every confirmed, outgoing transaction.
- Introduce a concept ofConditional Deposit Addresses (CDAs), which are now the primary means of communicating with depositors. This is a very important feature which we will expand on in the next post.
You can read more about the client libraries in our documentation. Or get the libraries from their respective repositories:
See part 2 of this post.