O objetivo do teste é avaliar seu conhecimento em Laravel e respeito às boas práticas de programação e organização de código.
- Payt - Teste Backend
O Plano do projeto é um sistema de redirects, que redirecionará o usuário para a URL destino cadastrada e criará um registro de acesso.
O desenvolvimento possui 5 etapas:
- Proteção de Ids na API com package Hashids
- CRUD de Redirects: uma API RESTful para gerenciar os redirects
- Redirecionamento: Por exemplo, se o usuário acessar
http://localhost:8000/r/ABCD123
, ele será redirecionado parahttps://google.com
conforme registrado na model. - Estatísticas de Acesso: Endpoint que retorna as estatísticas de acesso do redirect
- Factories e Testes: Testes unitários e de integração para a API utilizando PHPUnit
- Não se preocupe com a autenticação dos usuários
- Você pode instalar outros pacotes que achar necessário ou forem úteis para o desenvolvimento do projeto
- A estrutura em si está ao seu critério, esta é apenas a ideia inicial. Melhorias no escopo são bem-vindas
⚠️ Após a leitura do teste, comece a preencher o arquivofeedback.md
com suas considerações sobre o teste
Model | Descrição |
---|---|
Redirect | Armazena as informações para execução do redirect |
RedirectLog | Armazena os logs de acesso ao redirect |
/r/{redirect}
: Redireciona para a URL de destino/api/redirects
: Resource de redirects/api/redirects/{redirect}/stats
: Retorna as estatísticas de acesso do redirect/api/redirects/{redirect}/logs
: Retorna os logs de acesso do redirect
Os ids na API não devem ser expostos, serão então substituídos por um hash.
- Usando o package
vinkla/hashids
, substitua os Ids dos redirects por um hash - Crie um atributo
code
que será o hash gerado pelohashids
a partir doid
- O atributo
code
deve ser utilizado para a busca de um redirect - Através de Dependency Injection, Controller deve receber a Model já instanciada com o Redirect buscado
Utilize o FormRequest para validação dos dados
- Deve ser possível criar um redirect passando apenas a URL de destino no payload em JSON
- Ela pode ou não conter query_params. Exemplo:
https://google.com
ouhttps://google.com?src=facebook
- Url de Destino deve de ser HTTPS
- Url de Destino deve ser validada retornando um erro caso a URL retorne um status diferente de 200
- Url de Destino não pode apontar para a própria aplicação
- A listagem de redirects, deve retornar as seguintes informações:
- Código
- Status (ativo/inativo)
- URL de destino
- Último acesso
- Data de criação
- Data de atualização
- Deve ser possível atualizar a URL de destino
- Deve ser possível ativar/desativar o redirect
- Deve ser possível deletar um redirect
- Quando deletado, o redirect será passado para desativado e receber um SoftDelete
- O redirecionamento deve ser feito através da rota
/r/{redirect}
- Deve ser feito um registro de acesso no
RedirectLog
com as informações da request- Id da Redirect
- IP da request
- User-Agent da request
- Header referer da request
- Query Params da request
- Data e hora do acesso
- Se a request vier com query params, eles devem ser passados para a URL de destino
- Se o redirect já possui query params, eles devem ser fundidos com os da request, a request tem prioridade
- Se a request vier com um query params que possuem valores vazios, eles devem ser ignorados
- Se a request vier com query params vazios e o redirect possuir a chave
- Deve ser possível acessar as estatísticas de acesso de um Redirect através
/api/redirects/{redirect}/stats
- Estatísticas de acesso devem conter:
- Total de acessos
- Total de acessos Ùnicos (IPs únicos)
- Top Referrers (Headers referer mais comum entre os Redirecionamentos)
- Uma array com total de acessos dos últimos 10 dias (Ex:
[{ "date": "2021-01-01": "total": 10, "unique": 8 }]
)
Crie as factories para os models e os testes para a API
Usando o PHPUnit, crie testes unitários e de integração para a API
- Criação de um redirect
- Criação do redirect com URL válida
- Criação do redirect com URL inválida por
- DNS inválido
- URL inválida
- URL apontando para a própria aplicação
- URL sem HTTPS
- URL retornando status diferente de 200 ou 201
- URL inválida pois possui query params com chave vazia
- Um teste para validação das estatísticas de acesso
- Verificar se os redirects vindo do mesmo ip são contados como um único acesso no total de acessos únicos
- Verificar se os headers referer são contados corretamente
- Verificar se os acessos dos últimos 10 dias estão corretos
- Verificar se os acessos dos últimos 10 dias estão corretos quando não há acessos
- Verificar se os acessos dos últimos 10 dias estão corretos quando há acessos
- Verificar se os acessos estão pegando somente os últimos 10 dias
- Um teste para validação dos query params inseridos na URL de destino
Merge Test | Query Params da Request | Query Params no Redirect | Resultado |
---|---|---|---|
Juntando duas origens | utm_source=facebook |
utm_campaign=ads |
utm_source=facebook&utm_campaign=ads |
Priorizando à Request | utm_source=instagram |
utm_source=facebook&utm_campaign=ads |
utm_source=instagram&utm_campaign=ads |
Merge ignorando chave vazia na Request | utm_source=&utm_campaign=test |
utm_source=facebook |
utm_source=facebook&utm_campaign=test |
- Organização do código(reusabilidade, legibilidade e manutenibilidade)
- Performance das queries
- Testes unitários e de integração
- Estrutura no banco de dados, indexes, chaves estrangeiras, etc
- Estrutura de commits
- Clone este repositório
- O projeto deve ser entregue em um repositório público no Github ou enviado por email contendo o
.git
para comparação com o projeto inicial - Não esqueça de preencher o arquivo
feedback.md
com suas considerações finais