Esse recurso ainda não tem uma definição no Schema da API (conforme definido no schema da API training-center/R2D2#40). Então é necessário primeiro criar a definição dele.

Importante:

Os endpoints sempre devem atender o schema para que a evolução da plataforma possa ser independente entre o backend e o frontend. O schema é a interface de comunicação entre as plataformas.

Operações:

• Cadastro
• Atualização
• Listagem
• Exclusão

Filtros para listagem:

• descricao
• limit [ default = 100 ]
• offset [ default = 0 ]

Informações adicionais

A ideia é o endpoint servir para listar o recurso Skill(Tabela skills, conforme modelo)

Informação do documento de requisitos:

Precisamos de algo para cadastrar as especializações e depois as pessoas poderem selecionar isso de uma lista, evitando assim a desnormalização da informação que aparece na tela

Schema

A ideia principal desse endpoint é ser capaz de atender o recurso do tipo Materia (conforme definido no schema da API training-center/R2D2#40).

Importante:

Os endpoints sempre devem atender o schema para que a evolução da plataforma possa ser independente entre o backend e o frontend. O schema é a interface de comunicação entre as plataformas.

Operações:

• Cadastro
• Atualização
• Listagem
• Exclusão

Filtros para listagem:

• descricao
• limit [ default = 100 ]
• offset [ default = 0 ]

Informações adicionais

A ideia é o endpoint servir para listar o recurso Area(Tabela Areas, conforme modelo)

Informação do documento de requisitos:

Precisamos de algo para cadastrar as especializações e depois as pessoas poderem selecionar isso de uma lista, evitando assim a desnormalização da informação que aparece na tela

Schema

Definir qual banco de dados iremos utilizar (Mysql, Postgres, etc..)

Definir as tabelas e relacionamentos.

Linting

Conforme Ata 26-11-2017 implementar no Hades ferramenta de verificação de estilo e código (lint). Em pesquisa verifica-se que uma das ferramentas possíveis é o eslint. Contudo, é preciso definir o estilo que será aplicado para a formação do código.
O eslint oferece alguns estilos:

• Google
• Airbnb
• Personalização

Já temos uma ideia de que estilo será seguido? No Front-end o eslint está sendo utilizado.

Ficou definido que teremos o login via Github.
Precisamos criar o mecanismo que será responsável por realizar isso, em conjunto com o R2D2.
É importante ver as considerações apontadas na issue #6
Uma sugestão é usar o Passport, mas isso pode ser discutido.
É interessante pensar em uma implementação quer permita uma evolução para outras estratégias de login.

Na discussão da estrutura do banco de dados surgiu a duvida de como vamos armazenar os dados de login.
Acho que esse discussão deve ser um pouco mais ampla, então acho bom centralizarmos nesse issue, depois adaptamos a estrutura do banco para o que definimos.

Algumas estratégias que foram levantadas pelo @angeliski

• OAuth2
• JWT

A ideia principal desse endpoint é ser capaz de atender o recurso do tipo pessoa (conforme definido no schema da API training-center/R2D2#40).

Importante:

Os endpoints sempre devem atender o schema para que a evolução da plataforma possa ser independente entre o backend e o frontend. O schema é a interface de comunicação entre as plataformas.

Operações:

• Cadastro
• Atualização
• Listagem

Filtros para listagem:

• Tipo [MENTOR, MENTORADO]
• limit [ default = 100 ]
• offset [ default = 0 ]

Informações adicionais

A ideia é o endpoint servir tanto para listagem de mentores, como de mentorados, sendo necessário apenas a alteração do filtro.

Informação do documento de requisitos:

• Precisamos listar todas as pessoas cadastradas no sistema com filtros para exibir somente mentor(a), somente gente buscando mentoria, somente gente que já recebe mentoria, somente níveis iniciantes, somente nível intermediário, somente quem já é atuante

Schema