Tstron by STerliakov - TypeScript Tron SDK

[suterliakov]

Project Name: TsTron
Project Track: Web3
Team Name: working solo
Team Member(s): sterliakov
Project Goal: Provide blockchain developers with access to more recent technology compared to plain Javascript, allowing new projects to benefit from type checking usage.
Project Info: Submission video
Project Websites: Home page (repository), NPM package, Devpost submission

Project Test Instructions

I’d just put “N/A” here, but let’s expand this: to test my project, do whatever you’d like to do using it! If you were using Javascript SDK before, then you can now start migrating to typescript. Also this project is tested by automated CI pipeline, runs of these actions can be seen in the repo under “Actions” tab. You can pick something from the test suite as a reference.

Project Details

TsTron was developed as a fork of TronWeb Javascript Tron SDK, converted to add type information. I decided not to go *.d.ts-way, because the original library is not actively maintained, and there is enough to improve in implementation. A few bugs were discovered and fixed in TsTron (these fixes will be backported to TronWeb soon). As of writing this, the capabilities of TsTron are exactly the same as capabilities of TronWeb interface, and the overall interface remains very close to the old one. To ensure type correctness, all types for endpoints responses and other data structures are created based on protobuf definitions, which are actually used by API implementations.

I can confidently say that current library state is cleaner than in was - and this was one of my primary goals. Also, in my opinion modern CI&CD pipeline is important for every library and package, so all tests and builds are performed on github and visible to all users.

This project may serve as (hopefully, almost correct) alternative to the non-existent Tron HTTP API documentation, allowing at least to find out what do the endpoints expect and return.

Also, I refactored some existing code, removing some duplications. This reduced the bundle size for 15%.

Project Milestones

My aim for the hackathon period was to create a working implementation that passes all pre-existing tests and compiles successfully, and make it available to the end user as an NPM package.

Future development steps include improving test suite (and the code coverage as a consequence) and adding first-class gRPC endpoints support.

[tronpulse]

Really welcome developers tools project on Tron!

[Carlunbingo]

Estaré siguiendo este proyecto a ver cómo le va

[Veeno]

It’s look like a great tool for developper !

[Yunik]

Nice project, keep up the good work

[constantinpricope201]

@suterliakov

e to the old one. To ensure type correctness, all types for endpoints responses and other data structures are created based on protobuf definitions, which are actually used by API implementatio

A lot of work on your project. I did not understand what do you mean by protobuf and how this checks works.My project interaction/frontend was build using typescript,I found a very intresting open project on github https://github.com/justfoundation/defi-widgets.

So to sum up the difference is that you implemented tronweb in typescript and add the CI&CD tests
?

[suterliakov]

Protobuf is an interface description language developed by Google (full name - Protocol Buffers), which allows a language-agnostic definition of messages in requests/responses or other exchange scenarios. Tron maintains them (here) for gRPC (I assume), and HTTP JSON API has similar structure (unfortunately, not 1:1). I converted that files to TypeScript (converters exist for many languages) and then applied some manual modifications to make them match the actual API behaviour. This allows for robust checking of the library code: I can verify that messages built and sent to the API match an external implementation.

Yes, you’ve got the main difference right: this project is basically a re-implementation of an existing library in TypeScript with bugfixes and CI&CD pipelines. However, there’s more on the roadmap, because gRPC support is really a must.

[constantinpricope201]

@suterliakov

Future development steps include improving test suite (and the code coverage as a consequence) and adding first-class gRPC endpoints support.

So as an overview protobuf is a structure API let’s say ?

What are the advantages of using your library instead of tronWEB? Statistically do you know the difference in performance?

Did you get in touch with them(TRON) to confirm/infirm if such implementation exists?

[suterliakov]

Yes, it’s basically a way to declare API structure. Here’s a short extract:

message BlockBalanceTrace {
  message BlockIdentifier {
    bytes hash = 1;
    int64 number = 2;
  }

  BlockIdentifier block_identifier = 1;
  int64 timestamp = 2;
  repeated TransactionBalanceTrace transaction_balance_trace = 3;
//  BlockIdentifier parent_block_identifier = 4;
}

message AccountTrace {
  int64 balance = 1;
  int64 placeholder = 99;
}

message AccountIdentifier {
  bytes address = 1;
}

message AccountBalanceRequest {
  AccountIdentifier account_identifier = 1;
  BlockBalanceTrace.BlockIdentifier block_identifier = 2;
}

message AccountBalanceResponse {
  int64 balance = 1;
  BlockBalanceTrace.BlockIdentifier block_identifier = 2;
}
service Wallet {
  rpc GetAccountBalance (AccountBalanceRequest) returns (AccountBalanceResponse) {
        option (google.api.http) = {
      post: "/wallet/getaccountbalance"
      body: "*"
      additional_bindings {
        get: "/wallet/getaccountbalance"
      }
    };
  };
  ...
}

The main advantage is using more modern Typescript instead of plain old Javascript - so the developers who can benefit from type checking in their projects or are just more used to Typescript can go their way with SDK support (and probably IDE feedback). There should be no noticeable performance difference, TS source compiles to relatively similar JS. However, I achieved approx. 15% bundle size reduction, so this may be helpful for plain JS users too - and don’t forget about bugfixes (including completely non-working code - the link points to undefined symbol that raises on run time).

I didn’t notify Tron yet, but I’m planning to do so when gRPC support is live. I’d definitely like my project listed somewhere as a community-maintained TS SDK. I didn’t ask Tron about existing implementations, but I conducted my own research and I think it’s fairly enough. There is one project trying to add .d.ts definitions, but it contains just a bunch of outdated definitions containing any types only (tronweb-typings) and has its repo deleted.

[constantinpricope201]

I was saying that because I found that the documentation in Chinese is different that that in English. It still could be some WIP for them though doubtful. This is a infrastructure project and adding gRPC it look like you have to do some manual work and it looks like many hours should be spend on that and maybe a question on their discord server might help you not to invest to much time in vain.

As bugfixes I would expect to see a pull request to tronweb repo as I cannot fallow you exactly what fixes you made.

Anyway more work than I would expect for this project and I would consider this an infrastructure project rather than an MVP and I really think you should get awarded as such.

Thanks a lot for all the responses!
Keep up the good work!!

[Mattylegend]

This project would serve as a great tool for developer nice project

[Nana66419]

Congratulations, the community believed in you. Keep building and i hope this will atleast serve as a motivation.