Versions Compared

Old Version 3

changes.mady.by.user Eric Butz

Saved on

compared with

New Version Current

changes.mady.by.user Eric Butz

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

tl;dr

I recommend creating a non-backward compatible fiosdk_typescript V2.0 that includes:

  • A refactor of the Typescript SDK to use push transaction - https://fioprotocol.atlassian.net/browse/BD-2121

  • Centralize the getters

  • Transaction centric approach

  • Removal of the mock server parameter from the SDK constructor and make it an optional parameter - https://fioprotocol.atlassian.net/browse/BD-2206

  • Move from a separate copy of eosjs to a fork of eosjs to make it easier to merge upstream changes from eosjs. We would then review commits and do regular merges from eosjs when we do fiojs release.

Overview

We have received feedback from integrators and have experienced development and deployment issues with the current SDK architecture. These include:

  • Mycelium is concerned with the number of 3rd party libraries included with our Kotlin SDK.

  • The use of custom endpoints in the SDKs creates the need to continuously upgraded the SDK when new FIPs are rolled out. This will make ongoing maintenance difficult.

  • Both Edge and Shapeshift have asked for access to the intermediate transaction structures (signed transactions, packed transactions, etc.). This is useful if a wallet wants to re-submit transactions that fail.

  • Documentation for the SDKs is somewhat flat. We would like to make this more of a user-experience based approach that walks integrators through the steps of integrating different features.

  • Documentation for SDKs emphasizes the individual API endpoints. We would like to update the SDK to use push_transaction instead of the individual API endpoints. We may also want to just use push_transaction in general.

  • Possibly reduce the number of calls needed by integrators by aggregating actions in a single call in the chain code.

API signed transactions

One release concern is the need to continually update the chain plugin when adding new transaction endpoints. It was suggested that it might be possible to have a "redirect" that sends all signed transactions to a generic function that unpacks the parameters and forwards it to the appropriate push_transaction contract action.

See the following for a discussion of using individual API endpoints versus a single endpoint: Individual API endpoints versus single endpoint

API getters

Currently it is necessary to update the chain code every time a new getter API endpoint is added. It is an open discussion as to whether it would be possible to refactor and simplify the getter code to enable adding new getter API endpoints without having to update the chain code.

Proposed Changes

Push Transaction

Mock Server

I do not think any integrator is using this mock server option and it is a bit confusing. The only reason we have not removed it sooner is that it is a breaking change.

Fork eosjs

  • Move from a separate copy of eosjs to a fork of eosjs to make it easier to merge upstream changes from eosjs. We would then review commits and do regular merges from eosjs when we do fiojs release.

Several options were discussed with Jimmy regarding the different options for minimizing the pain of keeping up with eosjs and eosjs-ecc changes. We also reviewed other forks of eosjs. The following are the options:

  • Keep as is. Maintain a separate copy of eosjs and manually merge in commits we think are important.

    • Pro: no changes to current process

    • Con: hard to know what changes are important and you can get into a bit of merge hell when you cherry pick.

  • Create a complete separate fiojs that wraps eosjs and eosjs-ecc

    • Pro: This would be clean, would clearly separate out fio code, and would allow devs to use eosjs completely separately from FIO.

    • Con: This will require a lot of rework of our code and is not simple.

  • Create a fork of eosjs and eosjs-ecc and merge in our fio code

    • Pro: This makes comparison of upstream changes easier to compare and pull in.

    • Con: It is not a “clean” separation of FIO code.

Based on the discussion we recommend the fork option.

Compatibility

These fixes will require wallets to migrate their code to use the new structure. See the following Dev Guide to upgrade for more details: https://github.com/fioprotocol/fiosdk_typescript/pull/65

Decisions

  • Agree with v2.0 release?

  • Timing of release?

  • Messaging to ensure wallets know there is a migration.

  • Timing for desupport of v1.0 SDK (when do we stop adding new endpoints?)

  • Make similar changes to Kotlin? Timing?