# Sinfonia data architecture

## Needed data types

### Coin
Different pages require different amout of coin information. Using only the full interface is fine, diving theme has the advantage of smaller and faster responses.

interface Coin {
    iconUrl: string,
    name: string,
    symbol: string,
    price: number,
}

interface CoinExtra extends Coin {
    marketCap: number,
    volume: number,
    lastNDaysPrice: number[],
}

### Wallet

interface Wallet {
    address: string
}

### User
The only needed information for the User is the coins field but calculating total and bonded assets each time could be expencive in the client while on the server it could be computed while filling the coins array.

interface User {
    totalAssets: number,
    bondedAssets: number,
    coins: UserCoinInfo[]
}

interface UserCoinInfo {
    coin: Coin,
    total: number,
    bonded: number,
}

### Pool
This interfaces are likely to change because the structure of the last 2 items is very UI related and doesn't really belong to the pool, more to the user. They are going to be reviewed after we have decided what comes from the server and what is going to be requested directly to an external service from the client.

interface Pool {
    name: string,
    coin1: Coin,
    coin2: Coin,
    APR: number,
    liquidity: number,
    swapFee: number,
}

interface PoolUser {
    liquidity: number,
    bonded: number,
}

interface UserPoolView {
    pool: Pool,
    user: PoolUser,
}

### Logging and history
Just the same interfaces as before but with an added timestamp both in the form of inheritance and composition. To be decided which one to use, personally prefer composition.

interface Timed {
    time: Date,
}

interface TimedPool extends Pool, Timed {} //Inheritance
interface TimedPool {
    pool: Pool,
    time: Date,
} //Composition

interface TimedExchange extends Exchange, Timed {} //Inheritance
interface TimedExchange {
    swap: Exchange,
    time: Date,
} //Composition

interface ExchangeHistory {
    swaps: TimedExchange[],
}

## Server or Client

### Coin
Price can be retrieved from coingeko BUT only for assets listed on it, for not listed assets we have to query the pool service and calculate it. The server requesting to coingeko the price can even adopt some form of caching so even if 200 users requeste price at the sime time just the first request is goind to generate a coingeko API call and the other 99 are going to get the cached value. Moreover the other coin information have to be requested from server anyway so it's probably better to have the server handle all of it.

### Wallet
Completly local, available from Keplr.

### User
Generated server side with the exception of the totalBonded and totalAssets that could be both client or server generated.

### Pool
Everything can be requested from the Osmosis services expect the reward. Unfortunetly their API are very broad and expensive. The same reasoning that we did for coint could be done here, almost everything is available from Osmosis but not everything so we have to ask the server anyway and then match the responses if this is done client side.

### History
Osmosis API do not seems to have a user based history so that's need to be requested from the server. Creating the history could be done in two ways:
1. if we decide to do a direct request to Osmosis from the client for swaps then on a successfull transaction we have to inform the server
2. if we decide to do a request to our server and in turn it forwards the request to Osmosis then the server has complete controll on it
Both solutions are possible but the first one is going to fail if the user internet goes off between the Osmosis request and the request to push the history