Nova estratégia de relevantes (ainda pelo saldo de TabCoins)

[aprendendofelipe]

Esse PR altera a estratégia de ranqueamento por relevância dos conteúdos.

Agora os conteúdos com até uma semana de idade são divididos em faixas de tempo de publicação e, dentro das faixas, são organizados pelo saldo de TabCoins (em breve iremos considerar uma outra estratégia de Score que se baseia nos votos, mas não somente o saldo de TabCoins).

Com isso podemos classificar um número maior de conteúdos ao mesmo tempo, diferente do que ocorre atualmente onde a classificação ocorre somente nos 30 conteúdos de cada página.

Para compensar um pouco a diminuição de performance pela query de ranqueamento mais pesada, foi eliminada a consulta que era feita apenas para buscar o total_rows. Agora esse valor é obtido na mesma consulta.

Também foi inserido os paths dentro de getStaticPaths para que os conteúdos relevantes tenham suas páginas estáticas geradas durante o deploy.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
tabnews	✅ Ready (Inspect)	Visit Preview	Sep 28, 2022 at 1:11PM (UTC)

[aprendendofelipe]

Apenas registrando aqui que ao invés de testar a performance somente do banco com a nova query, eu testei o tempo de execução da função getRelevant, pois aí a comparação faz mais sentido, já que duas consultas ao banco (contents e total_rows) agora viraram somente uma, e não existe mais o ranqueamento que ocorria na lambda, pois o conteúdo já vem do banco na ordem correta.

Os resultados foram tempos muito similares para getRelevant tanto na versão atual como na nova proposta.

Registro também que a parte de getStaticPaths foi só para aproveitar o deploy para entender melhor o seu funcionamento. Pois essa função só tem influência no momento do deploy. No próximo commit vou subir uma versão diferente para testar a geração de um número maior de páginas e com isso verificar se o número de conexões com o banco sobe na mesma medida. Na versão final desse PR podemos retirar (ou não) os paths de getStaticPaths.

[filipedeschamps]

Ahhhh que sensacional a parte do count que estava antes fazendo uma request duplicada 😍 isso vai ajudar muito!

Sobre o getStaticPaths, show de bola!! E vendo os logs aqui, não sei se criou o cache, estranho. Pegando esse build com o anterior do mesmo ambiente, os dois deram ~2 minutos e geraram 132 estáticos:

E que susto entrar em Preview e ter só a sua publicação 😂 😂 😂 mas faz total sentido!! 🤝 🤝 🤝

[filipedeschamps]

Tem pouca publicação para testar, mas vendo aqui quantos TabCoins precisava para a sua publicação ficar acima da minha:

6 TabCoins fica assim:

Daí com 7 foi pra cima 😍

[edit]

Comparando com o algoritmo velho:

[aprendendofelipe]

Ahhhh que sensacional a parte do count que estava antes fazendo uma request duplicada 😍 isso vai ajudar muito!

Pois é, isso, somado a não precisar reclassificar os conteúdos na lambda, compensou a diferença na performance da query 🎉

Pegando esse build com o anterior do mesmo ambiente, os dois deram ~2 minutos e geraram 132 estáticos:

Também reparei nisso. Se os caches aparecem nesse contagem, deveria ter um a mais (que era o único conteúdo retornado nos relevantes), por isso falei que no próximo commit vai ser um número maior de páginas, pois vou mudar a estratégia para new. Daí vai dar pra testar se gerou ou não o cache ao monitorar as conexões com o banco.

E que susto entrar em Preview e ter só a sua publicação 😂 😂 😂 mas faz total sentido!! 🤝 🤝 🤝

Ninguém publicou nada em homologação nos últimos dias... hahaha... Todo mundo ansioso pelo vídeo de lançamento 🚀

quantos TabCoins precisava para a sua publicação ficar acima da minha

Isso está fixo na query... Tem uma janela de TabCoins acima de 13, outra acima de 7... E isso vai intercalando com as janelas de tempo

Daí acho que devemos deixar mais flexível, pois a query deve ir para uma função que vai exigir uma migration para ser alterada, mas essa função pode receber esses parâmetros. E acho até que podemos deixar esses parâmetros no .env. Porque aí facilita pra quem estiver desenvolvendo fazer simulações e também facilita para os testes não precisarem ser alterados sempre que mudarmos esses parâmetros. Além de podermos deixar parâmetros diferentes em homologação. O que acha?

