frontendbr / eventos-api Goto Github PK

Hoje o deploy tem que ser feito manualmente, seria interessante customizar o Travis para fazer o deploy quando houver um merge na master

O Github está emitindo um alerta de vunerabilidades, é interessante revisar isso para garantir que as dependências estão sem brechas.

Uma das coisas que eu acho que hoje está muito complexa nos testes é a suite de testes.
Quando eu fiz ela, não considerei aspectos de teste de unidade, teste de integração e afins.

Acho que vale um refactor nela, depois que a implementação do banco e do auth for definida, para simplificar e dar maior segurança nas nossas regras de negocio.

Como o projeto está proximo da "entrega", é legal começar a pensar na vida útil dele. Por isso, se faz necessário o guia para contribuir.
https://help.github.com/articles/setting-guidelines-for-repository-contributors/

Hoje a autenticação é realizada em um modelo de passport+github+firebase. Essa issue tem como intuito, remover esse modelo e atualizar ele para não usar o firebase.
Nessa issue deve ser realizado o seguinte cenário:

• O usuário deve ser capaz de se autenticar com o github
• A API deve ser capaz de identificar se o usuário autenticado é admin #49
• Deve ser enviado um token por requisição na API, para manter stateless
• A API deve garantir que o token é do Github, para evitar brechas de segurança
• Remover os lugares onde o firebase é usado e se necessário remover o passport também.

É necessário desenvolver o seguinte endpoint:
GET /event/{eventId} Find event by ID
Esse endpoint deve retornar um único evento.

É necessário desenvolver a estrutura do front para consumo da API. É preciso decidir se vamos usar anguar, react, webpack e afins.

Que tal adicionar o package "cross-env" como dependência para resolver o problema da falta da NODE_ENV configurada?

Após a #47 é necessário criar o schema para persistir o evento no mongo. Nessa issue deve ser realizado o seguinte cenário:

• Criar o schema do mongo para o Evento
• Remover as referências de persistência do Firebase para o evento(O firebase só será removido após tudo ter sido removido).
• Atualizar os métodos que realizam o cadastro, atualização, deleção e listagem do evento.

Hoje existem algumas "barreiras" para rodar o projeto do zero, seria ideal documentar as informações necessárias para entender como rodar este projeto.
Pontos importantes:

• Configuração do Github APP
• Configuração do Firebase Admin
• Configuração de Autenticação do Firebase com o Github
• Secrets e Deploy

É necessário atualizar e revisar a documentação da API para garantir que todos os endpoints que vão ser disponibilizados estão documentados:

https://frontendbreventosapi-eventosapi.wedeploy.io/api/docs/

É necessário desenvolver o seguinte endpoint:
DELETE /event/{eventId} Deletes a event
Esse endpoint é responsável por realizar a deleção fisica do evento. Considerações:

• É necessário estar logado
• É necessário ser um adm
• Somente eventos reprovados devem ser deletados

Adicionar um linter ao projeto. Eu sugiro ESlint utilizando o Standard Style. O que você acha @angeliski ?

Depois da #13 É preciso fazer o dashboard ondes os administradores vão poder aprovar/reprovar os eventos, deletar e fazer upload das fotos.
Para esse dash é necessário fazer login no github e ser adm.

É necessário desenvolver o seguinte endpoint:
PUT /event/{eventId} Updates a event
Esse endpoint deve atualizar o evento. Considerações importantes:

• É necessário estar logado
• É necessário ser um adm
• A atualização deve seguir o padrão PATCH (atualização parcial), ou seja, só é atualizado aquilo que for enviado

É necessário desenvolver o seguinte endpoint:
GET /event - List all events
Esse endpoint é responsável por listar todos os eventos aprovados considerandos os filtros:

• Mês (month) [ Janeiro a Dezembro]
• Estado (state) [SP, RJ,MG]
• Palavras Chave (keywords) [pode se usar um like no titulo e descrição, considerar a performance]
• offset (Paginação)
• limit (Paginação)

Opção postergada:
A opção de informar o mês através de números é para evitar problemas de internacionalização (Outubro, October)

É necessário desenvolver o seguinte endpoint:
POST /event/{eventId}/uploadImage uploads an image for the event
Esse endpoint serve para disponibilizar imagens para o evento. Considerações:

• É necessário estar logado
• É necessário ser um adm

Essa issue é para a revisão co código ser feita antes do lançamento da V1. Qualquer comentário e sugestão é bem vinda.

É necessário desenvolver os endpoints de Login. Talvez seja interessante gerenciar isso com o Passport ou delegar direto para o Firebase.

@angeliski O que acha de utilizar o babel para transpilação do código NodeJS ? Assim poderemos utilizar as features mais recentes do JavaScript que não tem implementada ainda na V8 😄.

Desenvolver uma POC para validar a utilização de MongoDB(mLab) + NodeJS + Autenticação com GitHub
Repositório da POC

The devDependency nodemon was updated from 1.18.5 to 1.18.6.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

nodemon is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Hoje é necessário guardar a informação de quem são os administradores. Idelmente, será salvo apenas o email do usuário, identificando ele como administrador.Nessa issue deve ser realizado o seguinte cenário:

• Criar o schema que permite registrar um administrador
• Atualizar os locais onde a verificação de administrador é feita para simplificar conforme o mongo
• Remover as referências do firebase e do firebase-admin onde necessário(O firebase só será removido após tudo ter sido removido).

Galera, tive uma ideia e já até comentei com alguns, de utilizar uma stack um pouco diferente, mas bem simples! Seria criar uma API utilizando NodeJS e como banco de dados utilizar LokiJS, pra quem não conhece pode dar uma olhada aqui, é um banco NoSql simples e muito bacana!

Optamos por usar o mongodb como nossa base de persistência. Para isso, vamos usar o serviço do mongo lab. Nessa issue deve ser realizado o seguinte cenário:

• Adicionar as configurações de start do mongo no arquivo de configuração
• Adicionar os testes de integração (mongo-in-memory ou outro para os testes)
• Atualizar o README explicando qual tecnologia usamos e como alterar as configurações (Se necessário)

Pode se usar a POC de referência.

É necessário desenvolver o seguinte endpoint:
GET /event/findByStatus Finds Events by status
Esse endpoint segue a ideia do #3 a diferença entre eles é que nesse caso é necessário estar logado e é possível listar também os eventos pendentes.

The dependency mongoose was updated from 5.4.13 to 5.4.14.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

mongoose is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

Depois de terminar a #13 é preciso desenvolver o cadastro dos eventos via formulário. Para isso não é necessário login.

Adicionar ao nodemon para melhorar o ambiente de desenvolvimento.

Não baixei o projeto para estudá-lo e entender a implementação, mas uma coisa que me chamou a atenção no readme foi o fato de utilizar o Firebase e o Wedeploy. Qual a função do Firebase no projeto? Questiono isso, pois se a API vai ficar no wedeploy, acredito que dê pra fazer tudo com os próprio serviços deles (hosting, auth, db)

[]s

É necessário desenvolver o seguinte endpoint:
POST /event - Add a new event
Esse endpoint é responsável por cadastrar um evento. Todo os eventos devem entrar com o status pendente de aprovação para que os moderadores tenham que aprovar.

• Titulo (title)
• Data (dateEvent)
• Local (local)
• CEP (zip) (Opcional)
• Descrição (shortDescription)
• Valor (price) [0 para eventos gatruitos]
• Website do evento (eventLink)

Em caso de sucesso, o retorno deve ser 200. Pode se retornar 400 em caso de erro de preenchimento.