Future of this SDK

[RomainLanz]

Hey there! 👋

It is very hard (and nearly impossible in crypto-land) to write an isomorphic library.

I plan to rewrite some of the dependencies of the SDK in a better isomorphic JavaScript, and I was wondering how to make it easier to work with new frontend-building tools with this SDK.

As you may know, a bunch of dependencies is node-dependent. So the builder polyfill them during the build, but this is not working well with all bundler's new version (Webpack 5, Vite, Rollup, ...).

Instead of creating an isomorphic library, I thought, what do you think about creating three libraries?

• @terra-money/core => Common isomorphic part of the SDK
• @terra-money/sdk => Node part of the SDK
• @terra-money/client => JavaScript (Client) part of the SDK

People would choose to use the Node or the Browser version of the SDK, depending on their runtime.

This will not be easy to achieve well.
I have opened this issue to start discussing doing something similar in the "near" future.

[jkhaui]

Hey,

I think that's a great idea. I can tell you a bit about my experience writing a client-side library (which should be ready for an experimental release soon) based off the Terra.js SDK, including some pain points experienced. (I don't think these pain points are specifically related to a node/browser environment).

My initial goal was to create a basic React app (or dApp?) with basic functions like rendering a list of users' stablecoin balances in their wallets. This proved cumbersome as it involved calling the coins.toData(), coins.toString() methods, etc. and then again converting and formatting the resultant balances from strings to numbers.
Then I realised there were many other situations to account for, such as users' balances not being updated unless a refetch query was sent to the Terra endpoint. Eventually I concluded that the only possible way to show such "real-time" updates was to poll the Terra endpoint every 6 seconds.
At this point I basically decided to write an React + RxJS wrapper library over the Terra API to handle all the complex async logic. It actually works quite nicely, but I'm wondering if some of this functionality couldn't be handled by the API itself.

I think proper websockets support would be amazing. I know it's included in the SDK, but judging from the lack of documentation/examples I'm guessing it's not production-ready yet? It'd be great if there was a ws node hosted somewhere too; it's too much overhead for me to try and run it locally.

Finally, I'm only interested in the client SDK so not sure if I can offer much advice... But perhaps a yarn workspaces monorepo is the way to go for an isomorphic library. Similar to how the Anchor web app uses workspaces. Except you'd have a clearer distinction between client, node, and shared modules.

[jkhaui]

Another random discussion point: it took me a while to realise that the Coins object returned by the API is in a Decimal format created by the library Decimal.js. I feel that this could have been better documented, especially as some devs (like myself) may opt for other BigNumber libs (I chose big.js b/c of its smaller size).

Also, I wonder if Decimal.js is the best choice for the terra.js SDK as it relies on significant digits for arbitrary precision arithmetic, as opposed to big.js, bignumber.js, etc. which express precision in decimal places. I believe the latter are better suited for finance-related apps (but this isn't my area of expertise and is probably for another discussion).

[decryptdavid]

I have to say the use of Decimal.js caught me out on this SDK, I'm far more familiar with BigNumber.js from looking at other crypto projects and BigNumber seems to be somewhat more popular than Decimal in terms of the dependant libraries on NPM ~4,000 for BigNumber.js vs ~1,000 for Decimal.js, however Decimal seems to have just over double the weekly downloads which is interesting.

https://www.npmjs.com/package/bignumber.js
https://www.npmjs.com/package/decimal.js

I'd be interested in helping with any work on this library, right now I'm just looking to help increase the test coverage across the library during my free time, since it's a good way to learn more about the specific use cases.

[PFC-developer]

hey .. @jkhaui @RomainLanz @decryptdavid .. can you see yourself doing this full time?

(ie.. working on SDKs for TFL I mean.. not this patch)
can you email me ? PFC-Validator @ Protonmail.com (I am a member of TFL.. but don't want my work email out here)

we'd love you doing this more ;-)

[0xslipk]

Hey there! 👋

It is very hard (and nearly impossible in crypto-land) to write an isomorphic library.

I plan to rewrite some of the dependencies of the SDK in a better isomorphic JavaScript, and I was wondering how to make it easier to work with new frontend-building tools with this SDK.

As you may know, a bunch of dependencies is node-dependent. So the builder polyfill them during the build, but this is not working well with all bundler's new version (Webpack 5, Vite, Rollup, ...).

Instead of creating an isomorphic library, I thought, what do you think about creating three libraries?

• @terra-money/core => Common isomorphic part of the SDK
• @terra-money/sdk => Node part of the SDK
• @terra-money/client => JavaScript (Client) part of the SDK

People would choose to use the Node or the Browser version of the SDK, depending on their runtime.

This will not be easy to achieve well. I have opened this issue to start discussing doing something similar in the "near" future.

Hi @RomainLanz from a developer perspective. I think is a good idea to have others SDK out there (like in Ethereum we have ehters and web3). Let me know if you need help with this. I know very well terra lcd and tendermint mechanisms, so I can help you to build this new SDK. :D

Send me a message on twitter, my handle is @jarcodallo.