Skipper frontend

[ya7on]

Skipper full application architecture

Updated scheme of app services relations. Arrows represents data flow direction

architecture-beta
    group blockchain[TON]
    group backend[Backend application]

    service ui(internet)[User Interface]

    service api(internet)[API] in backend
    service indexer(internet)[Indexer] in backend
    service db(database)[Database]

    service tonapi(cloud)[TON API]

    service lock(database)[Jetton Lock] in blockchain
    service skipper(database)[Skipper] in blockchain
    service proposal(database)[Proposal] in blockchain
    service voter(database)[Voter] in blockchain

    junction left_db
    junction right_db

    ui:R <--> L:api
    api:T <-- B:left_db
    left_db:R --> L:db
    db:R <-- L:right_db
    right_db:B -- T:indexer

    indexer:B <-- T:tonapi
    tonapi:B <-- T:skipper

    lock:R --> L:skipper
    skipper:R --> L:proposal
    proposal:R <--> L:voter

Loading

Services

TON API - external service tonapi.io

API and Indexer are backend threads/processes/tasks (no matter) of backend application. Indexer listen to updates in blockchain, serialize it to database data structure and store it. API read stored data from database.

Updates from blockchain

After some research i find out that there is no need to listen emitted events in TON. There is HTTP API endpoint in tonapi.io: /v2/accounts/{account_id}/traces it return list of latest account traces:

Trace structure:

{
    "id": "55e8809519cd3c49098c9ee45afdafcea7a894a74d0f628d94a115a50e045122",
    "utime": 1645544908
}

Trace is (as i understood) group of transactions that has communicated with each other. If one of transaction related to specified account it appear in traces list endpoint.

We could periodically get list of latest traces for Skipper contract and check is there is some new traces. If there is, we fetch detailed information about each trace using /v2/traces/{trace_id} endpoint. It result has full info about transactions in this trace. So we could see opcodes and messages body (not sure it's full body, but opcodes are there) thus we could know is there new votes or new proposals.

Also using traces listening we could fit in free tier in tonapi with 1 rpc.

[iamIcarus]

when user open page with all active proposals frontend should call getter to each proposal contract visible on page to get it data

That will be the major issue yes, on top of that there is a rate limit (at least for free RPC).

Will it be background periodic task that should call getters of smart contracts or will it be something like Websocket subscriber in tonapi.io

We can improve better by emitting events on critical contract state changes so the fetching will work on-demand instead of scheduled.

[ya7on]

We can improve better by emitting events on critical contract state changes so the fetching will work on-demand instead of scheduled.

How will contract emit these events? It would be great to catch specific events and use it as trigger to reindex data in DB.

[iamIcarus]

check out this example

i didn’t get the chance to work with events on TON yet but i had worked before on Ethereum

events are very gas-efficient

[ya7on]

Thank you. I will try it

[ya7on]

I updated scheme in OP. Could you please share your thoughts on it?

[iamIcarus]

I wasn't aware of traces , that's is a better solution. Nice work!

The new scheme looks good!