bikedeboa / bikedeboa-api Goto Github PK

Eu queria muito poder detectar se tem bicicletários visíveis na tela. Parece que o jeito mais eficiente de fazer isso é eu passar um bounding box pro backend e ele encontrar pra mim se há bicicletários dentro desta caixa.

O cache dos navegadores e dos crawlers das redes sociais não irão perceber quando alguém modificar uma foto de um bicicletário já que salvamos no Amazon S3 sempre com o mesmo nome de arquivo (o ID do bicicletário).
Pra resolver isso basta dar uma refatorada no código do backend pra adicionar um identificador sequencial a mais no nome (ID-1, ID-2, ...) ou mais simples ainda um timestamp da hora que a foto é salva.

O endpoint de GET /local/light (getAllLight) é uma das chamadas mais importantes da API em termos de Experiência de Usuário, foi é o que bloqueia o uso do aplicativo no primeiro acesso até que o cliente tenha recebido todos dados de todos bicicletários.
Apesar do grande impacto no tempo de carregamento do app, esta chamada não é muito otimizada. Acredito que podíamos facilmente melhorar bastante a performance se não tivéssemos que calcular o número de reviews e a note média pra cada um toda vez que é chamado. Esse número poderia ser pré-computado, salvo no próprio Local e atualizado a cada operação sobre as avaliações.

Alternativamente, implementar cache no servidor (#12) pode já melhorar bastante isso, sem gerar maiores complexidades de implementação.

Assim a gente nao precisa deletar sugestões que forem atendidas, e podemos manter um histórico delas.

https://trello.com/c/Rzul3E4f/214-melhoramentos-se%C3%A7%C3%A3o-sobre-o-projeto

Endpoint deveria retornar:

• total de bicicletários
• total de avaliações
• total de visualizações

https://webapplog.com/http2-server-push-node-express/

Eu tenho usado o Mailchimp pra disparar emails pra alguns usuários, mas isso está sendo feito bem manualmente. Esse ticket é pra investigar como integrar com esse serviço pra de maneira automática:

• Cadastrar novos usuários na lista de email
• Disparar emails em pontos-chave da jornada do usuário, como: boas vindas, de cadastro de novo bicicletário, depois de 1 mês sem entrar no site, etc.
• ...dentre outras ideias do ticket do trello sobre Marketing (https://trello.com/c/7ARkaFp9/210-marketing)

Não tenho certeza, mas acho não temos middleware de cache do servidor. A ideia é que chamadas recentes à API não obriguem o servidor a trabalhar pra calcular tudo denovo e salve resultados pré-calculados. Isso é especialmente útil com alta demanda do servidor em um curto espaço de tempo.

Cuidado: cache é algo muito útil, mas muito fácil de fazer merda. Usar cache muito duradouro em respostas pode fazer o estado da aplicação parecer maluco, como se estivesse atualizando os dados quando na realidade está, mostrando dados antigos, etc.

O PageSpeed Insights reclamou que nossas respostas da API não tem header de max-age, ou seja, não aproveitam o cache dos navegadores.

Cuidado: cache é algo muito útil, mas muito fácil de fazer merda. Usar cache muito duradouro em respostas pode fazer o estado da aplicação parecer maluco, como se estivesse atualizando os dados quando na realidade está, mostrando dados antigos, etc.

Algumas leituras pra ajudar:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching
https://jakearchibald.com/2016/caching-best-practices/

Nós pagamos hoje 7 dolares por mês pra cada servidor nosso no Heroku, independente do tráfego que temos. Um amigo sugeriu fortemente tentarmos usar diretamente o serviço da AWS, que provavelmente ficará bem mais barato e é muito mais flexível e poderoso.

Assim poderemos indexar bicicletarios por cidade, listar cidades com mais bicicletarios, detectar se uma cidade nao tem bicicletarios, ...

https://trello.com/c/mw60cACw/232-desabilitar-avalia%C3%A7%C3%B5es-pra-quem-n%C3%A3o-t%C3%A1-logado