practice-uffs / practice-enquete Goto Github PK

A partir dos dados da reunião do dia 10/03/2021 informados na #1 dar continuidade para criar o banco de dados e iniciar o trabalho no back-end:

• Conforme #12 criar o diagrama ER com base em duas tabelas sendo Perguntas e Respostas;
• Após confirmação de diagrama ER consistente com um bom fluxo, então dar inicio ao banco de dados criando de fato as tabelas;

Visto que o back end possui uma arquitetura bem definida baseado no Clean Architecture, faz-se necessário documentar isso no README da API. Cada camada abstrata deve ter sua função explicada e relacionada com sua respectiva pasta. Dessa forma, possíveis contribuidores futuros podem continuar implementando seguindo este mesmo padrão.

Após concluir a prototipagem da issue #13 iniciar o desenvolvimento do front:

• Criar o header e footer sendo o mesmo do Mural
• Layout com caixa de texto e onde será renderizado a interpretação do texto
• Sidebar onde terá um esquema de arquivos como o sidebar do VScode
• Estrutura com parser para escrever e interpretar texto

Será editado e acrescentado mais checkbox ...

Header e footer foram implementados na issue #31
Porém alguns estilos não foram aplicados com sucesso. Segue abaixo ajustes necessários:

Como está:

Como deve ficar:

É necessário ajustar a publishSurvey que ela gere um um código de acesso para a enquete, o qual será utilizada na URL (e.g., enquete.com/Gu3al21). Além disso, espera-se que hajam casos de teste E2E automatizados.

É necessário criar uma query para a obtenção de enquetes de um usuário, o qual será chamada de getSurveysByUserId. Se necessário, deve ser definido um input de dados com validação e um type de dados para retornar ao client. Além disso, espera-se que hajam alguns casos de teste E2E automatizados.

A partir dos dados da reunião do dia 10/03/2021 informados na #1 dar continuidade ao front:
Conforme #12 criar o protótipo com base no design do Mural, sendo 4 páginas, 2 para versão desktop e 2 para versão mobile.
Ambas acessadas pelo browser e com menu de pastas lateral (sendo possível esconder, opcional) com as classificações de "Publicadas", "Rascunhos" e "Histórico". Características específicas de cada página:

• Página com caixa de texto e local para preview do texto escrito e interpretado em formato de enquete, a mesma página será usada na criação de novas enquetes e também ao acessar uma enquete iniciada dos "Rascunhos" (a diferença é que "Criar enquete" trás a página vazia e acessando uma dos rascunhos vai ser carregado os dados salvos ainda não publicados);

• Página posterior a criação de enquete ao acessar uma enquete específica para visualizar com opção de compartilhar a mesma, seja por QR-code ou link, com um local ao lado com as respostas dos usuários finais (se não existir o local vai estar em branco, mas é destinado as respostas);

• Após concluir passos acima criar nova (o) Issue/Checkbox com base nos dados citados na reunião do dia 10/03/2021, conforme inicio dessa publicação, para fins de organização dos componentes a serem implementados sem a perda do contexto/fluxo das páginas;

Por vezes, definir as mensagens de erro, sucesso, validação, etc é algo bem complicado de se lidar. Manter um certo padrão nas mensagens é importante, mas com elas espalhadas pelo código fica difícil de fazer isso. Portanto, deve-se implementar um sistemas para centralizar as mensagens da API para facilitar todo esse processo. À princípio, isso deve ser feito de forma simples, mas é possível aplicar alguma biblioteca feita para isso posteriormente.

O projeto da API (server) deve ser ajustado com features pré-prontas que podem ser alteradas posteriormente para criar o que o Enquete precisa.

Como este é um projeto novo, faz-se necessário alinharmos os objetivos que ele possui, quais funcionalidades deve apresentar e porque isso é importante. Portanto, peço que todos que tiverem uma visão sobre o que o Enquette deve ser, comentem aqui para que fiquemos bem alinhados quanto a o que deve ser desenvolvido. Ideias também podem ser comentadas.

É necessário criar uma query para obter uma enquete pelo seu código de acesso, o qual será chamada de getSurveyByCode. Se necessário, deve ser definido um input de dados com validação e um type de dados para retornar ao client apenas o necessário. Além disso, espera-se que hajam casos de teste E2E automatizados.

É necessário criar uma mutation para a criação de enquetes, o qual será chamada de createSurvey. Se necessário, deve ser definido um input de dados com validação e um type de dados para retornar ao client apenas o necessário. Além disso, espera-se que hajam casos de teste E2E automatizados.

