Explaining why there were problems with RPC nodes and what was the problem and why you must update your application.
### Target audience
I explained everything as simple as I could. The main call is for the app owners to update their applications with the updated libraries.
After the recent timeout problems, it was necessary to take these steps and update the libraries.
I updated 2 major JS libraries, hive-js and dhive, to help resolve the timeout problems.
### The "call" method
The "call" method was a way of talking to hived (the hive blockchain's application). This method got deprecated and removed from hived with the appbase update (HF19?).
So what has happened since then? Well, we were still using the "call" method for most of our applications. But the "call" method is not known to hived anymore, so the requests have to go through a proxy called "jussi". Jussi is installed in front of all the public RPC nodes.
Jussi takes the "call" method and translates it into the correct format then sends it to the hived. The problem is, you are adding an extra step for the API requests and it slows them down.
An example of the "call" method:
```
{"id":0,"jsonrpc":"2.0","method":"call","params":["database_api","get_dynamic_global_properties",[]]}
```
Notice `"method":"call"`. So jussi takes that and translates it into the new format:
```
{"id":0,"jsonrpc":"2.0","method":"condenser_api.get_dynamic_global_properties","params": []}
```
See what happened? The user thinks the call was going to `database_api` but actually, jussi translates it into `condenser_api`.
To be honest, this is not the best way of doing things. The idea behind jussi was good but implementation was a mess.
***
### What is the "new" format?
The "appbase" style calls are the calls that are supported directly by hived and don't need a translation.
It's not new and has been there for years but we didn't bother updating our libraries to use the supported methods.
With switching to the appbase calls, every request to the RPC nodes becomes faster.
This is the first change to both hive-js and dhive libraries. They both were using the deprecated "call" method.
***
### You might not need jussi
Till now, hive-js wouldn't work with hived nodes until you added jussi in front of them. But with this update, hive-js will work with hived nodes. But remember, you will still need jussi for the hivemind calls. Also, there might be caching benefits in using jussi.
***
### Broadcasting transactions
This is the important part. There are two methods for broadcasting a transaction.
1. `broadcast_transaction_synchronous`
2. `broadcast_transaction`
The first method sends the transaction to the RPC node, the RPC node validates the transaction, then waits for the transaction to be included in a block, then sends back a response including the transaction id and block number.
The second method sends the transaction to the RPC node, the RPC node validates the transaction, then sends an empty success response back.
In the second method, the library has to generate the transaction id locally. Which is way too much faster. In this method, the only way for a transaction to fail is expiration or micro forking maybe. So in most cases, it's good enough.
Of course, hive-js and dhive both were using the first method. When many people connect to the RPC node and wait there, it becomes problematic. The best way for handling huge traffic is to release a connection as soon as possible so other connections can be made.
Both libraries now use the second method for broadcasting transactions. You may already notice its huge impact on the speed of your votes and comments.
Peakd is already updated. Keychain is waiting for google approval and the mobile version will be soon updated. Some apps are catching up like Hivesigner, and Ecency. There was a problem updating hive.blog and that will be also updated.
***
### Why bother updating
- Everything becomes faster for the end-user
- RPC nodes don't suffer overloading
- Apps become future proof
- It's easy as running a command
***
### How to update your apps
**hvie-js v2.0.1** - [Release notes](https://gitlab.syncad.com/hive/hive-js/-/releases)
Used in hive.blog, peakd, keychain, and many other apps.
```
npm install @hiveio/hive-js@latest --save
```
The minified JS for browsers:
```
https://cdn.jsdelivr.net/npm/@hiveio/hive-js@2/dist/hive.min.js
```
***
**dhive v1.0.0** - [Release notes](https://gitlab.syncad.com/hive/dhive/-/releases)
Used in ecency (mobile & web) and many other apps.
```
npm install @hiveio/dhive@latest --save
```
The minified JS for browsers:
```
https://cdn.jsdelivr.net/npm/@hiveio/dhive@1/dist/dhive.js
```
***
**hive-tx v4.0.0** - [Release notes](https://github.com/mahdiyari/hive-tx-js/releases)
Used in keychain mobile and other apps.
hive-tx already is using the appbase methods and there is a function called `.broadcastNoResult()` for the fast transaction broadcasting. But I did update hive-tx so now the `.broadcast()` function is also updated.
```
npm install hive-tx@latest --save
```
The minified JS for browsers:
```
https://cdn.jsdelivr.net/npm/hive-tx@4/dist/hive-tx.min.js
```
***
Note:
@foxon and @emrebeyler confirmed that `beem` doesn't need an update.
***
### Scaling problems?
The recent problem doesn't seem to be a scaling problem. It's more related to the libraries and apps using the deprecated methods.
The recent library changes seem to be solving most of the problems. Although there are investigations still going on by @blocktrades regarding the timeout problems.
Hive blockchain in theory can handle much more activity than this. Some say like 1,000 transactions per second. But there might be minor problems because those scenarios are not actually tested.
***
### Final words
I'm sure all the problems will be solved and we will see much better growth. I'm bullish on Hive and will continue my contributions as far as I can.
Thanks to the other devs who updated their applications on time to help with the problem.
***
Image source: pixabay.com
See: Everything can be faster on Hive - hive-js & dhive new changes
by
@mahdiyari
