Decimal API Update
Hello, community!
Yesterday we published a large-scale article with plans for 2024, and today we will share the first results on the way to our goals.
Throughout the life of the Decimal blockchain, a separate set of software has been responsible for receiving, processing, storing and transmitting data from the network.
As the network has grown and the functionality and operations have increased, so has the load on the software used. This led to time delays in operations, errors in the response to requests sent via API, incorrect display of data on awards, etc.
The team decided to reorganise the software.
A distinctive feature of the new approach to working with data was the transition from a monolithic system to a microservice system.
Previously, the software complex consisted of the following components:
- parser,
- database (a single database that stored all received and processed information from BC),
- Gate API,
- Explorer API.
In its new form, the complex is represented by a set of microservices, each consisting of its own parser, database and API.
The following objectives were set as part of this transformation:
1. Redesign the data parser from the BC.
- Optimise the parser’s performance through more modern approaches in software development.
- Rewrite the source code of the parser from NodeJS to Golang
- Make the parser modular and practical so that it can be reused.
2. Conduct an API revision.
- Revise all roots and endpoints and remove duplicates.
- Divide all endpoints into thematic groups, which will be united into one service
- Rewrite endpoints data processing logic from Node.JS to Golang. It is important to note that the structure of endpoints has not changed.
What the new approach will give us:
- Increased speed of data acquisition, processing and transmission
- Increased fault tolerance of the whole system. If one of the services goes down, the others will continue to work.
- Scalability of a single service as its functionality increases
So far, work has been done on 4 services, namely:
- Service transactions (API Service transaction)
- Rewards service (API Service rewards)
- Service Block (API Service Block)
- Service Coin (API Service Coin)
These services are being tested. 26. 01 Transaction Service was launched in the extended environment. This means that EVM transaction data displayed in Explorer will come from it.
Several services are currently under development:
- Service Contracts (API Service Contract)
- Service Address (API Service Address)
It is important to note that after thorough testing, the service endpoints will be integrated into Explorer and Console. On the extension environment, data will already pass through these services. Until all the services are brought to the Prod and pass all the checks, the current software system will continue to work.