# Note Gianpaolo Severino

## Summary

- Repo url: https://github.com/gsanseverino/avascan-test
- Voto: 4/5

## Tecnologie usate

- express / mongoose
- mongodb

## Legenda
- :+1: Cosa positiva
- :-1: Cosa negativa
- :thinking_face: Elemento dubbio, nè :+1: nè :-1:
- :question: Richiesta di chiarimenti da fare al candidato

## Note

### Generali
- :+1: Ha usato due container per indexer e api
- :+1: Batch API di web3
- :thinking_face: Buona struttura endpoint, a parte per:
- `/addresses` che ritorna solo i top 100. È così da specifica, ma il naming dell'endpoint non riflette la cosa.
- `/transactions/<address>` che non ha molto senso
- :+1: Codice molto più leggibile/comprensibile

### Write a process in TypeScript that keeps updated in an appropriate database the transactions injected in the last 10,000 c-chain blocks:
- :thinking_face: blockNumbers potrebbe contenere numeri negativi
- :thinking_face: r46: Sarebbe stato meglio usare un Set
- :thinking_face: In teoria l'indexer non processa il live edge ma solo le ultime 10k quando lo lanci, poi esce
- :+1: Scritture in parallelo su mongo
- :-1: Poteva salvare i balance e le tx alla fine in modo da parallelizzarle
- :-1: getLastTransaction prende l'ultima tx ma non ordina su txIndex, e comunque non abbiamo un indice su blockNumber.
- Tecnicamente manca lo streaming ma basta far ripartire l'indexer.

### list transactions made or received from a certain address sorted by blockNumber and transactionIndex:
- :-1: Indice creato non soddisfa la chiamata, anzi l'endpoint non ordina proprio, gli è andata bene che mongo ha sfruttato l'indice anche se non completamente.
- :-1: No paginazione

### number of transactions made or received from a certain address
- :-1: poteva splittare la count in due query e fare indice sia su to che su from
- :-1: poteva fare contatore visto che l'indexer lavora pullando i blocchi

### list of transactions sorted by value (amount of $AVAX moved)
- :thinking_face: Doppio indice +1/-1 ?
- :+1: Funziona
- :-1: Meccanismo per generare la pagina precedente è un po' weird, prende la prima tx e vede se è contenuta nella pagina corrente.

### list of 100 addresses with largest balance that made or received a transaction
- :+1: ok indice

## Feedback
Codice chiaro, funzionamento lineare e buona struttura del progetto. Positivo aver usato due container per separare i due processi.
Aree di miglioramento:
- Design degli indici del database (esempio: Per recuperare le transazioni dove un address è from OR to non è sufficiente un indice del tipo `{from,to, blockNumber, txIndex}`)
- Design endpoint API (naming e chiarezza sulle funzioni dell'endpoint stesso)
- Approcci di ottimizzazione legati alla gestione di centinaia di milioni di transazioni, dove eseguire operazioni come una `count` possono essere proibitive

# Note colloquio 2023-02-24

## Summary
Ha fatto domande a Lorenzo?
Supponeva di dover calcolare il balance basato sulle tx, invece Lorenzo ha chiarito che è il balance assoluto dell'indirizzo.
Ha guardato avascan per prendere ispirazione su paginazione etc...

## URL /addresses
Si mette a parlare delle entità che ha strutturato. Si giustifica dicendo che non gli è venuto in mente.

## URL /transactions/<address>
Si mette a parlare delle entità che ha strutturato.
Poi dice che si potrebbe usare un query param.

## Cosa succede se ho meno blocchi di 10k.
Dovrei aggiungere un check per eliminare i negativi

## Riga 46
Cita Map, ma non sembra molto padroneggiante della cosa.

## getLastTransaction
Ok si accorge che manca l'indice

## Live edge
Aveva ipotizzato di riavviare l'indexer

## Indice non corrispondente
Non sa capire bene perchè l'indice non va, si giustifica.

## Alternative alla count
Potrei incrementare un counter nella collection addresses.
:question: Come e quando lo faresti?
Lo farei a livello di indexer, però poi avrei tante query a mongo. Oppure potrei recuperare i dati all'inizio del batch e poi scrivere su mongo alla fine.