Acho que a próxima etapa já vai exigir rodar uma migration para salvar a função que calcula o Score e a função que recebe os parâmetros e efetua o ranqueamento. Daí não vai mais precisar desse arquivo queries.js.

O que acha @filipedeschamps? Já crio essas funções (o que não deve mudar nada no funcionamento e performance) ou quer testar mais alguma coisa antes?

Aproveitando... Tomei um 429 aqui. Acho que só porque deixei a página de status aberta. E se não foi por isso, precisamos investigar 😮

[aprendendofelipe]

Daí com 7 foi pra cima 😍

Esqueci de comentar... Se as duas publicações estivessem na mesma janela de tempo bastaria ter 1 TabCoin a mais para ficar por cima. E as janelas de tempo estão assim: 1h, 6h, 1 dia, 3 dias e 7 dias.

[filipedeschamps]

Aproveitando... Tomei um 429 aqui. Acho que só porque deixei a página de status aberta. E se não foi por isso, precisamos investigar 😮

Show! Recebi o alerta aqui:

E analisando os logs, foi por conta dela mesmo 😂 Ela faz 4 request a cada segundo para atualizar os dados, então em menos de 5 minutos com a página aberta o usuário irá esbarrar no rate limit. Deveríamos manter esse intervalo para o refresh dos dados do banco de dados, mas o restante deveríamos reduzir bastante.

Isso está fixo na query... Tem uma janela de TabCoins acima de 13, outra acima de 7... E isso vai intercalando com as janelas de tempo

Daí acho que devemos deixar mais flexível, pois a query deve ir para uma função que vai exigir uma migration para ser alterada, mas essa função pode receber esses parâmetros. E acho até que podemos deixar esses parâmetros no .env. Porque aí facilita pra quem estiver desenvolvendo fazer simulações e também facilita para os testes não precisarem ser alterados sempre que mudarmos esses parâmetros. Além de podermos deixar parâmetros diferentes em homologação. O que acha?

Me parece show, mas ao mesmo tempo fico pensando que o agoritmo que eu criei hoje não é o melhor do mundo, mas mesmo assim não houve a necessidade de ficar mexendo tanto nele e está a um tempo consideravel no ar sem alteração alguma. Dado a isso, eu imagino que iremos achar uma configuração muito boa rapidamente com o seu algoritmo e não iremos mexer nele por muito tempo, e quando mexer, seria legal ver isso sendo provado de alguma forma pelos testes (se tiver algum impacto).

---

Deixei esse trecho abaixo em itálico porque a fonte é tipo "vozes da minha cabeça":

Fiquei pensando alguns bons minutos aqui e reavaliando/considerando algumas implementações no passado e até mesmo ao longo do desenvolvimento aqui no TabNews eu percebi que tudo que teve uma probabilidade de ficar "dormente", não valeu a pena criar configuração ou sofisticação em cima. O débido dessa sofisticação, no tempo suficiente, vai transformar o saldo da implementação em negativo. Então mesmo se você passar por um estágio inicial de ativamente modificar algo que após isso irá ficar dormente, chuto que vale a pena deixar implementado de forma estática e consolidado tudo num mesmo lugar, uma vez que esteja isolado/componetizado(?). Por algum motivo, é sempre muito mais fácil consumir um sistema assim e expandir ele para uma versão sofisticada se precisar, do que pegar uma versão sofisticada e simplificar (se a sofisticação não valeu a pena). Inclusive, é muito raro presenciar alguém simplificando algo (removendo sofisticação), quando ela não está sendo usada... mesmo que isso fica lá gerando uma porcentagem de entropia. Avaliando as sofisticações de forma isolada, nenhuma poderá incomodar, mas somando todas e projetando isso para o futuro, temos um sistema com muita entropia. E novamente, tudo que está simples e precisa ser transformado para algo mais sofisticado, vai ser transformado, onde o contrário já é muito mais raro. Entendo que a dinâmica seja assim, porque sofisticar algo é "feature driven", já simplificar algo é "maintenance driven".

E com isso eu entendo cada vez mais frase abaixo:

Fim das vozes da minha cabeça 😂😂😂

---

