Sugestão arquitetural

[dalssoft]

Descrição da arquitetura

Lista dos candidatos (core)

Essa parte da arquitetura é responsável por guardar e garantir os dados alimentados de maneira manual. É através dessas informações que:

• a UI será montada
• o crawler usará como seed

Inicialmente não há necessidade de UI para a manutenção (CRUD) desses dados, sendo mantido via um arquivo de seed (ex: http://davidmles.com/blog/seeding-database-rails/)

Bando de dados

Tabela: candidato

campo	descrição
id	id único do candidato, seguindo a numeração do TSE/TRE (??)
nome	nome do candidato
partido_id	FK tabela partido
candidatura_id	FK tabela candidatura
data_criacao	data de criação do registro
data_atualizacao	data de atualização do registro

Tabela: candidatura

campo	descrição
id	id único do tipo da candidatura (um caractere) (Ex: P - Prefeito, V - vereador)
descricao	descrição do tipo de candidatura
data_criacao	data de criação do registro
data_atualizacao	data de atualização do registro

Tabela: partido

campo	descrição
id	id único do partido, seguindo a numeração do TSE/TRE
nome	nome do partido
data_criacao	data de criação do registro
data_atualizacao	data de atualização do registro

Tabela: candidato_link

campo	descrição
id	id único da página (GUID)
candidato_id	FK tabela candidato
link	URL para um site ou mídia social do candidato
tipo_link_id	FK tabela tipo_link
data_criacao	data de criação do registro
data_atualizacao	data de atualização do registro

Tabela: tipo_link

campo	descrição
id	id único do tipo do link (dois caracteres) (Ex: FB - Facebook, TT - Twitter)
descricao	descricao do tipo do link
data_criacao	data de criação do registro
data_atualizacao	data de atualização do registro

Info: é importante manter as tabelas normalizadas e suas constraints ligadas entre os relacionamentos, garantindo que os dados aqui não sejam corrompidos. Outras tabelas, como as do crawler, talvez não necessitem do mesmo rigor.

Client / UI: Home, páginas e filtros [~/client]

[TBD]

Crawler 1: Posts da página do candidato [~/crawler/posts]

Atualiza quais os posts de cada página (no FB) de cada candidato nos últimos N dias.

Bando de dados

[TBD]

Parametros

• É executado a cada N horas.
• Lista os posts apenas dos últimos X dias ou Y páginas do json.

Crawler 2: Engajamento do post [~/crawler/likes]

Atualiza quantos likes e quantos comentários cada post tem.

Bando de dados

[TBD]

Parametros

• É executado a cada N horas.
• Atualiza apenas os posts dos últimos N dias.

Apêndice

Padrão para o bando de dados:

• para nome de tabela e campos: https://launchbylunch.com/posts/2014/Feb/16/sql-naming-conventions/
• ids tentam ser legíveis e amigáveis, quando possível, evitando joins

[dalssoft]

aqui eu fiz sugestão da divisão de algumas camadas, uma modelagem inicial para o core, alguns sugestões de pastas para o projeto e padrões de nomenclatura (foi o primeiro que o google trouxe).

fica faltando um monte de coisas: definição da arquitetura do client/ui, dos crawlers, etc.

[mvcds]

• Se separarmos o ID do candidato da numeração TSE/TRE, teremos uma tabela para pessoa, o que permite que candidatos tenham numeração variada (se a mesma for alterada conforme partido, posição almejada, ano da eleição, etc).
• A tabela de candidatura é uma tabela auxiliar só para mostrar o cargo? Se for isso, acho melhor mudarmos o nome para TipoCandidatura. Pra mim, Candidatura implica partido, tipo, ano e possiveis outras informações.
• Adicionar o número do partidos seria legal.
• Como temos funcionalidades ligadas à cargos/funções, acho que temos que armazenar esses dados para montar um histórico.
• Vamos precisas deixar na nossa base quais projetos cada candidato entregou ou iremos ficar buscando essa informação de forma semelhante aos posts? No caso de ser "estático" precisaremos de uma tabela pra esses dados também.

[mvcds]

Se entendi a proposta da seed, é preencher o banco com dados pré-definidos.
Pode ser uma boa ideia para um momento futuro, mas enquanto estamos em concepção podemos usar algo como o rosie junto ao faker, para criarmos algo que se assemelha aos modelos.

O problema dessa abordagem é que são dados falsos, mas podemos começar a testar a modelagem com eles antes de inserir dados reais.

[danielbdias]

Achei a modelagem inicial ok.

O único comentário sobre ela é que eu sugiro termos ids separados dos ids dos órgãos governamentais (o caso das tabelas candidato e partido).

A modelagem ficaria algo como:

campo	descrição
id	id único
codigo_tse	id segundo o TSE

Para a criação das seeds e para a criação dos migrations eu sugiro que a gente use o db-migrate.

[alanhoff]

Por mim está tudo OK somente optaria for fazer logo uma API em vez de um site estático pois o mesmo terá constantes atualizações.

Uma estrutura de projeto que vem funcionando muito bem para mim é esta:

|-> index.js
|-> frontend (talvez rodar em um projeto separado)
|-> libs
      |-> server.js
      |-> ...
| -> resources
       |-> partidos
             |-> model.js
             |-> schemas.js
             |-> routes.js
             |-> handlers.js
       |-> cadidatos
             |-> model.js
             |-> schemas.js
             |-> routes.js
             |-> handlers.js
       |-> ...
| -> tests
       |-> fixtures
             |-> candidatos.js
             |-> ...
       |-> specs
             |-> candidatos.js
             |-> partidos.js
             |-> ...

[dalssoft]

Coloquei na wiki do projeto: https://github.com/codeforsaopaulo/assimfalouocandidato/wiki/Arquitetura:-Vis%C3%A3o-Geral

[dalssoft]

@mvcds

Se separarmos o ID do candidato da numeração TSE/TRE, teremos uma tabela para pessoa, o que permite que candidatos tenham numeração variada (se a mesma for alterada conforme partido, posição almejada, ano da eleição, etc).

pensei em manter o banco de dados integro para aquela eleição e não para muitas eleições, para manter o mais simples possível

A tabela de candidatura é uma tabela auxiliar só para mostrar o cargo? Se for isso, acho melhor mudarmos o nome para TipoCandidatura. Pra mim, Candidatura implica partido, tipo, ano e possiveis outras informações.

fiquei na dúvida também, mas preferi deixar uma tabela para ficar bem didático para quem for dar manutenção (ao invés de usar alguma feature do banco para manter integridade)

Adicionar o número do partidos seria legal.

done

Como temos funcionalidades ligadas à cargos/funções, acho que temos que armazenar esses dados para montar um histórico.
Vamos precisas deixar na nossa base quais projetos cada candidato entregou ou iremos ficar buscando essa informação de forma semelhante aos posts? No caso de ser "estático" precisaremos de uma tabela pra esses dados também.

pelo o que entendi ficou decidido que na nossa página teria links para páginas parceiras ou públicas que teriam esse conteúdo, certo?

Se entendi a proposta da seed, é preencher o banco com dados pré-definidos.
Pode ser uma boa ideia para um momento futuro, mas enquanto estamos em concepção podemos usar algo como o rosie junto ao faker, para criarmos algo que se assemelha aos modelos.
O problema dessa abordagem é que são dados falsos, mas podemos começar a testar a modelagem com eles antes de inserir dados reais.

a ideia é ter uma forma rápida de alimentar com dados reais os dados dos candidatos. algo que seja fácil das pessoas colaborarem também. pensei num arquivo de seed, que é fácil de editar via github direto.

podemos usar o faker para teste, mas ai é outra coisa.

@danielbdias

O único comentário sobre ela é que eu sugiro termos ids separados dos ids dos órgãos governamentais (o caso das tabelas candidato e partido).

done

[dalssoft]

@alanhoff se separarmos a parte de business da infra, a API e Web (site) são só apresentação do mesmo dado e lógica.

indo nessa linha, sugiro a estrutura do nodebase, que fica claro o papel de business (models, repositórios, etc) e o que é camada de visualização/interação (infra\service, infra\web, infra...)

mas confesso que no final tenho pouco apego à estrutura do projeto. fica o que o pessoal achar melhor.