É necessário criar uma mutation para a criação de uma resposta para uma enquete, o qual será chamada de createAnswer. Ela deve receber o id da enquete a ser respondida e do usuário que está respondendo (exceto para respostas anônimas). Além disso, só é possível responder enquetes publicadas, então é necessário verificar o estado da enquete. Se necessário, deve ser definido um input de dados com validação e um type de dados para retornar ao client apenas o necessário. Além disso, espera-se que hajam casos de teste E2E automatizados.

É necessário criar uma mutation para a edição de uma resposta, o qual será chamada de updateAnswer. Ela deve receber o id da resposta a ser editada para efetuar a ação, mas assim que for feito um sistema de autenticação, ele deve ser utilizado para verificar se o usuário logado pode ou não editar aquela resposta, isto é, se ele é dono dela. Além disso, só é possível editar uma resposta se a enquete for publicada e não estive fechada, então é necessário verificar o estado da enquete. Se necessário, deve ser definido um input de dados com validação e um type de dados para retornar ao client apenas o necessário. Além disso, espera-se que hajam casos de teste E2E automatizados.

É necessário criar uma mutation para o fechamento de uma enquete pelo seu id, o qual será chamada de closeSurvey. Ela deve alterar o estado para closed se o estado atual da enquete for published. Se necessário, deve ser definido um input de dados com validação e um type de dados para retornar ao client apenas o necessário. Além disso, espera-se que hajam casos de teste E2E automatizados.

Por um lado, permitir que o front defina o que uma pergunta possui permite que o front seja mais independente neste aspecto. No entanto, é papel do back end assegurar que os dados dos usuários fiquem consistentes e seguros. Portanto, é necessário definir as perguntas no back end de forma que tenham todos os parâmetros necessários para o seu bom funcionamento.

Cada pergunta deve ter um tipo, sendo que é possível deixar diversos tipos já pré-definidos, mesmo que nem todos sejam utilizados. Isso permitir melhorar o sistema com o tempo ao utilizar os muitos tipos implementados. Além disso, é necessário haver atributos como título, obrigatoriedade, opções, texto de ajuda, valor padrão, mínimo e máximo, entre outras possibilidades. Quanto mais formas de customizar a pergunta, mais robusto o sistema ficará para o futuro.

Ao ter todas essas características já definidas na API, ela se torna muito mais segura e o front pode se limitar a utilizar as ferramentas disponibilizadas ao invés de ter que criar do zero. Além disso, embora as perguntas precisem ser bem definidas, continuarão sendo armazenadas em JSON no banco de dados.

É necessário criar uma mutation para a publicação de uma enquete pelo seu id, o qual será chamada de publishSurvey. Ela deve alterar o estado para published se o estado atual da enquete for draft. Se necessário, deve ser definido um input de dados com validação e um type de dados para retornar ao client apenas o necessário. Além disso, espera-se que hajam casos de teste E2E automatizados.

O PRACTICE possui um template para a criação de repositórios, mas ele não foi usado para a criação deste. Portanto, faz-se necessário adicionar os arquivos necessários para que este repositório esteja de acordo com o template.

É necessário configurar os bancos de dados utilizando docker-compose (um local e um para testes automatizados), criar variáveis de ambiente .env e .test.env e estabelecer conexão na API.

É necessário definir melhor os requisitos deste projeto para que ele possa ser devidamente desenvolvido. O primeiro passo é, após o fechamento da issue #1, criar o diagrama ER do banco de dados e prototipar todas as telas que serão criadas.

Faz-se necessário a definição das tecnologias utilizadas neste projeto e de um guia sobre como instalá-las. Imagino que, como o client e o server são separados, poderia haver um README específico para cada um deles, pois possuem dependências diferentes. Portanto, no README principal do projeto estariam apenas as dependências que são comuns para ambos os projetos (como o NodeJS) e teria que haver links para os READMEs deparados para facilitar a navegação.

É necessário criar uma mutation para a edição de uma enquete, o qual será chamada de updateSurvey. Ela deve receber o id da enquete a ser editada para efetuar a ação, mas assim que for feito um sistema de autenticação, ele deve ser utilizado para verificar se o usuário logado pode ou não editar aquela enquete, isto é, se ele é dono dela. Além disso, apenas enquetes que estão no estado de rascunho podem ser editadas, então é necessário verificar este estado para efetuar a ação. Se necessário, deve ser definido um input de dados com validação e um type de dados para retornar ao client apenas o necessário. Além disso, espera-se que hajam casos de teste E2E automatizados.

Visto que este é um projeto aberto ao público, pode ser que outras pessoas queiram contribuir com o projeto. Portanto, é necessário preencher o ROADMAP com dados detalhados sobre o que este projeto pretende ser e quais as funcionalidades necessárias para se alcançar este objetivo. Imagino que isso esteja diretamente relacionado à issue #1.