Acho que a próxima etapa já vai exigir rodar uma migration para salvar a função que calcula o Score e a função que recebe os parâmetros e efetua o ranqueamento. Daí não vai mais precisar desse arquivo queries.js.

O que acha @filipedeschamps? Já crio essas funções (o que não deve mudar nada no funcionamento e performance) ou quer testar mais alguma coisa antes?

Minha sugestão é entrarmos com esse PR em produção e avaliar o resultado, entender se precisa fazer algum ajuste e em seguida fazer as funções que você citou na migration.

[aprendendofelipe]

E analisando os logs, foi por conta dela mesmo 😂 Ela faz 4 request a cada segundo para atualizar os dados, então em menos de 5 minutos com a página aberta o usuário irá esbarrar no rate limit. Deveríamos manter esse intervalo para o refresh dos dados do banco de dados, mas o restante deveríamos reduzir bastante.

Que bom que é só isso! Acho que é bom alterar os tempos antes do lançamento, então, para não deixar para depois, já vou mudar para 30s... Se quiser um tempo diferente é só falar.

Deixei esse trecho abaixo em itálico porque a fonte é tipo "vozes da minha cabeça":

HAHAHA... Que bom que não sou só eu que tenho essas vozes!!! Pensei que as minhas fossem por eu ser físico 😜

Então tá show! Só que ainda falta criar algo para quando chegar no fim dos relevantes, na linha do que você sugeriu aqui

podemos sugerir ela continuar a navegação pela seção Recentes.

Não pensei ainda na melhor maneira de sugerir isso. Talvez algo assim:

Esses foram os conteúdos relevantes mais atuais. Veja os demais conteúdos na seção Recentes.

Isso até pode ficar para depois, mas não dá pra enviar pra produção antes de saber o que vai acontecer se o getStaticPaths tentar gerar os 60 estáticos de uma vez. Podemos só retirar desse PR, mas como quero descobrir logo isso, vou aproveitar enquanto você analisa sobre a mensagem acima e sobre os tempos na página status, e já vou subir uma versão com strategy: 'new'. E se der tudo certo eu volto para strategy: 'relevant', pois acredito que faz mais sentido. Se no deploy abrir diversas conexões do mesmo jeito que sem os paths, então eu retiro isso do PR, pois nesse caso não vai nos ajudar em nada por enquanto. Mas se você quiser que retire os paths independentemente do resultado do teste, é só falar.

[aprendendofelipe]

Gerou os 60 estáticos e não mudou o tempo de deploy

Mas realmente não muda o número de static files aqui:

Além disso, o número de conexões com o banco chegou a um pico de 44 conexões, [Edit: o que leva a crer que a geração mesmo durante o deploy ocorre em mais de uma lambda, mas provavelmente não seja uma lambda por path, pois senão teriam sido abertas 60 novas conexões Faltava adicionar os paths em mais alguns caminhos, pois a geração de todas as páginas ocorre na mesma lambda, ou seja, com só uma conexão do banco]. Com esse resultado eu acho que vale a pena deixar os paths. Então vou mudar de volta para strategy: 'relevant'. Ok?

[filipedeschamps]

Que bom que é só isso! Acho que é bom alterar os tempos antes do lançamento, então, para não deixar para depois, já vou mudar para 30s... Se quiser um tempo diferente é só falar.

Ficou sensacional!! É isso aí 🤝

Esses foram os conteúdos relevantes mais atuais. Veja os demais conteúdos na seção Recentes.

Perfeito!

Com esse resultado eu acho que vale a pena deixar os paths. Então vou mudar de volta para strategy: 'relevant'. Ok?

Também acho que vale a pena manter, pois a cada deploy perdemos os caches e se um robô do Google passar e ele ter que esperar para a página ser gerada, vai nos penalizar nos resultados. Com isso temos a garantia de os conteúdos mais frescos e relevantes sempre vão responder rápido para todo mundo 🤝

[aprendendofelipe]

Mais um ponto positivo para passar os paths em getStaticPaths:

Voltei a strategy: 'relevant', mas em homologação hoje só tem 3 conteúdos recentes, então só gerou esses 3 caches durante o deploy. Após o deploy, ao navegar para a página Recentes, o número de conexões subiu até o limite de 90%, coisa que não aconteceu durante o teste que gerou cache de 60 conteúdos durante o deploy.

Com esse resultado dá até vontade de aumentar esse número para 100, que seria o limite atual pelo validador do campo per_page.

