Reformulação do laguinho
JoseRenan opened this issue · 18 comments
Pessoas, foram levantados problemas em outras issues e no discord sobre o laguinho não conseguir ser muito auto sustentável por centralizar dados que os maintainers talvez não tenham conhecimento e etc, e também a criação de endpoints manualmente pra cada dado novo adicionado e por isso o desenvolvimento do laguinho se manteve parado nesse tempo.
Após algumas discussões, falamos com alguns professores (thanks @matheusgr ❤️ ) e veio a sugestão de que o laguinho passasse a ser algo como o npm, yarn ou pip, porém pra gerenciar datasets de computação, por exemplo, o @OpenDevUFCG/roadmap tem um dataset de disciplinas e suas dependencias de computação, que caso eles queiram disponibilizar no laguinho, eles rodariam algum comando no terminal como laguinho publish e isso publicaria os dados do roadmap no laguinho, porém diferentemente de como é hoje, os dados se manteriam no repositório do roadmap, fazendo com que os maintainers do roadmap ficassem com a responsabilidade de manter esses dados. Os usuários que quiserem baixar os CSVs localmente poderiam usar o comando laguinho get opendevufcg/roadmap que baixaria os dados do repositório, ou poderiam acessar o endpoint laguinho.opendevufcg.org/opendevufcg/roadmap e teriam acesso aos dados publicados da mesma forma. Mais no futuro, poderíamos ter uma página pra listar/pesquisar os datasets disponíveis no laguinho (como o npm e yarn mesmo) e exibir algumas métricas interessantes sobre eles.
Essa solução resolve os problemas citados inicialmente, pois dá a responsabilidade ao publisher dos dados de mantê-los e ao mesmo tempo mantém o propósito do laguinho de ser uma plataforma para facilitar o acesso desses dados para todos.
O que acham??? e quem tá interessado em ajudar a implementar??
/cc @paulojbleitao
cc @grabowski74
Achei top, tenho interesse 👀
quero
Acho uma boa solução!
@JoseRenan o que exatamente viria pra mim quando eu fizesse laguinho get opendevufcg/roadmap, um arquivo com o dataset?
@thayannevls penso em 2 modos de uso. um que realmente é baixar e colocar numa pasta versionada (a la node_modules). que é o get faria.
outra estratégia seria baixar um json (laguinho json opendevufcg/roadmap) com a configuração de onde pegar e como usar. ex.: um json com URI para endpoints rest ou graphql daquele dado.
esse modelo do json serviria para usuários q cadastrarem dados dessa natureza... massssss e, essa é a parte mais legal, imagino que o laguinho poderia até realizar algum tipo de tradução para quem cadastrar csv's ou xls... algo como: nome do recurso é o nome do arquivo, cada linha é uma entidade, cabeçalho define nome das propriedades. algo dessa natureza.
não tive mto tempo para pensar no assunto, mas oferecendo agora uma visão macro, imagino algo assim.... o laguinho é composto pelas partes:
- registro sistema para cadastro e publicação de repositórios de dados. penso que seria legal suportar algo como um repô git com um arquivo num modelo parecido
package.json - registro-web frontend para achar pacotes no registro.
- mecanismo de tradução sistema para oferecer API rest/graphql para dados brutos de forma que seja algo programático (pode ser rate limit para usuários free e pago para um limite mto alto)
- cliente toolkit para baixar dados brutos versionados (molde do node_modules) ou para criar um arquivo de configuração json com os endpoints dos dados. o toolkit vai oferecer mecanismos de baixar samples desses dados para execução de testes locais, etc. etc. imagino que há mto q possa ser feito aqui.
considerando agora a visão de MVP, poderia ser feito:
- criação do registro para cadastro simples, não versionado, de um dado csv bruto
- criação do cliente que busca no registro e baixa esse dado
- adicionar versionamento ao registro e ao cliente
em paralelo vc trabalha no mecanismo de tradução e no frontend web.
@matheusgr Parecido com a cli do Kaggle?
Em relação ao versionamento, seria com intuito de otimizar o processo de atualizar o datasets quando o usuário querer? No caso ele poderia atualizar apenas as linhas que mudaram no csv, sem precisar baixar tudo de novo
Se entendi bem, creio que pro roadmap desse próximo de 2019 bimestre poderíamos começar com o registro e o cliente . O que me preocupa é onde hospedar os registros, será que dá continuar usando o now para isso @JoseRenan ?
@thayannevls acho que dá sim, em termos de armazenamento, acredito que não teríamos muitos problemas porque em tese só precisamos guardar alguma referencia do repositório, identificação do dataset e id da versão (provavelmente algum id do commit) pra cada publish. O único problema talvez fosse a limitação de requests do now, que tb não acho que seria um problema inicialmente 🤔
acho que pra guardar a referecia do dataset podia ser como o próprio npm faz, no package.json de pedir a url do repositório, ao invés disso, a gnt poderia pedir pra ele passar o link do modulo que contém o dataset
ao invés disso, a gnt poderia pedir pra ele passar o link do modulo que contém o dataset
Eu tava pensando em ter os dois, tipo, no package.json tem o URL do repo e um entrypoint, que é o arquivo que vai ser importado quando eu importar o modulo no meu código, no nosso .json a gente teria a URL e o diretório de onde tá os dados. Daí a gente só pegaria daquele diretório os arquivos de dados que tivessem o formato suportado (.csv, .json, .xls, etc)
@matheusgr @fanny @paulojbleitao @grabowski74
Eu e @JoseRenan fizemos um design docs de como poderia ser nossa primeira versão baseado no que @matheusgr sugeriu aqui na discussão, vejam:
Alguns pontos:
- Pensamos em ser obrigatório que a pasta onde ele der
laguinho publishseja um repositório .git - Para garantir que o usuário tenha permissão no git que ele referencia no
laguinho.json, pensamos em adicionar um passo de configuração do laguinho na máquina local, onde ele criaria um arquivo.laguinhopreenchendo com um Personal Token Access - O Token é usado no passo 2 do publish flow, fazemos uma requisição ao github pela CLI para verificar se ele possui acesso de escrita naquele repositório
- No nosso banco de dados apenas guardaríamos(por enquanto) os metadados dos arquivos json dos dados publicados, sendo os dados baixados diretamente do github pela CLI
- Em primeira versão, usuário receberia dado bruto
O que acham?
Achei ótimo, só uma dúvida. Quando tu fala dado bruto, é sem disponibilizar aquilo de varios tipos de formatos, né?
Isso mesmo @fanny , só oferecer na forma que foi enviado pra gente
Fechando essa issue em decorrencia da OpenDevUFCG/laguinho#1 dependendo do que sair de lá, se viermos a criar outro repo e tal, a gente quebra as discussões técnicas em várias issues