indexer-manager

README

INDEXER MANAGER / SEARCH

⚠ This is the new version of manager, if you're looking for the old one you can find it on legacy-manager branch This repository contains an indexer manager for transactions.

Structure

Connectivity

Manager and Worker are linked by GRPC bidirectional streams. To connect with each other, worker needs to know manager's http interface. After initial request is done - GRPC connection is started in another direction - from client to manager. All the following communication between services happen after. For every request, worker should sent a x number of responses marked with request's taskID. Response set should be terminated by one message with status being final.

Activity

Workers are meant to be stateless, this is why the main responsibility of managers is to serve requests from outside. Managers are not creating intermediate states. Every operation done on data is atomic. This allows to run more than one instance of manager in the same time.

Scheduling

To fulfill current goals, system needs to operate on actions that are triggered periodically. Because system may work with multiple instances of manager, this creates an obvious problem of reoccurring activities. This is why scheduler was created as separated process. It allows to connect to multiple managers in the form of SDS-like service. You can find scheduler inside indexer-scheduler repository.

Manager

Process that is responsible for maintaining current state of system

Client

It should not contain any transport related operations such as data conversions of parameter checks. All the input and output structures should be as carrier-agnostic as possible.

Connectivity

Manager's Package for maintaining connections with workers. Currently allows to start the abstract connection with workers, match request with the response and direct that to proper client handles. Also implements simple round robin strategy for sending every next request to another currently connected worker.

Transport

• GRPC transport for connectivity package. Bidirectional stream implementation for worker connectivity.
• HTTP transport containing set of user-facing endpoints with non-business logic data validation.

Worker

Stateless worker that is responsible for connecting with the chain, getting information, converting it to a common format and sending it back to manager. Worker can be connected with multiple managers but should always answer only to the one that sent request.

Transport

Currently implemented transport allow worker to run using grpc.

Connectivity

Basic functions for initial simple service discovery. Right now, http queries to every manager triggered periodically.

API

Implementation of bare requests for network.

Client

Worker's business logic wiring of messages to client's functions.

Docker-Compose

This repo also comes with partially preconfigured docker-compose setup. To run using docker-compose you need to

• Start docker-compose (If you're running that for the first time you may need to run docker swarm init )

    docker-compose build
    docker-compose up

First manager would (the main api) would be available under http://0.0.0.0:8085

Docker-compose version comes also with preconfigured prometheus and grafana, serving content on :3000 and :9090

Compile

To compile sources you need to have go 1.16+ installed. For Worker and Manager it's respectively

    make build

Running

The mandatory env variables (or json file) for both manager and migration the parameters are:

    ADDRESS=0.0.0.0:8085

Where ADDRESS is the ip:port string with http interface. It is possible to set the same parameters in json file under --config config.json

Local Development

Get the code

git clone git@github.com:figment-networks/indexer-manager.git
cd indexer-manager/

Run the manager

The manager needs very little config. Workers are configured with the manager address (http://0.0.0.0:8085). Once both the manager and worker are running, the worker will discover the manager and they will establish a streaming connection with each other automatically.

go run ./cmd/manager

If all goes well, you should see the following logs:

{"level":"info","time":"2021-06-29T16:52:30.367-0400","msg":"indexer-manager  (git: ) - built at "}
{"level":"info","time":"2021-06-29T16:52:30.367-0400","msg":"[HTTP] Listening on 127.0.0.1:8085"}

Workers (e.g. kava-worker) are by default configured with the manager address (http://0.0.0.0:8085). Once both the manager and worker are running, the worker will discover the manager and they will establish a streaming connection with each other automatically. If that's successful, you should see something like this:

{"level":"info","time":"2021-06-29T17:18:07.109-0400","msg":"[Manager] Registering ","type":"grpc","connection_info":{"version":"0.0.1","type":"grpc","addresses":[{"ip":"","address":"0.0.0.0:3000"}]},"network":"kava","chain":"kava-7","version":"0.0.1"}
{"level":"info","time":"2021-06-29T17:18:07.109-0400","msg":"[GRPC] Trying to connect with ","id":"580a26db-f7d3-4bfa-80fc-c0a615fd11d2","connection_info":[{"version":"0.0.1","type":"grpc","addresses":[{"ip":"","address":"0.0.0.0:3000"}]}]}
{"level":"info","time":"2021-06-29T17:18:07.111-0400","msg":"[GRPC] Successfully Dialed ","id":"580a26db-f7d3-4bfa-80fc-c0a615fd11d2","address":"0.0.0.0:3000"}
{"level":"debug","time":"2021-06-29T17:18:07.114-0400","msg":"[GRPC] Sending ClientResponse PONG","pong_duration":0.002995149}

The worker has made itself known and is now eligible to receive tasks. To schedule repeating tasks (such as polling for latest data), run the indexer-scheduler. Scheduler will automatically try connecting to a manager running on port :8085. Worker tasks can be configured inside scheduler.

Debug with VSCode

The .vscode directory contains a launch config to debug the manager. To start debugging, open the Debug panel (⇧⌘D) and click the green arrow.