[filipedeschamps]

Após o deploy, ao navegar para a página Recentes, o número de conexões subiu até o limite de 90%, coisa que não aconteceu durante o teste que gerou cache de 60 conteúdos durante o deploy.

Hmmm que interessante! Fora que isso garante que de fato as páginas conseguem ser geradas (onde sem isso, só em produção a gente descobriria "bug de produção" ao gerar uma página de conteúdo).

Com esse resultado dá até vontade de aumentar esse número para 100, que seria o limite atual pelo validador do campo per_page.

Não vejo problema algum! Só tomaria cuidado com aqueles valores do database.js para ele não abrir conexões demais no build e invadir as conexões reservadas 👍

[aprendendofelipe]

Não vejo problema algum! Só tomaria cuidado com aqueles valores do database.js para ele não abrir conexões demais no build e invadir as conexões reservadas 👍

Colocando 100, o número de conexões durante o deploy permaneceu em 5. Tranquilo demais!

Só que achei estranho que ao navegar pela primeira vez na página de Recentes o número de conexões subiu. O que indica que o cache das páginas ainda estavam sendo gerados depois do deploy. Demorou um pouco, mas entendi o motivo. Só estava gerando as páginas no caminho pages\[username]\[slug], mas as páginas de cada autor ainda eram geradas somente no primeiro acesso após o deploy.

Então agora coloquei os paths no caminho pages\[username] também. E agora sim o número de conexões permaneceu em 5 mesmo após o deploy. O número de conexões só subiu após navegar até a página 4, onde aí sim passei dos 100 conteúdos gerados no deploy.

Então errei ao afirmar que

a geração mesmo durante o deploy ocorre em mais de uma lambda

Pois agora o número de conexões não está mais subindo durante o deploy, o que indica que todos os caches são gerados pela mesma conexão com o banco 🎉🎉🎉

Vou voltar strategy: 'relevant' e vou deixar para amanhã a criação da mensagem:

Esses foram os conteúdos relevantes mais atuais. Veja os demais conteúdos na seção Recentes.

[aprendendofelipe]

Acho que é isso por enquanto:

• Ranqueamento de relevantes da última semana utilizando o saldo da TabCoins.
• Mensagem no final da lista de relevantes direcionando para Recentes.
• Mudança no refreshInterval dos analytics na página de Status.
• Adicionado paths nos getStaticPaths das páginas: /[username], /[username]/[slug], /pagina/[page] e /recentes/pagina/[page].

Separei os commits só por organização. Acho que está pronto para produção, se todos estiverem de acordo.

Próxima etapas incluem:

• Criar a função para usar o Score no lugar do saldo de TabCoins. E isso pode ficar para depois do lançamento, caso ele esteja próximo.
• Monitorar o ranqueamento e ajustar o que for necessário.

[filipedeschamps]

@aprendendofelipe por mim está ótimo e está pronto para o merge 👍

O único detalhe que eu talvez alteraria é na cor dos links gerados pelo EndOfRelevant. Ficou um pouco invisível, mas eu posso estar sendo um "usuário falso" nesse ponto, porque eu fui atrás da feature, coisa que poderá não acontecer com um usuário normal. Um usuário normal poderá ler os itens da lista até esbarrar com esse item especial. De qualquer forma, se achar que faz sentido ter um impacto visual maior, eu deixaria os links com a cor padrão de links, sem estilizar a parte de estarem visitados inclusive.

[filipedeschamps]

@aprendendofelipe vou alterar a cor do link do EndOfRelevant e fazer deploy 🤝

[aprendendofelipe]

O único detalhe que eu talvez alteraria é na cor dos links gerados pelo EndOfRelevant. Ficou um pouco invisível, mas eu posso estar sendo um "usuário falso" nesse ponto, porque eu fui atrás da feature, coisa que poderá não acontecer com um usuário normal. Um usuário normal poderá ler os itens da lista até esbarrar com esse item especial. De qualquer forma, se achar que faz sentido ter um impacto visual maior, eu deixaria os links com a cor padrão de links, sem estilizar a parte de estarem visitados inclusive.

O que eu pensei sobre isso foi mais informar o final dos relevantes do que criar um Call-to-Action. Por isso deixei no mesmo padrão dos conteúdos. Assim um usuário que ainda não está familiarizado com o sistema não vai ser desviados para os conteúdos mais recentes antes de percorrer todos os títulos classificados como relevantes.

