Migrar o gerenciamento de dados de um formato JSON para um banco de dados relacional utilizando um BACKEND

[diegorogerssa]

Descrição do recurso

Atualmente, os termos do Diciotech são gerenciados via Pull Requests (PRs) no repositório GitHub, com validação por Continuous Integration (CI). O formato dos termos pode ser simples ou incluir exemplos de código, como:

{
  "title": "Termo técnico",
  "description": "Explicação sobre o termo",
  "tags": ["Tag1"]
}

ou:

{
  "title": "Termo técnico",
  "description": "Explicação sobre o termo",
  "content": {
    "code": "Código de exemplo"
  },
  "tags": ["Tag1", "Tag2"]
}

Embora esse fluxo funcione perfeitamente, ele exige conhecimento técnico de Git e JSON, o que dificulta a participação de usuários menos familiarizados. A proposta é criar um backend com uma aplicação web para gerenciar os termos, tornando o processo mais acessível e organizado.

No novo modelo, o login será obrigatório apenas para usuários que desejarem adicionar novos termos.
Além disso, a aplicação web terá páginas dedicadas para:

• Adicionar Termos: Um formulário intuitivo para que os usuários submetam novos termos de maneira prática.
• Gerenciar Termos: Uma interface administrativa onde os administradores poderão revisar, aprovar, rejeitar ou sugerir alterações nos termos enviados.

Motivação

• Acesso Descomplicado:
  Qualquer pessoa poderá consultar os termos sem a necessidade de login.

• Facilidade para Contribuição:
  O novo sistema elimina a complexidade de abrir PRs e editar arquivos JSON manualmente.

• Controle e Transparência:
  O login será obrigatório para quem enviar novos termos, associando cada contribuição a um usuário e garantindo maior responsabilidade.

• Organização do Repositório:
  O código do projeto ficará separado do conteúdo dinâmico, centralizando o gerenciamento dos termos na aplicação.

• Escalabilidade:
  O sistema será mais robusto e preparado para lidar com um maior número de usuários e termos de forma eficiente.

Sugestão de implementação

Para Usuários:

• Login Opcional:
  Qualquer pessoa pode consultar termos. O login será necessário apenas para enviar novos termos.
• Formulário Completo:
  • Título: Nome do termo.
  • Descrição: Explicação detalhada.
  • Tags: Palavras-chave associadas (opção para sugerir ou selecionar tags existentes).
  • Conteúdo: Campo para adicionar exemplos de código ou informações extras.
  • Botão Enviar: Submete o termo para revisão por um administrador.

Para Administradores:

• Gerenciamento de Termos:
  • Lista de termos pendentes, aprovados ou rejeitados.
  • Visualizar detalhes do termo, como título, descrição, tags e conteúdo.
• Aprovação e Rejeição:
  • Aprovar: Publica o termo na base pública.
  • Rejeitar: Envia uma notificação ao autor com o motivo da rejeição.
• Sugestão de Alterações:
  • Permitir editar e enviar sugestões ao autor para ajustes antes da aprovação.
• Filtros e Busca:
  • Localizar termos por título, tags ou status.

Essa implementação simplifica o fluxo, melhora a experiência do usuário e organiza o conteúdo de forma centralizada e escalável. 🚀

[levxyca]

Obrigada pela contribuição @diegorogerssa! Atualmente temos essa PR #267 em andamento, estou entendo como essas duas implementações podem se impactar para não gerarmos perca de trabalho e entender como podemos se complementar 😀 Vou deixar aqui com a tag de discussão para irmos conversando sobre.

Se você quiser dar uma olhada na PR em construção #267 também pra dar seus pitacos 🚀

[george-gca]

Eu acho que essa issue é uma ideia de uma feature futura (não sei quão futura), enquanto a minha é um código pra entrar agora. Então não vejo impacto agora, mas dependendo de como isso se integraria no código de front, não vejo problemas em isso entrar. Quer dizer, vejo alguns problemas, mas não de isso ser adicionado ao projeto. Vou destrinchar um pouco.

Integração com o front

Atualmente a submissão de novos termos é via json, que tem todos os pontos que já foram ditos. Na #267 eu mudei pra ser um yml que é mais legível pra um ser humano, mas que depois é convertido pelo build pra um json e que vai ser lido pelo front como atualmente é feito. Se esse backend novo gerasse um yml (ou um json) pra ser lido pelo front, o impacto pra mim seria zero, com exceção das traduções.

Suporte a vários idiomas

Ainda na #267 eu adiciono suporte a várias línguas. Isso é feito tendo arquivos yml com os termos por idioma. Tem um yml por letra inicial, mas isso foi criado pra evitar ao máximo merges no código. Eu imagino que quando a pessoa desenvolvedora for submeter uma PR com novos termos, ela tem 2 opções:

• adicionar também as traduções
• criar issues relatando a falta das traduções e indicando o idioma, pra que alguém da comunidade possa fazer essa parte

temos que pensar também como isso ficaria nesse sistema. Eu acho que estamos acabando por adicionar muitos requisitos, mas se tem quem saiba implementar eu acho ótimo haha.

PRs vs interface web

Atualmente a submissão de PRs tem um benefício que é ser revisado por pessoas não admin. Eu mesmo já revisei algumas PRs que achei que o texto podia ser melhorado. E todo mundo (que saiba usar o GitHub claro) pode ir lá e dar seu pitaco, deixar comentários, etc. Um sistema desses meio que limita somente aos admin revisar e deixar opiniões. A menos que tenha alguma forma de qualquer pessoa comentar, mas aí seria qualquer pessoa com login, o que leva no próximo ponto

Login

Eu imagino que login envolva ter uma base de dados em algum lugar de logins e senhas, a menos que usemos algo como login via GitHub, Google, etc. Aí nisso também entra os comentários. Nesse ponto de repente até poderíamos usar o giscus pros comentários, não sei como tu vês esse processo sendo feito.

Integração com o GitHub

Eu imagino que tenha como fazer tudo se integrar ao build (ex: ao aceitar um novo termo). Mas não tenho ideia de como se faz.