Este é o desafio Spotippos, o code-challenge do VivaReal.
Você precisa ter a linguagem Crystal versão 0.21.1 instalada para poder rodar ou compilar o projeto. Você também pode usar o Dockerfile incluso para rodar direto no Docker.
Instale as dependências:
crystal depsDepois, você pode usar o atalho do Crystal para compilar e rodar direto:
crystal ./src/spotippos.crOu pode compilá-lo e rodar a versão compilada:
crystal build --release ./src/spotippos.cr
./spotipposO webserver estará disponível na porta 3000.
Ao fazer as chamadas para o webserver, é importante definir o cabeçalho
Content-type: application/json.
KEMAL_ENV=test crystal specIMPORTANTE: Se você esquecer o KEMAL_ENV=test, o Kemal vai subir o servidor
e travar os testes para sempre :(
Construa a imagem:
docker build -t spotippos .Crie um container através dela, expondo a porta que você quiser para acessá-lo:
docker run -p 3000:3000 spotipposPara rodar os testes no Docker, faça:
docker run -e KEMAL_ENV=test spotippos crystal specUsei a linguagem Crystal, que é uma linguagem fortemente inspirada em Ruby, porém estaticamente tipada e compilada através do LLVM, o que garante ela rodar rapidamente, com uma boa performance e prevenindo erros de tipagem em tempo de compilação. Ela ainda está em beta, na versão 0.21.1, e por enquanto só roda em Linux e OS X. A vantagem dela é que é tão parecida com Ruby que qualquer Rubista, com pouquíssimo tempo de aprendizagem, consegue ler e escrever código Crystal, que tem uma boa performance, por ser compilada.
A camada de roteamento é feita usando Kemal, um framework inspirado no Sinatra.
Para os testes, usei Spec2, inspirado no RSpec.
O motivo de eu ter usado essa linguagem é que eu queria escrever alguma coisa nela e, bem, o teste veio a calhar :P Acho que não rolaria usar em produção pois o ecossistema ainda é bastante jovem, a documentação é pouca e as mensagens de erro ainda estão muito crípticas.
No repositório da aplicação estou acessando uma variável de classe (@@storage)
que representa a persistência dos dados. Tentei representar um storage externo,
e a ideia é que caso fosse usado num cenário real, ele fosse facilmente
substituível.
Ao iniciar o projeto, uso o método Fixtures.load_fixtures para carregar os
dados providos. Não criei opções para passar arquivos de input diferentes, mas
é uma modificação trivial se precisar ser feito.
Um próximo passo seria paginar a resposta da rota GET /properties, por
exemplo, já que ela pode retornar milhares de imóveis.
Por simplicidade, estou assumindo que todos os dados numéricos do imóvel são inteiros, apesar de alguns conceitualmente poderem ser decimais "no mundo real".
Uma coisa que ficou um pouco esquisita é que várias conversões de Integer32 para Integer64 ficaram espalhadas pelo código. Isso aconteceu pois a lib que eu usei para atender as requisições web e os JSONs trabalha com Int64 e o core da linguagem com Int32. Não corri muito atrás de "resolver" isso pela questão do tempo, então o código ficou mais feio do que poderia.
Não escrevi specs para as Entities, pois são "POCOs" (Plain Old Crystal Objects), nem para os Containers, pois apenas facilitam o uso das bibliotecas em desenvolvimento.
Escrevi os testes pros Controllers acessando direto o endpoint, como um teste
de integração, para não ter que simular o env (contexto HTTP) do Kemal.
Não usei nenhuma lib para fazer factories ou fixtures pois todas que testei estavam bem bugadas :P Por conta disso, faço a inicialização do ambiente de teste de forma verbosa, criando todos os objetos e inserindo-os no storage.