E a formatação menos destacada para quem já acessou o link de Recentes é justamente para não dar chamar atenção para algo que não é novidade para esses usuários.

[aprendendofelipe]

@aprendendofelipe vou alterar a cor do link do EndOfRelevant e fazer deploy 🤝

Mas se tem intenção de direcionar o usuário para esse caminho, então manda bala! 🤝

[filipedeschamps]

O que eu pensei sobre isso foi mais informar o final dos relevantes do que criar um Call-to-Action. Por isso deixei no mesmo padrão dos conteúdos. Assim um usuário que ainda não está familiarizado com o sistema não vai ser desviados para os conteúdos mais recentes antes de percorrer todos os títulos classificados como relevantes.

E a formatação menos destacada para quem já acessou o link de Recentes é justamente para não dar chamar atenção para algo que não é novidade para esses usuários.

Show! Seu raciocínio faz total sentido! O meu receio começou a ser de um usuário novo no site não notar que aquele item é um aviso, acabar lendo por cima e ter a percepção que o TabNews tem só aquilo de conteúdo. E para o usuário hardcore, acredito que ele dificilmente vai chegar na última página 🤝

Mas se tem intenção de direcionar o usuário para esse caminho, então manda bala! 🤝

Show, mandando commit 👍

[filipedeschamps]

Merged! Let's goooooooooooooooooooooo!!!!!

[filipedeschamps]

Olha que massa, recuperou no item 30 essa publicação super relevante, mesmo sendo de 4 dias atrás 😍 🎉

Em paralelo, deu uma puxada no banco ainda, mas foi uma delícia ter as páginas da paginação já cacheadas 🤝

[aprendendofelipe]

Olha que massa, recuperou no item 30 essa publicação super relevante, mesmo sendo de 4 dias atrás 😍 🎉

🤩🤩🤩

Em paralelo, deu uma puxada no banco ainda, mas foi uma delícia ter as páginas da paginação já cacheadas 🤝

Provavelmente tinha alguém navegando pelas páginas de recentes para além da página 4. Acho que só pode ter sido isso que disparou as conexões.

Mas o principal é que quem estava navegando até a terceira página não precisou aguardar nenhuma criação de estáticos 🎉🎉🎉

[aprendendofelipe]

Olha que massa, recuperou no item 30 essa publicação super relevante, mesmo sendo de 4 dias atrás 😍 🎉

E com isso já percebi uma falha, pois esse conteúdo deveria estar no top_one, que é o melhor da semana (desde que tenha mais de 13 TabCoins). Em algum momento durante os testes eu decidi inverter o rank_group para o 0 ser o primeiro, mas acabou sobrando ORDER BY rank_group DESC em duas janelas de tempo (top_one e top_three).

Na verdade em top_one essa classificação por rank_group nem faz diferença, mas eu mantive para ficar o mesmo padrão em todas as janelas e assim facilitar quando fosse criar uma função recorrente.

Então quando chegou no top_three tinha mais do que 3 conteúdos com mais de 7 TabCoins, e o DESC indevido fez descartar o rank_group = 0 antes de descartar os menos pontuados em rank_group = 1.

O bom é que todos os conteúdos relevantes dentro da semana acabam entrando nas próximas janelas caso não se enquadrem nas primeiras, por isso ele ainda apareceu lá na 30ª posição, mas vou corrigir, pois ficou diferente do planejado.

Vou aproveitar para mudar os UNION para UNION ALL também, pois foi outra coisa que mudei durante os testes e agora não precisa mais usar o UNION, então podemos usar UNION ALL que é para ser mais rápido.

[aprendendofelipe]

As janelas estão assim:

rank_group	Janela \ Tamanho	Reservados	Máximo	Saldo mín.	Idade máx.
0	top_one	1	1	13	7 dias
1	top_three	2	3	7	2 dias
2	top_1_hour	3	6	1	1 hora
3	top_6_hours	9	15	2	6 horas
4	top_1_day	15	30	1	1 dia
5	top_3_days	30	60	1	3 dias
Todos	ranked	-	-	1	7 dias

