# lite graph design

## Key features
- Postgres as event storage
- Hasura as gql/rest provider
- Parsers are written in any wasm compiled language
- Parser api should be based on Cloudflare workers design

## Parser api
Parser api looks like this:

pub struct Message();
pub struct Transaction();
pub struct Block();

pub struct ParserContext{
    pub block: Block,
    pub database: Database,
}

pub struct Hash(String);
pub struct Address(String);
pub struct ContractState(Vec<u8>);

pub struct DbRecord{
    pub table: String,
    pub message_hash: Hash,
    pub transaction_hash: Hash,
    pub data: serde_json::Value,
}

impl ParserContext{
    pub async fn save_record(&self, record: DbRecord) -> Result<()>{
        ...
    }

    pub fn get_contract_state(&self, address: Address) -> Option<ContractState>{
        ...
    }
}

pub trait Parser{
    async fn handle_message(ctx: ParserContext, message: Message);
    
    async fn handle_transaction(ctx: ParserContext, transaction: Transaction){
        for message in transaction.messages{
            handle_message(ctx, message).await;
        }
    }

    async fn handle_block(ctx: ParserContext, block: Block){
        for transaction in block.transactions{
            handle_transaction(ctx, transaction).await;
        }
    }
}

Every target language should implement this API in a Wasm wrapper.

## Flow
- `npx lite-graph init my-awesome-parser`
- User implements a parser in his language of choice
- User fills db schema or predefined `json | yaml` config
- `npx lite-graph compile` produces Wasm file
- `npx lite-graph load path/to/binary.wasm` loads binary
- `npx lite-graph serve` starts parsing using new config and code. Hasura server starts listening for requests

## Components
- lite-graph core:
- Wasm interpreter
- data storage layer
- lite-graph cli:
- init
- compile
- load
- serve
- lite-graph hasura:
- hasura server
- hasura migrations generator
- hasura metadata generator
- ts bindings for core api
- rust bindings for core api
- python bindings for core api