Modelagem: Usuário e Perfil

[alexandre]

Para não precisarmos documentar o projeto depois, eu acho interessante usarmos alguma tag como RFC (Request For Comments) para ao menos discutir detalhes iniciais e conforme

Usuário

O usuário é utilizado apenas para autenticação. Dados como nome, bairro e etc estão relacionados a um perfil (e.g. Citzen e Councillor). Mesmo o projeto sendo um complemento ao CDMB, eu acho que podemos desenvolvê-lo de uma maneira independente e assim permitir que ele seja utilizado em outras iniciativas.

# apenas para exemplificar
class User:
    id
    uuid
    username
    email
    password
    <profile (backref)>

Perfil

Perfil é utilizado para representar os dados do usuário [do sistema] que não estão relacionados a autenticação. Por enquanto, eu só consigo pensar em dois perfis: Cidadão e Vereador. O vereador também é um cidadão, mas dentro de uma "conversa" (pergunta/resposta/réplica/etc) ele atua em outro perfil. (nada impede o vereador de utilizar o sistema enquanto cidadão)

# apenas para exemplificar
class Profile:
    id
    uuid
    name
    email
    state
    country
    <user>

Observação

Essa é apenas a primeira versão. Podemos discutir a partir desse ponto e atualizar esse texto. Eu não entrei no detalhe sobre relacionamento, implementação e etc, mas qualquer ideias relacionada é valida...

[andresmrm]

Não sei se entendi, mas no modelo que tínhamos pensado a autenticação e perfil seria responsabilidade do Viralata. Então o PerguntaCamara não teria a senha e nem o perfil.
https://github.com/okfn-brasil/viralata

[alexandre]

Eu já nem lembrava do viralata. Mas eu acho que faz sentido manter o perfil, já que ele não tem uma relação obrigatória com a autenticação (e.g. filtrar mensagens enviadas, relacionar respostas e conversas).

Eu dei uma olhada no código do tagarela para tentar entender como implementar o viratala no pergunta-camara, mas não tenho certeza se eu entendi bem.

Eu vou pular essa parte e assim que estiver funcionando, eu atualizo essa issue, ok? Aproveitando: você acha que faz sentido manter esse tipo de issue ou é melhor escrevermos direto na wiki e abrir issues apenas para discutir as alterações?

[ ]'s

[andresmrm]

Depende de que tipo de informações teria nesse perfil... Minha única preocupação é duplicar informações tanto no Viralata como no PerguntaCamara.

Para ser sincero não lembro mais exatamente o que tinha que fazer para funcionar com o Viralata.
Mas acho que era só configurar a chave (o módulo precisa ter acesso à chave pública que o Viralata está usando). E dai você pega as informações do token desse jeito:
from viralata.utils import decode_token
https://github.com/okfn-brasil/tagarela/blob/master/tagarela/views.py#L294

Acho que faz sentido manter isso nas issues sim.

[alexandre]

A ideia é ter o que não deveria [IMO] ter no viralata (e.g.: email e bairro).

