By: Jesse Abramowitz, Blockchain Developer

One of the great promises of the Polkadot network is interconnectivity. For Polkadot interconnectivity doesn’t merely mean that each chain can talk to each other, but also that developers can easily develop on multiple chains.

Specifically I am referring to Polkadot.js. A JS library that connects you to a specific blockchain. This Library for the most part is one size fits all for each parachain, so as an application developer I don’t need to learn a whole new library for each parachain I just need the one library to rule them all.

However, as with anything there are growing pains. Since I believe the Universal Faucet is the first application to do connect to multiple parachains with Polkadot.js (Polkascan does parachains as well but they don’t use Polkadot.js…..let me know if there are others) I thought I would write an article as how I did it and some of the challenges I encountered.

To use the Polkadot.js library on multiple parachains you need your endpoint to the desired parachain and their custom node types. Since you can customize your runtime in each parachain you need to tell Polkadot.js what customizations you made. This can be done with a JSON object when you initialize your api instance.

That being said let’s go one by one through the four parachains I connected to and see how to connect to them and some challenges you may stumble on.

I have put all custom types and examples up on a github repo here.

Robonomics

To me this should be the standard. A simple JSON object I can go copy from a github page (or documentation) then I can drop it in my code and I am connected.

const api = await ApiPromise.create( { provider, types : { Order: { model: “Vec<u8>”, objective: “Vec<u8>”, cost: “Balance” }, “Demand”: { order: “Order”, sender: “AccountId” }, Offer: { order: “Order”, sender: “AccountId” }, Liability: { order: “Order”, promisee: “AccountId”, promisor: “AccountId”, result: “Option<Vec<u8>>” }, LiabilityIndex: “u64” }

Simple and easy. One issue I did have is that I needed node 10 or higher for this to work. The node types can be found on this github page.

Edgeware

I started off connecting Edgeware through some npm packages they had. The version of Polkadot Keyring those packages used and the ones I used were the same so I didn’t have any issues there.

They have since created a JSON object that allows them to connect. When I get that working I will post it on the github repo of connecting to parachains here. Again I recommend using the JSON object for reasons I will get more into when I was integrating Joystream.

const { ApiPromise, WsProvider } = require(“@polkadot/api”); const { IdentityTypes } = require(‘edgeware-node-types/dist/identity.js’); const { VotingTypes } = require(‘edgeware-node-types/dist/voting.js’); const { GovernanceTypes } = require(‘edgeware-node-types/dist/governance.js’); Const getApi = async () => { // Initialise the provider to connect to the local node const provider = new WsProvider(“”); // Create the API and wait until ready const api = await ApiPromise.create( { provider, types : { …IdentityTypes, …GovernanceTypes, …VotingTypes, }, });

Joysteam

This is where things got tricky. Joystream also uses an npm package for custom types. When using it alone it is fine. However, when using it with polkadot and edgeware not so much. Since each version of the modules use the same packages but different versions of them.

Joystream uses

“@polkadot/keyring”: “0.76.1”, “@polkadot/types”: “0.77.1”,

Edgeware uses

“@polkadot/api”: “0.79.1”

Which means you get this error

ExtError: Multiple versions of @polkadot/keyring detected, ensure that there is only version one in your dependency tree

To fix this it took me reading through the yarn documentation. There is something in yarn called resolutions which forces a specific version of every package you install. This will help resolve this issue. As you can see though this is one of the reasons why I prefer the JSON objects.

Here is what I added to my package JSON

```

“resolutions”: { “@polkadot/keyring”: “0.92.1”, “@polkadot/types”: “0.79.1” },

Centrality

Centrality doesn’t use the Polkadot.js library, which is cool their documentation was pretty decent. It can be found here and for the most part it was pretty similar.

It actually has a native coin and a native assets token called CENNZ and CENTRAPAY respectively.

The code looks like this.

It wasn’t crazy to implement, I can’t recall what versions of yarn it works with but mine was too low and I had to update it for it to work.

Deploying

The issue arose because we were using Firebase, which is great but does an npm install not a yarn install. Normally that would be fine, however since I am relying on yarn resolutions to resolve my package issue this was in a mess.

I found a library that would do this for npm, however it broke with node 10, so again I was shit out of luck.

Pretty much had to create a private_node_modules folder and upload the problematic node modules directly to firebase to fix this.

Conclusion

I think just like Ethereum and EIPS we will see polkadot and PIPs or maybe SIPs for substrate…..actually I really hope it is SIPs. An early SIP that I may propose is to make sure if parachains want to connect to the Polkadot.js library they at least provide a JSON object for types. If they want to get fancy for whatever reason go for it but at least have the JSON object. As well, some sort of global repo for these objects would be very nice (I have created the start of one here).