Que sensacional, tanto a abordagem dos dados quanto toda descrição do que foi feito aqui nessa publicação! Vou divulgar no meu LinkedIn amanhã 🎉
Uma dúvida: no último gráfico, ele representa a soma das TabCoins dos contents de cada usuário? Se sim, isso inclui tanto contents com e sem parent_id?
Salve, filipedeschamps!
Obrigado pelo feedback! 😁
Então, pelo que entendi, o endpoint de content só retorna os posts pais e suas respectivas estatísticas. Nenhum dos dados obtidos por este endpoint tem parent_id diferente de null, i.e. são todos nulos.
Fiz um bate de números para alguns posts, e o valor de TabCoins para eles bate com o que está no campo tabcoins que a API retorna, e é este mesmo campo que utilizei para somar as TabCoins:
select owner_username,
count(distinct id) as qtdContent,
sum(tabcoins) as qtTabcoins,
sum(tabcoins) / count(distinct id) as qtTabCoinsContent
from bronze.tabnews.contents
group by 1
order by 3 desc
limit 10
Acho que temos como oportunidade navegar post a post para pegar todos os posts filhos, hehe.
Boa, correto! Por padrão o endpoint /contents vai assumir stragegy=best e é o que está sendo utilizado na Home 🤝
Outra estratégia que você pode utilizar para o scraping é o stragegy=new que irá listar as publicações de forma descrescente, veja:
https://www.tabnews.com.br/api/v1/contents?strategy=new&page=1
E caso queira pegar tudo de um usuário (tanto publicações root quanto child):
https://www.tabnews.com.br/api/v1/contents/filipedeschamps?strategy=new&page=1
Perfeito! No nosso script já utilizamos o strategy=new. A questão é que se um post (particularmente os mais antigos) é atualizado ou ganha mais Tabcoins, mesmo pegando por essa estratégia não vamos ter visibilidade, certo? A não ser que percorra sempre todas as pages.
Por isso pode ser uma boa ideia ter uma strategy=updated_at (algo assim), ordenando os contents pela sua atualização, seja por edição, tabcoins, childs, etc. Assim evitamos percorrer todas as pages para pegar todos os contents atualizados, trabalhando apenas com as pages mais recentes. Não sei se me fiz entender hehe. Mas é algo que ajudaria tanto na coleta dos dados (em velocidade), quanto evitaria o escalonamento de minhas requests à API.
Coloquei esses pontos nessa issue
Perfeito! No nosso script já utilizamos o strategy=new. A questão é que se um post (particularmente os mais antigos) é atualizado ou ganha mais Tabcoins, mesmo pegando por essa estratégia não vamos ter visibilidade, certo? A não ser que percorra sempre todas as pages.
Hmm é verdade!
Por isso pode ser uma boa ideia ter uma strategy=updated_at (algo assim), ordenando os contents pela sua atualização, seja por edição, tabcoins, childs, etc. Assim evitamos percorrer todas as pages para pegar todos os contents atualizados, trabalhando apenas com as pages mais recentes. Não sei se me fiz entender hehe. Mas é algo que ajudaria tanto na coleta dos dados (em velocidade), quanto evitaria o escalonamento de minhas requests à API.
Seria bom até para outras coisas 🤝
Em paralelo, para o maior controle possível seria legal expor a tabela balance_operations com todas as movimentações. No futuro gostaria de fazer isso 🤝