Na branch `pyramid-bootstrap-, eu implementei uma auth simples com jwt. Vou deixar parado esas parte para conseguir terminar o CRUD de mensagens/conversa. Assim que eu terminar essa parte, eu volto para usar o viralata.

[andresmrm]

Então, quando eu precisei adicionar um texto de perfil para o usuário, eu fiquei na dúvida sobre onde colocar. As opções principais que pensei eram: ou colocar no Viralata, ou criar um microserviço só para perfil de usuário. Eu realmente não estava querendo criar mais um microserviço só para isso. Me pareceu um exagero para só mais um ou outro campo de texto, e seria mais um módulo para dar manutenção, hospedar, etc.
Colocar informações de perfil em mais de um microserviço me pareceu ruim, pois duplicaria essas informações, aumentando a complexidade para gerenciar isso, especialmente quando ocorrerem modificações, poderia gerar estados inconsistentes etc. Se é para colocar em um só microserviço que já existe, a melhor escolha para mim continua sendo o Viralata, que já é quem cuida de certo modo dos usuários.
Se o PerguntaCamara vai ter dados de perfil, o EsicLivre também teria que ter, e o Tagarela possivelmente também, etc.
Mas eu estava pensando em um modelo de usuário o mais simples possível. Sem distinção, por exemplo, entre cidadão e vereador (algo que ainda não vejo muita necessidade...). Se for complicar, talvez faça sentido criar um microserviço só para perfil, ou até cada módulo gerenciar isso (se tiverem regras específicas de perfil e não dê para deixar em um microserviço genérico. Mas eu realmente ainda não vejo necessidade para tudo isso...

[alexandre]

O perfil não tem a ver com autenticação, então eu acho que não faz sentido ficar no Viralata.

Se o PerguntaCamara vai ter dados de perfil, o EsicLivre também teria que ter, e o Tagarela possivelmente também, etc.

Eu acho que deveriam sim.

Ainda pensando em micro serviço: não é duplicar, já que um serviço não sabe da existência do outro. O PerguntaCamara é uma ferramenta para o Cuidando, mas não sabe da existência do EsicLivre.

Essa é a parte que eu não fico confortável com micro serviço: não tenho domínio do negócio, então optaria por um monolítico até ficar um pouco mais confortável.

Vou fazer o seguinte: para simplificar a modelagem, eu vou remover o perfil e deixar apenas usuário (um perfil simples apenas para registrar "quem fez a pergunta").

[andresmrm]

O perfil não tem a ver com autenticação, então eu acho que não faz sentido ficar no Viralata.

O perfil me parece ter mais a ver com autenticação do que com perguntas para a câmara, porque tanto perfil como autenticação são coisas relacionadas ao usuário...

Eu acho que deveriam sim.

Todos guardariam e-mail, por exemplo? E se o usuário quiser trocar o e-mail? A interface teria que mandar trocar em todos os micro serviços? E se der falha com um mas não nos outros?

Vou fazer o seguinte: para simplificar a modelagem, eu vou remover o perfil e deixar apenas usuário (um perfil simples apenas para registrar "quem fez a pergunta").

Você lembra como fizemos no EsicLivre?
https://github.com/okfn-brasil/esiclivre/blob/master/esiclivre/models.py#L229-L240

Essa é a parte que eu não fico confortável com micro serviço: não tenho domínio do negócio, então optaria por um monolítico até ficar um pouco mais confortável.

Você prefere fazer esse módulo em um modelo monolítico, sem usar o Viralata? Pensando nele de forma isolada me parece ok. O problema que vejo seria para usar depois ele no Cuidando...

Ainda pensando em micro serviço: não é duplicar, já que um serviço não sabe da existência do outro. O PerguntaCamara é uma ferramenta para o Cuidando, mas não sabe da existência do EsicLivre.

Humm, não sei se entendi o que você quer dizer, mas acho que é: se ele não sabe da existência dos outros serviços, como ele vai pegar as informações deles? No caso, se o PerguntaCamara não tem essas informações de perfil, como ele vai usá-las? É isso?

Se for, eu acho que é uma boa pergunta. hahah
Acho que o PerguntaCamara, se feito no modelo de micro serviço, não precisa da maior parte das informações de perfil (por exemplo, "state" e "country"). Agora, e-mail pode ser interessante.
Uma coisa que estávamos pensando era enviar avisos por e-mail quando a pergunta tivesse uma resposta. Mas se o EsicLivre ou o PerguntaCamara não tem o e-mail, como fazer?
Uma possibilidade que pensei seria um serviço só para avisos por e-mail, e ele cuidaria disso tanto para o EsicLivre como para o PerguntaCamara (e para o Tagarela).

Dai você diz: nossa que complicado! Será que não valeria mais a pena fazer tudo isso em monolítico?
Boa pergunta novamente. Não sei. Quando iniciamos o Cuidando 2 fizemos uma discussão e optamos pela arquitetura em micro serviços. Apesar dos pesares eu arriscaria dizer que foi uma boa escolha. Mas podemos sentar e rediscutir isso. =)