Adiciona paginação ao endpoint GET /users

[Rafatcb]

Mudanças realizadas

Resolve a parte do backend do issue #1675.

Passei o getPagination para um outro arquivo para poder ser reutilizado e também aproveitei para refatorar algumas coisas simples, como substituir http://localhost:3000 por orchestrator.webserverUrl em alguns testes.

• Paginação em GET /api/v1/users com per_page e page, ordenado pela data de atualização (updated_at, mais recentes primeiro).

Tipo de mudança

• Nova funcionalidade.

Checklist:

• As modificações não geram novos logs de erro ou aviso (warning).
• Eu adicionei testes que provam que a correção ou novo recurso funciona conforme esperado.
• Tanto os novos testes quanto os antigos estão passando localmente.

[vercel]

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

Name	Status	Preview	Comments	Updated (UTC)
tabnews	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 8, 2024 1:20am

[aprendendofelipe]

Show @Rafatcb! 💪

Pensando em simplificar a implementação/manutenção, estou em dúvida se precisamos de todas essas diferentes estratégias. A que você chamou de recently_updated já não seria suficiente para a necessidade da moderação?

Fiz comentários no código.

[aprendendofelipe]

E se apenas substituir a findAll pela nova findWithStrategy já apropriada para /api/v1/users?

A tentativa de deixar a findAll flexível acaba tornando ela mais complexa do que o necessário, e dificultando seu entendimento, como acontece em content.findAll(). Em models/content isso até se justifica, mas aqui não estou vendo necessidade.

[Rafatcb]

Você diz para retornar a contagem de usuários, os resultados de forma ordenada e com paginação sempre? Se for isso, o findAll é utilizado no PR #1638, então teria alguns pontos negativos pela contagem não ser necessária naquela situação e pela paginação poder, eventualmente, causar um bug difícil de identificar (se futuramente termos um evento que envolva mais contas do que o tamanho padrão da paginação).

Hoje o findAll está ordenado por created_at ASC, o que já prejudicaria o desempenho no outro PR, mas não precisaria dessa ordenação por padrão.

[Rafatcb]

Eu deixei as funções findAll e findAllWithPagination separadas para deixá-las menos flexíveis. Se você ter uma sugestão melhor de usar uma única função tendo em vista os pontos que levantei no meu comentário anterior, diga que eu modifico.

[aprendendofelipe]

Precisa mesmo de firstUser e secondUser? Deve ser suficiente criar aqui apenas as variáveis privilegedUser e defaultUser, já que são duplicadas com as outras duas.

unprivilegedUser me parece menos adequada do que defaultUser, que já é o padrão adotado em todos os testes.

E deve compensar também declarar aqui a privilegedUserSession, que pode ser atribuída em beforeAll(). O que acha?

[Rafatcb]

Precisa mesmo de firstUser e secondUser?

Não é necessário, mas facilita o entendimento dos testes nas comparações expect(responseBody).toStrictEqual, onde pelo nome da variável o leitor consegue saber que um foi criado antes do outro.

unprivilegedUser me parece menos adequada do que defaultUser, que já é o padrão adotado em todos os testes.

Ok.

E deve compensar também declarar aqui a privilegedUserSession, que pode ser atribuída em beforeAll(). O que acha?

Isso pode ser feito sim 👍

[Rafatcb]

Pensando em simplificar a implementação/manutenção, estou em dúvida se precisamos de todas essas diferentes estratégias. A que você chamou de recently_updated já não seria suficiente para a necessidade da moderação?

Seria sim. Pensei nas outras apenas para ficar num padrão parecido com o /contents, que possui as estratégias old e new, por exemplo, mas posso deixar apenas com uma ordenação.

[Rafatcb]

Você diz para retornar a contagem de usuários, os resultados de forma ordenada e com paginação sempre? Se for isso, o findAll é utilizado no PR #1638, então teria alguns pontos negativos pela contagem não ser necessária naquela situação e pela paginação poder, eventualmente, causar um bug difícil de identificar (se futuramente termos um evento que envolva mais contas do que o tamanho padrão da paginação).

Hoje o findAll está ordenado por created_at ASC, o que já prejudicaria o desempenho no outro PR, mas não precisaria dessa ordenação por padrão.

[Rafatcb]

Precisa mesmo de firstUser e secondUser?

Não é necessário, mas facilita o entendimento dos testes nas comparações expect(responseBody).toStrictEqual, onde pelo nome da variável o leitor consegue saber que um foi criado antes do outro.

unprivilegedUser me parece menos adequada do que defaultUser, que já é o padrão adotado em todos os testes.

Ok.

E deve compensar também declarar aqui a privilegedUserSession, que pode ser atribuída em beforeAll(). O que acha?

Isso pode ser feito sim 👍

[aprendendofelipe]

Já aprovei, mas vejam, por favor, se faz sentido mexer nos pontos que comentei no código 🤝

[aprendendofelipe]

Em produção! 🚀🚀🚀

Já adicionei a feature read:user:list para os moderadores 😉