Os slots reservados para cada janela podem não ser ocupados se não houver conteúdo que se enquadre nos requisitos. Nesses casos o slot fica disponível para a próxima janela, por isso a quantidade máxima de slots de cada janela é maior do que o reservado. E caso uma janela tenha mais conteúdos enquadrados do que slots disponíveis, os conteúdos menos pontuados ficam de fora dessa janela, mas eles sempre se enquadram em alguma das próximas janelas.

Reparem que o top_6_hours exige um saldo mínimo de 2 TabCoins. O efeito prático disso é que um conteúdo que não receber nenhum voto positivo dentro de 6 horas, mesmo tendo ficado no top_1_hour , só vai disputar slots com conteúdos a partir do rank_group 4.

Quaisquer sugestões são bem vindas.

[filipedeschamps]

Sugestão que me veio em mente agora é fazer como quando módulos expõem interfaces públicas, porém em beta/preview, que é expor a interface/propriedade/parâmetro, mas sob um namespace, como foi com o unstable_revalidate. Então a gente poderia expor um relevant_beta, que implementa uma strategy só pra ela (uma função) que depois é só questão de apontar o relevant oficial pra ela.

[filipedeschamps]

Complementando, poderia até ter uma página /relevantes_beta que é uma cópia simples do index da Home, só para termos um feeling real do resultado e conseguir mudar de uma aba para a outra e visualmente comparar as diferenças.

Em paralelo, estou me perguntando aqui se o top_one não vai dar a impressão que a Home está stale ou com conteúdos desatualizados, dado que é a posição de mais destaque e que eventualmente por continuar em primeiro vai aumentar a probabilidade de cada vez mais somar qualificações (ele não vai sofrer o efeito de deterioração pelo tempo, meio que vai ser o contrário). Hoje está o Aprenda Web Design em 4 minutos o que não acho que deveria ter recebido tanto upvote, mas mesmo assim com a deterioração por tempo não faria diferença, pois ele provavelmente seria derrubado pela gravidade exponencial.

Então entendo que apesar do item mais votado da semana ter a maior qualificação, não significa que em X+3 ele seja o mais relevante para quem acessa diariamente o TabNews.

Tava rabiscando aqui algumas ideias de janelas, não sei se fazem sentido, mas queria deixar registrado aqui caso tenha alguma utilidade:

1. Destacar os X itens (ex: 5) que estão melhores qualificados dentro de 5 horas, com no mínimo de 2 TabCoins (para essa seção sempre estar viva, se mexendo e pegar os outliers do momento).
2. Destacar os X itens (ex: 10) que estão melhores qualificados dentro de 12 horas, com no mínimo de 2 TabCoins (para essa seção tentar pegar os itens dentro de um "horário comercial" do dia)
3. Destacar os X itens (ex: 10) que estão melhores qualificados dentro de 24 horas, com no mínimo de 1 TabCoins (para essa seção dar alguma chance de conteúdos novos aparecerem na Home se assim precisar, e também deixar o usuário ler o que de melhor aconteceu nesse tempo).
4. Destacar os X itens (ex: 5) que estão melhores qualificados dentro da semana (para essa seção relembrar os melhores da semana, para o peso na Home não ficar somente no que está quente, mas também o que matou a pau na semana)

Uma dúvida: como tudo isso funciona com a paginação (offset)?

[aprendendofelipe]

Gostei da ideia da página /relevantes_beta, mas não gosto da ideia de fazer os testes no ambiente de produção, pois vamos ficar invalidando os caches a cada deploy.

Uma sugestão... A gente pode criar uma branch específica para esses testes, deixar essa branch protegida no GitHub e configurar variáveis de ambiente específicas dessa branch na Vercel pra ela acessar o banco de produção. Daí como a branch vai estar protegida, a gente só aprova merge de mudanças no algoritmo de ranqueamento, e nada mais.

Sobre a sua ideia com essas 4 janelas, vejo alguns problemas, mas vamos testar e ver o resultado.

Uma dúvida: como tudo isso funciona com a paginação (offset)?

Tudo normal... O Algoritmo primeiro ranqueia os conteúdos de 1 semana em memória e só depois aplica o LIMIT e OFFSET que foi passado. Por exemplo, agora tem 58 conteúdos relevantes, se acessar o link abaixo vai receber os 8 últimos do ranking:

https://www.tabnews.com.br/api/v1/contents?strategy=relevant&page=2&per_page=50