You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Olá Pessoal, essa é uma das minhas primeiras Issues no github, então desculpe se cometer algum erro. Programação para mim é um hobbie, já que atuo como Engenheiro Civil.
Vamos ao que interessa, acredito que a API tenha um proposito de produtividade no final das contas, não só para o programador mas também para o usuário que utilizar o sistema. E para mim sempre foi uma coisa muito chata cadastrar empresas. E a chateação aumenta, quando vai no site da receita e digita o CNPJ e todos dados aparecem (não sei se eles liberam alguma API, nunca consegui achar nada), então acho que seria algo útil uma implementação onde digita o CNPJ e os dados principais são retornados.
Ah e parabéns pela iniciativa, vou tentar ajudar também. Bom que me ajuda nos meus estudos de javascript e nodeJS.
Acho bacana essa sugestão e até onde sei a receita não tem uma API para isso, e só permitem consultar um CNPJ colocando um captcha
Pelo que eu me lembre, eles lançam uma vez a cada três meses (ou algo do tipo) um arquivo contendo os CNPJs cadastrados com informações extras.
Vou até baixar o arquivo para dar uma olhada depois, mas acho que uma solução possível (mas não sei o quão viável é, devido à necessidade de espaço/db no servidor), ter algum endpoint que possa ser batido e o servidor baixar, descompactar o arquivo, decodificar e importar esses dados, e outro endpoint para consultas.
Fazer um script que baixe isso a cada trimeste quando a Receita atualizar, geraria também um histórico ao longo do tempo. Isso porque acredito que a base não seja estática. Se a empresa mudou alguma informação cadastral, essa mudança ficaria registrada nesse histórico.
Quanto à questão de espaço, não sei se o backend que vocês estão utilizando é suficiente e aceita algum banco de dados relacional, pois a base realmente é grande.
A ideia é muito boa e facilitaria as aplicações a implementarem alguma funcionalidade que exige dados a respeito de um CNPJ. Caso não existisse, todos os desenvolvedores teriam de fazer um script para descompactar, criar o banco e realizar as consultas. Um retrabalho considerável.
Reacted by Nauro da Silva Júnior and Matheus Oliveira
Fiz exatamente o processo de baixar os 20 arquivos, junta-los e transforma-los num CSV GIGANTE! (~12Gb), depois de algumas tentativas de importar o CSV para o MySQL (Escolha predefinida pela empresa, não me culpem se existe solução melhor), o tamanho acabou ficando em 9,9Gb + indexes.
Pois ai temos outro problema, o tempo de busca de 1 CNPJ, antes do index era de ~1min, depois do index, alguns millisegundos.
Muito interessante, mas em caso de atualização dos dados da receita como fica? Acredito que a disponibilização dos dados por ela é feita pós a atualização por requisição por ela. Seria interessante pós uma requisição ser feita, responder com o que está na base de dados, mas agendar no backend uma solicitação para verificação em caso de atualizado, desse modo se tenta atualizar o que está sendo requisitado.
@farukaf Não entendi bem sua ideia, pois CDN, até onde sei, não serve para BD. Acho que querendo ou não, vamos precisar de um banco com no min 10gb (se não fizermos o versionamento de alterações da empresa).
@Juloko Como a receita atualiza esses 20 arquivos a cada 3 meses, temos que fazer o processo completo a cada atualização.
Mas existe um limbo ai no meio, pois empresas alteradas ou abertas desde a ultima atualização (no máximo 3 meses), não existirão no BD, e portanto, teriamos que fazer o scrapping, com o usuario preenchendo o captcha.
Quanto a cada requisição, solicitar que faça o scrapping, teríamos que burlar o captcha, pra que o processo seja automático.
Burlar o capcha não me parece uma boa idéia, se ele está lá é porque alguém quer segurança, alguém paga uma infra ali por trás e quer que apenas os usuários humanos passem... Julgo justo e acho que tentar burlar é algo que não deveria ser uma opção de caminho.
Quanto a CDN, não cacheia bases de dados, mas cacheia respostas de APIs, e se você usar com estratégias de stales while revalidade, que é o que citou, ela vai responder na hora com o que tem em cache porém estará agendada para que aquele cache expire e ela revalide, mas o user sempre consome do cache o que da uma latência baixíssima.
Isto a Vercel e o Next fazem para nós já, o projeto atual na busca do cep já usa o stale while revalidade da vercel.
@filipedeschamps quem vai saber falar aqui, mas creio que a ideia não é ter uma base de dados neste projeto, mas sim servir como um centralizador/agregador, uma interface e um cache para as apis mais úteis e utilizadas no Brasil.
Acredito que é assim a busca do CEP, fazemos a busca nos correios, a resposta fica cacheada aqui, a primeira requisição de certo endereço levará um pouco a mais, as próximas terão latência baixíssima pois virão do cache do next/vercel.
O correto é um banco de dados. Relacional ou não.
Mas como os arquivos são estaticos por até 3 meses pensei que fragmentar em varios jsons pode ser uma solução.
Mas já não poderia ir utilizando o receitaws até que desenvolva outra opção?
Então a melhor opção (1) que temos até agora é consultar a ReceitaWS como os módulos existentes do BrasilAPI já faz.
Além disso podemos usar o módulo do @biutas (2) para consultar o próprio site da receita, mas aí teria o captcha. Caso ele fosse quebrado, essa seria a melhor opção.
Por fim, essa ideia de baixar o ZIP da Receita (3) o @biutas também já fez em Python. Daí podemos deixar em standby até alguma sugestão de backend pra armazenar o banco surgir.
Como o @farukaf disse, podemos implementar a opção (1) já que é a mais viável. Seguindo para opção (2), e por fim a (3) caso encontrassemos uma solução para backend.
Concordo que burlar captcha não é legal, da mesma forma que a receita WS tem limite de consulta de 3/minuto. Teríamos que ver qual a orientação, se podemos ter base de dados no projeto.
Eu sei que a ideia é ser uma coisa independente, mas acredito se alguém conhecer pessoas envolvidas nesses orgãos governamentais, eles talvez proveriam uma maneira mais fácil de realizar essas funções, ou até mesmo façam propaganda dessa solução para o uso mais abrangente.
Vou fazer um passo-a-passo do que acho que seria interessante:
Passo 1 - Baixar os arquivos da receita de vários gb conforme comentaram acima
Passo 2- Criar um scrpit ETL (Extract, transform and load) para:
extrair os dados dos arquivos da receita federal
tratar esses dados
transformar em arquivos .json. Para cada cnpj teria um arquivo json já salvo com todos os dados.
Os dados poderiam ser salvos em um serviço de armazenamento como o S3 por exemplo.
Passo 3 - (opcional) - automatizar o download os arquivos e executar o script ETL. Mas de início pode ser feito de forma manual mesmo, já que os dados são disponibilizados a cada 3 meses.
Passo 5 - Ao fazer uma requisição para servidor.com/api/cnpj/numero-do-cnpj.json será retornado o conteúdo do arquivo, sem precisar de um banco de dados, com custo computacional quase zero. E ainda com o beneficio de aproveitar a infraestrutura de cache do backend.
@ivanmonteiro Foi o que eu comentei anteriormente... de uma forma menos didatica...
O S3 tem um custo, armazenar esses arquivos no github seria inviavel? eu consultei os limites e não nenhuma impossibilidade.
@farukaf seria inviável para clonar e trabalhar com este tanto de arquivos no repositório, se fosse para o lado de bases de dados o redis seria muito legal por ser chave valor, bateria qualquer base relacional ou não... mas este caminho de usar jsons seria ótimo mesmo, até melhor, encapsular em uma api onde retornaríamos se não encontrasse seria legal.
Mas aqui no GH acho que seria bem ruim, o S3 teria custo, só se a Vercel tiver storage lá também e topar colocar lá, já que são sponsor oficial mesmo hehe
Ou termos um repositório a parte para usar de banco de dados destes jsons...
@ivanmonteiro Foi o que eu comentei anteriormente... de uma forma menos didatica...
O S3 tem um custo, armazenar esses arquivos no github seria inviavel? eu consultei os limites e não nenhuma impossibilidade.
Quanto ao Github acho que seria complicado principalmente no quanto vai demorar para fazer o primeiro push e as atuailizações futuras. Apesar de não imporem limites, fora o tamanho do arquivo que é no máximo 100mb, eles recomendam que o repositório tenha menos de 1gb para não sobrecarregar os servidores do Github.
@farukaf seria inviável para clonar e trabalhar com este tanto de arquivos no repositório, se fosse para o lado de bases de dados o redis seria muito legal por ser chave valor, bateria qualquer base relacional ou não... mas este caminho de usar jsons seria ótimo mesmo, até melhor, encapsular em uma api onde retornaríamos se não encontrasse seria legal.
Mas aqui no GH acho que seria bem ruim, o S3 teria custo, só se a Vercel tiver storage lá também e topar colocar lá, já que são sponsor oficial mesmo hehe
Ou termos um repositório a parte para usar de banco de dados destes jsons...
Aparentemente o storage da Vercel é bem limitado (limite de 16.000 arquivos).
Quanto a um redis acho que poderia ser legal, mas também tem o problema do custo de manter essa infraestrutura...
armazenar esses arquivos no github seria inviavel?
Não só é viável como o índice de pacotes do Rust é armazenado assim, em formato de árvore, no GitHub
O índice de pacotes do Rust possui "somente" 41.291 pacotes. O número de arquivos JSON para todas as empresas é de 40.184.161, ou seja quase mil vezes maior.
Se conseguissemos dividir esses CNPJs em 4096 pastas diferentes, teríamos algo em torno de 10 mil arquivos por pasta, o que é um bom número para um sistema de arquivos.
O script ETL poderia alterar o JSON somente das empresas que tiveram algum dado modificado.
O primeiro commit seria de 22 GB, e os seguintes talvez 10% do tamanho.
Acredito que o mais simples de se fazer, é criar um subprojeto para o CNPJ onde nós mantemos uma base no tipo Receitaws, porem tem custos para manter isso.
Uma saída seria cobrar, para manter o custo, claro que sem lucros. E como contrapartida para quem pagasse por nossa base de dados, liberaria histórico de alteração e outros tipos de consultas.
Fazendo isso já teríamos o acesso a API pelo BrasilApi sem limite de consultas.
@guilhermelpp Gostei da sua ideia, já que o projeto não prevê uma base de dados, poderiamos criar a nossa API, cobra-la para manter, e então colocar aqui no BrasilAPI.
Alguém teria noção de custo para manter essa infra? AWS, GCP, Azure?
É uma boa ideia saber quem vai querer usar essa API, porque corre-se o risco de gastar um tempo fazendo todo o sistema e no final, não conseguir alcançar o público. Isto é, eles vão preferir continuar pagando o concorrente que eles já conhecem e confiam.
Precisamos saber quanto a ReceitaWS cobra pelo uso da API deles e se a nossa tem capacidade de ser tão boa quanto. As vezes eles mesmo podem ter algum recurso mais elaborado para obter informações precisas e atualizadas das empresas.
Esses são alguns pontos importantes a levantar porque algum investimento será preciso pra manter a base.
Exato, sei que é possível obter os dados em outros orgãos, pois algumas empresas fornecem "quais empresas abriram ontem", mas desconheço onde busca essa info.
@farukaf Se for para o lado da AWS não precisa ser o dynamo, usem o RDS onde você tera free tier em mysql, postgres e diversos outros bancos. Quanto a api de início indo pela AWS usaria lambda function onde teria 1 milhão de lambdas executadas sem custo. Já tem banco de dados e sistema online processando 1 milhão de requests sem custo, passando de 1 milhão de requests suponho que o projeto já terá como se manter bem fora da camada free tier.
Apenas a questão da base de dados, se a api será para busca do CNPJ, e é um dado que tem que ser inteiro, eu iria de Redis, com certeza ele baterá qualquer banco relacional e até o no sql. Porém pode ser que de início ele não seja viável por custos, mas que também são baixos.
@wilsonneto-dev o tier gratuido do RDS é de 20gb por 12 meses... mas é uma opção... o ideal seria uma solução gratuita até conseguir esse apoio financeiro. Amazon Databases
Activity
naurojunior commentedon Jun 1, 2020
Acho bacana essa sugestão e até onde sei a receita não tem uma API para isso, e só permitem consultar um CNPJ colocando um captcha
Pelo que eu me lembre, eles lançam uma vez a cada três meses (ou algo do tipo) um arquivo contendo os CNPJs cadastrados com informações extras.
Vou até baixar o arquivo para dar uma olhada depois, mas acho que uma solução possível (mas não sei o quão viável é, devido à necessidade de espaço/db no servidor), ter algum endpoint que possa ser batido e o servidor baixar, descompactar o arquivo, decodificar e importar esses dados, e outro endpoint para consultas.
Edit:
Link dos dados e infos
http://receita.economia.gov.br/orientacao/tributaria/cadastros/cadastro-nacional-de-pessoas-juridicas-cnpj/dados-publicos-cnpj
Se eu conseguir evoluir em algo eu abro um PR com essa sugestão
asm95 commentedon Jun 3, 2020
Fazer um script que baixe isso a cada trimeste quando a Receita atualizar, geraria também um histórico ao longo do tempo. Isso porque acredito que a base não seja estática. Se a empresa mudou alguma informação cadastral, essa mudança ficaria registrada nesse histórico.
Quanto à questão de espaço, não sei se o backend que vocês estão utilizando é suficiente e aceita algum banco de dados relacional, pois a base realmente é grande.
A ideia é muito boa e facilitaria as aplicações a implementarem alguma funcionalidade que exige dados a respeito de um CNPJ. Caso não existisse, todos os desenvolvedores teriam de fazer um script para descompactar, criar o banco e realizar as consultas. Um retrabalho considerável.
farukaf commentedon Jun 3, 2020
Eu uso esse serviço a alguns meses. Não necessita captcha.
Exemplo do Ajax
$.ajax({ url: 'https://www.receitaws.com.br/v1/cnpj/{cnpj}' , dataType: "jsonp", type: 'GET', })Request URL: https://www.receitaws.com.br/v1/cnpj/00000000000191?callback=jQuery31008196623825509244_1591201769078&_=159120176907
Exemplo de retorno
typeof jQuery31008196623825509244_1591201769078 === 'function' && jQuery31008196623825509244_1591201769078({ "atividade_principal": [{ "text": "Bancos múltiplos, com carteira comercial", "code": "64.22-1-00" }], "data_situacao": "03/11/2005", "complemento": "ANDAR 1 A 16 SALA 101 A 1601 ANDAR 1 A 16 SALA 101 A 1601 ANDAR 1 A 16 SALA 101 A 1601", "nome": "BANCO DO BRASIL SA", "efr": "UNIÃO", "uf": "DF", "telefone": "(61) 3493-9002", "email": "secex@bb.com.br", "atividades_secundarias": [{ "text": "Outras atividades de serviços financeiros não especificadas anteriormente", "code": "64.99-9-99" }], "qsa": [{ "qual": "10-Diretor", "nome": "MARCIO HAMILTON FERREIRA" }, { "qual": "10-Diretor", "nome": "NILSON MARTINIANO MOREIRA" }, { "qual": "10-Diretor", "nome": "WALTER MALIENI JUNIOR" }, { "qual": "10-Diretor", "nome": "CARLOS ALBERTO ARAUJO NETTO" }, { "qual": "10-Diretor", "nome": "ANTONIO MAURICIO MAURANO" }, { "qual": "10-Diretor", "nome": "MARCELO AUGUSTO DUTRA LABUTO" }, { "qual": "10-Diretor", "nome": "ROGERIO MAGNO PANCA" }, { "qual": "10-Diretor", "nome": "SIMAO LUIZ KOVALSKI" }, { "qual": "10-Diretor", "nome": "TARCISIO HUBNER" }, { "qual": "10-Diretor", "nome": "EDUARDO CESAR PASA" }, { "qual": "10-Diretor", "nome": "MARCIO LUIZ MORAL" }, { "qual": "10-Diretor", "nome": "JOSE EDUARDO MOREIRA BERGO" }, { "qual": "10-Diretor", "nome": "ALEXANDRE ALVES DE SOUZA" }, { "qual": "10-Diretor", "nome": "CICERO PRZENDSIUK" }, { "qual": "10-Diretor", "nome": "EDSON ROGERIO DA COSTA" }, { "qual": "10-Diretor", "nome": "FABIANO MACANHAN FONTES" }, { "qual": "10-Diretor", "nome": "FERNANDO FLORENCIO CAMPOS" }, { "qual": "10-Diretor", "nome": "GUSTAVO DE SOUZA FOSSE" }, { "qual": "10-Diretor", "nome": "MARCO TULIO DE OLIVEIRA MENDONCA" }, { "qual": "10-Diretor", "nome": "MARVIO MELO FREITAS" }, { "qual": "10-Diretor", "nome": "REINALDO KAZUFUMI YOKOYAMA" }, { "qual": "10-Diretor", "nome": "JOSE CAETANO DE ANDRADE MINCHILLO" }, { "qual": "10-Diretor", "nome": "CARLOS RENATO BONETTI" }, { "qual": "10-Diretor", "nome": "JOSE EDUARDO PEREIRA FILHO" }, { "qual": "10-Diretor", "nome": "MARCO TULIO MORAES DA COSTA" }, { "qual": "10-Diretor", "nome": "JOAO PINTO RABELO JUNIOR" }, { "qual": "10-Diretor", "nome": "CARLOS HAMILTON VASCONCELOS ARAUJO" }, { "qual": "10-Diretor", "nome": "LUCINEIA POSSAR" }, { "qual": "10-Diretor", "nome": "JOSE RICARDO FAGONDE FORNI" }, { "qual": "10-Diretor", "nome": "MARCOS RENATO COLTRI" }, { "qual": "10-Diretor", "nome": "CARLA NESI" }, { "qual": "10-Diretor", "nome": "BERNARDO DE AZEVEDO SILVA ROTHE" }, { "qual": "10-Diretor", "nome": "ANTONIO GUSTAVO MATOS DO VALE" }, { "qual": "10-Diretor", "nome": "LUIZ CLAUDIO BATISTA" }, { "qual": "10-Diretor", "nome": "JOSE AVELAR MATIAS LOPES" }, { "qual": "10-Diretor", "nome": "ANA PAULA TEIXEIRA DE SOUSA" }, { "qual": "10-Diretor", "nome": "DELANO VALENTIM DE ANDRADE" }, { "qual": "10-Diretor", "nome": "GERSON EDUARDO DE OLIVEIRA" }, { "qual": "16-Presidente", "nome": "RUBEM DE FREITAS NOVAES" }, { "qual": "10-Diretor", "nome": "PAULA LUCIANA VIANA DA SILVA LIMA MAZANEK" }, { "qual": "10-Diretor", "nome": "CAMILO BUZZI" }, { "qual": "10-Diretor", "nome": "CARLOS MOTTA DOS SANTOS" }, { "qual": "10-Diretor", "nome": "FABIO AUGUSTO CANTIZANI BARBOSA" }, { "qual": "10-Diretor", "nome": "IVANDRE MONTIEL DA SILVA" }, { "qual": "10-Diretor", "nome": "RONALDO SIMON FERREIRA" }, { "qual": "10-Diretor", "nome": "ENIO MATHIAS FERREIRA" }, { "qual": "10-Diretor", "nome": "DANIEL ANDRE STIELER" }, { "qual": "10-Diretor", "nome": "MAURICIO NOGUEIRA" }, { "qual": "10-Diretor", "nome": "THOMPSON SOARES PEREIRA CESAR" }, { "qual": "10-Diretor", "nome": "ERIK DA COSTA BREYER" }, { "qual": "08-Conselheiro de Administração", "nome": "WALDERY RODRIGUES JUNIOR" }, { "qual": "08-Conselheiro de Administração", "nome": "DEBORA CRISTINA FONSECA" }, { "qual": "08-Conselheiro de Administração", "nome": "LUIZ SERAFIM SPINOLA SANTOS" }, { "qual": "08-Conselheiro de Administração", "nome": "PAULO ROBERTO EVANGELISTA DE LIMA" }], "situacao": "ATIVA", "bairro": "ASA NORTE", "logradouro": "Q SAUN QUADRA 5 LOTE B TORRES I, II E III", "numero": "SN", "cep": "70.040-912", "municipio": "BRASILIA", "porte": "DEMAIS", "abertura": "01/08/1966", "natureza_juridica": "203-8 - Sociedade de Economia Mista", "fantasia": "DIRECAO GERAL", "cnpj": "00.000.000/0001-91", "ultima_atualizacao": "2020-06-02T17:39:05.330Z", "status": "OK", "tipo": "MATRIZ", "motivo_situacao": "", "situacao_especial": "", "data_situacao_especial": "", "capital_social": "67000000000.00", "extra": {}, "billing": { "free": true, "database": true } });biutas commentedon Jun 3, 2020
Fiz exatamente o processo de baixar os 20 arquivos, junta-los e transforma-los num CSV GIGANTE! (~12Gb), depois de algumas tentativas de importar o CSV para o MySQL (Escolha predefinida pela empresa, não me culpem se existe solução melhor), o tamanho acabou ficando em 9,9Gb + indexes.
Pois ai temos outro problema, o tempo de busca de 1 CNPJ, antes do index era de ~1min, depois do index, alguns millisegundos.
O Repo que faz a junção dos arquivos é esse:
https://github.com/fabioserpa/CNPJ-full
Também trabalhei num projeto que fazia o scrapping do site da receita, mostrando o captcha para o usuário resolver.
https://www.npmjs.com/package/consulta-cnpj-rfb
Me disponho a colaborar nessa API, se alguém ja estiver fazendo algo.
farukaf commentedon Jun 3, 2020
Index em um campo de texto em um banco relacional creio que mantenha um consumo razoavel no servidor do banco. Olhando este cenario.
Teria alguma possibilidade de fragmentar as informações e hospeda-las em cdn, com index em codigo para ser consumido? ou to falando besteira?
julioflima commentedon Jun 3, 2020
@biutas
Muito interessante, mas em caso de atualização dos dados da receita como fica? Acredito que a disponibilização dos dados por ela é feita pós a atualização por requisição por ela. Seria interessante pós uma requisição ser feita, responder com o que está na base de dados, mas agendar no backend uma solicitação para verificação em caso de atualizado, desse modo se tenta atualizar o que está sendo requisitado.
biutas commentedon Jun 3, 2020
@farukaf Não entendi bem sua ideia, pois CDN, até onde sei, não serve para BD. Acho que querendo ou não, vamos precisar de um banco com no min 10gb (se não fizermos o versionamento de alterações da empresa).
biutas commentedon Jun 3, 2020
@Juloko Como a receita atualiza esses 20 arquivos a cada 3 meses, temos que fazer o processo completo a cada atualização.
Mas existe um limbo ai no meio, pois empresas alteradas ou abertas desde a ultima atualização (no máximo 3 meses), não existirão no BD, e portanto, teriamos que fazer o scrapping, com o usuario preenchendo o captcha.
Quanto a cada requisição, solicitar que faça o scrapping, teríamos que burlar o captcha, pra que o processo seja automático.
wilsonneto-swe commentedon Jun 3, 2020
Burlar o capcha não me parece uma boa idéia, se ele está lá é porque alguém quer segurança, alguém paga uma infra ali por trás e quer que apenas os usuários humanos passem... Julgo justo e acho que tentar burlar é algo que não deveria ser uma opção de caminho.
Quanto a CDN, não cacheia bases de dados, mas cacheia respostas de APIs, e se você usar com estratégias de stales while revalidade, que é o que citou, ela vai responder na hora com o que tem em cache porém estará agendada para que aquele cache expire e ela revalide, mas o user sempre consome do cache o que da uma latência baixíssima.
Isto a Vercel e o Next fazem para nós já, o projeto atual na busca do cep já usa o stale while revalidade da vercel.
@filipedeschamps quem vai saber falar aqui, mas creio que a ideia não é ter uma base de dados neste projeto, mas sim servir como um centralizador/agregador, uma interface e um cache para as apis mais úteis e utilizadas no Brasil.
Acredito que é assim a busca do CEP, fazemos a busca nos correios, a resposta fica cacheada aqui, a primeira requisição de certo endereço levará um pouco a mais, as próximas terão latência baixíssima pois virão do cache do next/vercel.
Abraço!
farukaf commentedon Jun 3, 2020
O correto é um banco de dados. Relacional ou não.
Mas como os arquivos são estaticos por até 3 meses pensei que fragmentar em varios jsons pode ser uma solução.
Mas já não poderia ir utilizando o receitaws até que desenvolva outra opção?
asm95 commentedon Jun 3, 2020
Então a melhor opção (1) que temos até agora é consultar a ReceitaWS como os módulos existentes do BrasilAPI já faz.
Além disso podemos usar o módulo do @biutas (2) para consultar o próprio site da receita, mas aí teria o captcha. Caso ele fosse quebrado, essa seria a melhor opção.
Por fim, essa ideia de baixar o ZIP da Receita (3) o @biutas também já fez em Python. Daí podemos deixar em standby até alguma sugestão de backend pra armazenar o banco surgir.
Como o @farukaf disse, podemos implementar a opção (1) já que é a mais viável. Seguindo para opção (2), e por fim a (3) caso encontrassemos uma solução para backend.
biutas commentedon Jun 3, 2020
Concordo que burlar captcha não é legal, da mesma forma que a receita WS tem limite de consulta de 3/minuto. Teríamos que ver qual a orientação, se podemos ter base de dados no projeto.
Werner1201 commentedon Jun 4, 2020
Eu sei que a ideia é ser uma coisa independente, mas acredito se alguém conhecer pessoas envolvidas nesses orgãos governamentais, eles talvez proveriam uma maneira mais fácil de realizar essas funções, ou até mesmo façam propaganda dessa solução para o uso mais abrangente.
ivanmonteiro commentedon Jun 4, 2020
Vou fazer um passo-a-passo do que acho que seria interessante:
Passo 1 - Baixar os arquivos da receita de vários gb conforme comentaram acima
Passo 2- Criar um scrpit ETL (Extract, transform and load) para:
extrair os dados dos arquivos da receita federal
tratar esses dados
transformar em arquivos .json. Para cada cnpj teria um arquivo json já salvo com todos os dados.
Os dados poderiam ser salvos em um serviço de armazenamento como o S3 por exemplo.
Passo 3 - (opcional) - automatizar o download os arquivos e executar o script ETL. Mas de início pode ser feito de forma manual mesmo, já que os dados são disponibilizados a cada 3 meses.
Passo 5 - Ao fazer uma requisição para servidor.com/api/cnpj/numero-do-cnpj.json será retornado o conteúdo do arquivo, sem precisar de um banco de dados, com custo computacional quase zero. E ainda com o beneficio de aproveitar a infraestrutura de cache do backend.
farukaf commentedon Jun 4, 2020
@ivanmonteiro Foi o que eu comentei anteriormente... de uma forma menos didatica...
O S3 tem um custo, armazenar esses arquivos no github seria inviavel? eu consultei os limites e não nenhuma impossibilidade.
1 remaining item
wilsonneto-swe commentedon Jun 4, 2020
@farukaf seria inviável para clonar e trabalhar com este tanto de arquivos no repositório, se fosse para o lado de bases de dados o redis seria muito legal por ser chave valor, bateria qualquer base relacional ou não... mas este caminho de usar jsons seria ótimo mesmo, até melhor, encapsular em uma api onde retornaríamos se não encontrasse seria legal.
Mas aqui no GH acho que seria bem ruim, o S3 teria custo, só se a Vercel tiver storage lá também e topar colocar lá, já que são sponsor oficial mesmo hehe
Ou termos um repositório a parte para usar de banco de dados destes jsons...
ivanmonteiro commentedon Jun 5, 2020
Quanto ao Github acho que seria complicado principalmente no quanto vai demorar para fazer o primeiro push e as atuailizações futuras. Apesar de não imporem limites, fora o tamanho do arquivo que é no máximo 100mb, eles recomendam que o repositório tenha menos de 1gb para não sobrecarregar os servidores do Github.
Aparentemente o storage da Vercel é bem limitado (limite de 16.000 arquivos).
Quanto a um redis acho que poderia ser legal, mas também tem o problema do custo de manter essa infraestrutura...
asm95 commentedon Jun 5, 2020
O índice de pacotes do Rust possui "somente"
41.291pacotes. O número de arquivos JSON para todas as empresas é de40.184.161, ou seja quase mil vezes maior.Se conseguissemos dividir esses CNPJs em 4096 pastas diferentes, teríamos algo em torno de 10 mil arquivos por pasta, o que é um bom número para um sistema de arquivos.
O script ETL poderia alterar o JSON somente das empresas que tiveram algum dado modificado.
O primeiro commit seria de 22 GB, e os seguintes talvez 10% do tamanho.
farukaf commentedon Jun 5, 2020
Da para ser utilizado alguma estrutura de compactação. Basta criar uma prova de conceito. E realizar alguns testes...
guilhermelpp commentedon Jun 5, 2020
Opa, não pensei que iria render tanto hehe.
Acredito que o mais simples de se fazer, é criar um subprojeto para o CNPJ onde nós mantemos uma base no tipo Receitaws, porem tem custos para manter isso.
Uma saída seria cobrar, para manter o custo, claro que sem lucros. E como contrapartida para quem pagasse por nossa base de dados, liberaria histórico de alteração e outros tipos de consultas.
Fazendo isso já teríamos o acesso a API pelo BrasilApi sem limite de consultas.
biutas commentedon Jun 5, 2020
@guilhermelpp Gostei da sua ideia, já que o projeto não prevê uma base de dados, poderiamos criar a nossa API, cobra-la para manter, e então colocar aqui no BrasilAPI.
Alguém teria noção de custo para manter essa infra? AWS, GCP, Azure?
farukaf commentedon Jun 5, 2020
https://aws.amazon.com/pt/dynamodb/?did=ft_card&trk=ft_card
https://prnt.sc/sublee
DynamoDB da AWS diz ser gratuito até 25gb.
Nuunca trabalhei com esse DB. Ele atende o que precisamos?
asm95 commentedon Jun 7, 2020
É uma boa ideia saber quem vai querer usar essa API, porque corre-se o risco de gastar um tempo fazendo todo o sistema e no final, não conseguir alcançar o público. Isto é, eles vão preferir continuar pagando o concorrente que eles já conhecem e confiam.
Precisamos saber quanto a ReceitaWS cobra pelo uso da API deles e se a nossa tem capacidade de ser tão boa quanto. As vezes eles mesmo podem ter algum recurso mais elaborado para obter informações precisas e atualizadas das empresas.
Esses são alguns pontos importantes a levantar porque algum investimento será preciso pra manter a base.
biutas commentedon Jun 8, 2020
Exato, sei que é possível obter os dados em outros orgãos, pois algumas empresas fornecem "quais empresas abriram ontem", mas desconheço onde busca essa info.
wilsonneto-swe commentedon Jun 8, 2020
@farukaf Se for para o lado da AWS não precisa ser o dynamo, usem o RDS onde você tera free tier em mysql, postgres e diversos outros bancos. Quanto a api de início indo pela AWS usaria lambda function onde teria 1 milhão de lambdas executadas sem custo. Já tem banco de dados e sistema online processando 1 milhão de requests sem custo, passando de 1 milhão de requests suponho que o projeto já terá como se manter bem fora da camada free tier.
Apenas a questão da base de dados, se a api será para busca do CNPJ, e é um dado que tem que ser inteiro, eu iria de Redis, com certeza ele baterá qualquer banco relacional e até o no sql. Porém pode ser que de início ele não seja viável por custos, mas que também são baixos.
farukaf commentedon Jun 8, 2020
@wilsonneto-dev o tier gratuido do RDS é de 20gb por 12 meses... mas é uma opção... o ideal seria uma solução gratuita até conseguir esse apoio financeiro.
Amazon Databases