API para consulta de CEPs

[thiamsantos]

Olá pessoal, tranquilo. Eu estava com ideia de criar um serviço de consulta de CEPs bem no estilo do viacep ou do cepaberto mas com a diferença de ser totalmente open source e poder ser rodada internamente na sua infra. Porque é um absurdo a base de dados do cep ser fechada.

A ideia era fazer um serviço um web pronta para produção que os desenvolvedores pudessem acessar externamente ou rodar a sua própria cópia da aplicação. Para isso o projeto teria que ser total open-source, imagens do docker deveriam ser disponibilizadas assim como facilitar a publicação no heroku. E também todo o banco de dados dos CEPs teria que ser aberta. Algo semelhante aos projetos freegeoip, url-to-pdf-api e imgproxy. O principal objetivo é criar um serviço extramamente rápido e que todos possam usar.

Para que o serviço tenha velocidade é importante escolher uma stack à altura eu pensei em usar go ou elixir (o elixir eu tenho mais familiaridade mas o go é mais rápido). É importante também cachear as consultas de maneira agressiva para diminuir o tempo de resposta por tirar a consulta ao banco de dados. Eu até cheguei a criar um POC usando go, PostgreSQL e Redis (para cache). O que me impediu de prosseguir com mais vontade foi o fato de eu não ter uma base de dados completa com os CEPs. Eu estava usando uma parte disponibilizada pelo cepaberto.

O que vocês acham da ideia? Há alguma implicação legal que impeça a criação desse serviço e a disponibilização gratuita dos dados? Gostaria muito de ouvir a opinião de vocês.

[rafa-acioly]

O que vocês acham da ideia? Há alguma implicação legal que impeça a criação desse serviço e a disponibilização gratuita dos dados? Gostaria muito de ouvir a opinião de vocês.

Não acho que tenha algum problema judicial e acho super legal a iniciativa, se precisar de contribuição com GO me coloco a disposição.

Acredito que o único e possível problema seja a atualização do banco de dados com as informações, se cada pessoa tiver seu próprio banco de dados vai ser um pouco "difícil" e custoso ter que atualizar o container toda vez que os dados forem alterados com correção ortográfica e etc...

[thiamsantos]

Não acho que tenha algum problema judicial e acho super legal a iniciativa, se precisar de contribuição com GO me coloco a disposição.

Legal, acho que o go se encaixa bem nessa aplicação né.

Acredito que o único e possível problema seja a atualização do banco de dados com as informações, se cada pessoa tiver seu próprio banco de dados vai ser um pouco "difícil" e custoso ter que atualizar o container toda vez que os dados forem alterados com correção ortográfica e etc...

O legal seria se nós disponibilizarmos o banco inicial e depois talvez disponibilizar scripts que façam as atualizações dos dados. O dev poderia passar os dados de acesso de acesso do banco dele e o script atualizar os dados, estilo uma migration.

Eu me preocupo bastante em como conseguir todos os dados do cep. Eu pensei em fazer uma vaquinha, sei lá, e comprar a base em um serviço desse ou do próprio correios.

[rafa-acioly]

@thiamsantos acho que você conseguiria essa base de dados com cep de graça, só precisamos procurar melhor.

Então a stack seria essa?

1. Go
2. Redis
3. Postgres

Não sei muito bem se apenas buscar cep seja algo extremamente útil, pensei na utilização e me fiz a seguinte pergunta:

Porque eu colocaria na minha infra uma "api" para buscar cep sendo que existem apis prontas que eu posso consumir? o que eu faço só com o cep para valer a pena incluir isso na minha infra?

Acho que buscar os preços de frete seria mais crucial e útil, o que acha?

[thiamsantos]

Então a stack seria essa?

Não sei, tá aberto a discussão. Eu falei dessa porque foi a minha ideia inicial.

Porque eu colocaria na minha infra uma "api" para buscar cep sendo que existem apis prontas que eu posso consumir? o que eu faço só com o cep para valer a pena incluir isso na minha infra?

A ideia é termos também uma api nossa rodando certinho, que as pessoas possam usar ser fazer o deploy de nada. Mas acontece que algumas empresas preferem rodar as coisas internamente por alguma regra interna. Outro motivo que também válido é em aplicações de alta performance é interessante trazer os serviços mais pra perto para diminuir a latência, diminuir a chance de erros (tipo nós esquecermos de pagar a mensalidade da hospedagem), não ficar dependente de mais uma aplicação externa e também poder monitorar mais de perto.

[rafa-acioly]

Entendo,

Acho a stack que você sugeriu de inicio muito boa e se precisar de de colaboração não deixe de me chamar!

[rodrigooler]

@thiamsantos eu topo participar também! =D

[mahenrique94]

Boa inciativa @thiamsantos, um tempo atrás eu fiz um web service que umas das funções é a consulta de CEP, além de outras...

Utilize Java com JAX-RS.

Link da Documentação.

O mesmo esta hospedado na Heroku, o unico detalhe é questão de consumo de daemon, se passar ai fica fora ou precisar pagar.

Abraçooos, parabens pela iniciativa

[thiamsantos]

@rafa-acioly @rodrigooler show!

@mahenrique94 excelente projeto! De onde você pegou a base de dados do cep?

[allbarbos]

@thiamsantos Iniciei um projeto parecido, totalmente open source e não apenas de CEP, e sim de todos os dados que são de utilidade publica, como FIPE, CEP, Indicadores/histórico de inflação e etc..

Estou definindo as coisas ainda (server, tecnologia e etc), pensando em linguagens mais tradicionais e simples, servidor com hospedagem barata e etc, a afim de no futuro ter uma galera pra contribuir e ainda não depender de hospedagens gratuitas.

[thiamsantos]

Estou definindo as coisas ainda (server, tecnologia e etc), pensando em linguagens mais tradicionais e simples, servidor com hospedagem barata e etc.

Eu acho essencial utilizar plataformas de alta performance como go e elixir, para atrair mais usuários, se não muitos não terão motivos de usar o serviço no lugar do viacep ou outro semelhante. Na questão de preço eu não vejo muito impedimento, o heroku e outros semelhantes não são caros.

@thiamsantos Iniciei um projeto parecido, totalmente open source e não apenas de CEP, e sim de todos os dados que são de utilidade publica, como FIPE, CEP, Indicadores/histórico de inflação e etc..

Tens um link para olhar? A minha ideia inicial de fazer apenas de CEP é justamente para facilitar a adoção, nem todo mundo usa os outros dados. E também porque seria mais rápido de desenvolver. Seguindo a filosofia de microserviços.

[allbarbos]

@thiamsantos Dessa versão open source ainda é tudo draft.

Anteriormente onde trabalho dei a idea da gente construir internamente e depois abrir pra galera, no entanto acabou que fiz todos os paranauês e na hora de abrir ficou no "Vamos ver o que podemos ganhar com isso" - https://api.cenarioconsulta.com.br/documentacao

Agora a ideia é fazer como um projeto "pessoal", onde o objetivo da plataforma seria gradativamente centralizar em um único lugar todos os dados públicos que estão espalhados ou ocultos pela internet e que na maioria dos casos quando possibiliza que a gente utilize, não oferece uma interface REST ou SOAP.

[thiamsantos]

@allbarbos a sua ideia de centralizar é bem legal. Não gostaria de contribuir com o serviço de CEP e depois a gente expande ou cria outro serviço com essa sua ideia.

Anteriormente onde trabalho dei a idea da gente construir internamente e depois abrir pra galera, no entanto acabou que fiz todos os paranauês e na hora de abrir ficou no "Vamos ver o que podemos ganhar com isso" - https://api.cenarioconsulta.com.br/documentacao

De onde era obtidos os dados? Era redirecionado para outro serviço?

[allbarbos]

@thiamsantos Bora bater um papo, poderiamos iniciar com CEP sim. Em relação aos dados, na época fizemos alguns bots pra sair buscando em ws, sites e etc.

[mahenrique94]

@thiamsantos eu consumo o serviço do ViaCEP, mas a ideia era montar uma base de dados minha, porém, me faltou e falta tempo para realizar esse procedimento, então encapsulei o consumo de cep em meu web service, assim quando eu tiver minha própria base, as aplicações que fazem uso não sofreram alterações.

[thiamsantos]

@thiamsantos eu consumo o serviço do ViaCEP, mas a ideia era montar uma base de dados minha, porém, me faltou e falta tempo para realizar esse procedimento, então encapsulei o consumo de cep em meu web service, assim quando eu tiver minha própria base, as aplicações que fazem uso não sofreram alterações.

Entendi. Mas no nosso caso acho que não se aplica fazer isso. Acho que com a ajuda de todos consigamos reunir tempo para criar a nossa base de dados e torná-la publica.

[thiamsantos]

Agora questões importantes:

• Qual stack vocês sugerem? Seguir com go, PostgreSQL e redis mesmo? Lembrando que a performance é o ponto mais importante aqui. Eu penso que talvez o crystal e o elixir fossem boas alternativas ao go. O crystal por ter uma sintaxe "melhor" que o go e ser mais rápido. E o elixir por ter um excelente framework web e uma grande comunidade.
• E quanto à obtenção dos dados? Qual abordagem vocês acham a melhor? Comprar uma base de dados pronta? Usar a base disponibilizada pelo cepaberto? Varrer as APIs existentes de CEP e consultar todos os CEPs possíveis? Ou talvez um crawler mais complexo como o do postmon?

[allbarbos]

Nunca utilizei GO, então não vou opinar, no entanto havia pensando em Rails e MariaDB.

Agora em relação aos dados, a ideia seria deixar o banco de dados aberto também? Como funcionaria? Porque pode ser que usem os dados para comercializar ou então fazer alguma merda também.

[thiamsantos]

Agora em relação aos dados, a ideia seria deixar o banco de dados aberto também? Como funcionaria? Porque pode ser que usem os dados para comercializar ou então fazer alguma merda também.

A ideia é deixar aberto os dados de cep, não todos os dados do banco. Talvez uns csv, ou sql, não sei.

Nunca utilizei GO, então não vou opinar, no entanto havia pensando em Rails e MariaDB.

Realmente, o rails é um excelente framework. Mas não se encaixa muito bem nessa aplicação por causa da performance. A ideia é ter uma aplicação extremamente rápida, e talvez um framework tão grande e tão completo para consultar ceps seja muita coisa. Benchmarks mostram que o ruby é muito inferior à outras linguagens e plataformas. Eu particularmente não gosto do go acho ele muito simples e feio, mas a performance é inegável e a simplicidade no desenvolvimento também. Por isso eu sugeri o crystal ou o elixir, ele tem uma pegada mais parecida com o ruby na questão da qualidade e legibilidade da linguagem mas sem sacrificar a performance. O que você acha?

E quanto ao MariaDB por que você pensa ser uma boa?

[allbarbos]

Entendi, vou dar uma pesquisada em Elixir.

Em relação ao BD, não vejo muita diferença entre MySQL, MariaDB e Postgre - então qualquer um seria diversão! kkk

[mahenrique94]

Cara eu iria de Node + Restify + MongoDB, simples, leve e muito rápidos.

[thiamsantos]

Cara eu iria de Node + Restify + MongoDB, simples, leve e muito rápidos.

Sim são excelentes opções. Mas porque você pensa que o MongoDB se encaixaria bem? Na minha visão os dados são bem relacionais por isso um banco relacional se encaixaria melhor.

Quanto ao Node, a minha principal linguagem é o JavaScript e não vejo problema em usar. Só que eu considero o elixir muito superior em qualidade da linguagem e qualidade da comunidade. Além do paradigma funcional melhorar muito o código e a legibilidade. O JavaScript acaba irritando as vezes, apesar de hoje estar muito melhor. Com async/await tudo é mais lindo. E também, apesar de ser uma diferença não significativa, o elixir é mais rápido.

[thiamsantos]

Eu conversei com o cara do cepaberto e é tranquilo a gente usar os dados que ele disponibiliza. Ele pretende logo logo colocar no ar as partes faltantes da base dados.

[mahenrique94]

Sim são excelentes opções. Mas porque você pensa que o MongoDB se encaixaria bem? Na minha visão os dados são bem relacionais por isso um banco relacional se encaixaria melhor.

Quanto ao Node, a minha principal linguagem é o JavaScript e não vejo problema em usar. Só que eu considero o elixir muito superior em qualidade da linguagem e qualidade da comunidade. Além do paradigma funcional melhorar muito o código e a legibilidade. O JavaScript acaba irritando as vezes, apesar de hoje estar muito melhor. Com async/await tudo é mais lindo. E também, apesar de ser uma diferença não significativa, o elixir é mais rápido.

MongoDB por ser leve, e trazendo um CEP já teriamos tudo dele, sem precisar realizar demais buscas para outras tabelas, além de ser um json muito leve para transitar em rede.

Node por ser facilmente escalável e deployado, além de possuir uma integração excelente com o Mongo.

[allbarbos]

@mahenrique94 Mas e no caso em que você tem 100.000 ceps e precisa buscar o cep 17780-000, fazer um find em uma coleção toda não seria custoso? Quando em um relacional você já teria indice e etc?

[rafa-acioly]

Eu voto por GO, acredito que uma linguagem compilada é sempre a melhor opção para performance.

[thiamsantos]

@mahenrique94 Mas e no caso em que você tem 100.000 ceps e precisa buscar o cep 17780-000, fazer um find em uma coleção toda não seria custoso? Quando em um relacional você já teria indice e etc?

Sim eu acho que o ideal é tabela relacional mesmo, esse negócio de que o mongo é mais rápido é mais marketing do que realidade. A velocidade dele ganha em inserção, mas uma tabela com os índices certinho geralmente é mais rápida que o mongo. Por isso a proposta é cachear em memória com o redis a consulta e usar um banco relacional por baixo.

Eu voto por GO, acredito que uma linguagem compilada é sempre a melhor opção para performance.

Pensando melhor acho que eu também prefiro. A proposta do API é realmente ser a mais rápida possível, o serviço perfeito para o Go.

[mahenrique94]

@mahenrique94 Mas e no caso em que você tem 100.000 ceps e precisa buscar o cep 17780-000, fazer um find em uma coleção toda não seria custoso? Quando em um relacional você já teria indice e etc?

Caso tenha a necessidade, você pode devolver esse CEP em especĩfico sem problemas.

Sim eu acho que o ideal é tabela relacional mesmo, esse negócio de que o mongo é mais rápido é mais marketing do que realidade. A velocidade dele ganha em inserção, mas uma tabela com os índices certinho geralmente é mais rápida que o mongo. Por isso a proposta é cachear em memória com o redis a consulta e usar um banco relacional por baixo.

Descordo, de todos os bancos que utilizei o mongo de longe é o mais rápido, seja para qualquer operação, ele é bem superior a um banco relacional.

[thiamsantos]

Descordo, de todos os bancos que utilizei o mongo de longe é o mais rápido, seja para qualquer operação, ele é bem superior a um banco relacional.

A meu ver ele não é superior não. É apenas diferente, assim como todos os outros bancos que vemos. O objetivo é encontrar a ferramenta certa para a aplicação certa. A questão de performance do banco geralmente uma banco relacional é "mais lento" não porque o banco é realmente lento mas sim porque as tabelas e os relacionamentos foram mal feitos e os índices não foram devidamente colocados. Eu penso que o mongo é um excelente banco e tem seus casos de uso, mas aqui não seria um desses. Os são claramente relacionais: cep -> endereço -> cidade -> estado. Mesmo o mongo sendo um pouco mais rápido que o PostgreSQL, eu não vejo que a diferença seja realmente relevante para justificar o seu uso. Isso porque o que realmente trará a performance vai ser o redis. Por ser chave/valor e em memória as consultas serão extremamente rápidas, muito mais do que qualquer outro banco em disco consegue atingir.

[rafa-acioly]

@hugocarreira eu já conhecia esse obrigado! mas qual o motivo do compartilhamento? acho que foge um pouco da discussão sobre arquitetura e alta disponibilidade.

[thiamsantos]

A stack vamos seguir com Go, PostgreSQL e Redis.

Eu criei uma organização para tocar o projeto. @rafa-acioly @rodrigooler já convidei vocês. @mahenrique94 @allbarbos @diegocosta vocês vão querer participar?

[diegocoxta]

@thiamsantos Pode me colocar, vou tentar ser mais ativo por aqui rs.

[nicolascb]

Oh galera, já existe um webservice dos correios pra isso:

https://apps.correios.com.br/SigepMasterJPA/AtendeClienteService/AtendeCliente?wsdl

[wbotelhos]

Exato @nicolascb , inclusive uso a gem https://github.com/prodis/correios-cep que usa esse serviço.

[rafa-acioly]

@wbotelhos @nicolascb vou tentar explicar melhor o motivo de querermos criar uma API para consultar CEP.

O motivo é ter uma aplicação de alta disponibilidade e velocidade de consulta, nós sabemos que existem API prontas por aí mas a questão é esta que citei.

Aconteceu comigo pouco tempo atrás; estavamos consultando uma api "x" para consultar CEP e fazer um calculo de frete e a api em questão simplesmente saiu do ar, tive alguns problemas pois ocorreram diversos erros em alguns pedidos.

Se eu tivesse uma aplicação na minha propria infraestrutura para que eu pudesse consumir seria ideal porque assim eu não ficaria refem de uma api que eu não sei até quando vai funcionar.

[nicolascb]

@rafa-acioly Eu entendi meu velho... mas porque usaria uma API de terceiros sendo que o próprio correio (que mantém a base de cep atualizada) já disponibiliza uma API para essas consultas? A segunda opção me parece mais segura do que qualquer outra.

[rafa-acioly]

@nicolascb a API do correio da muito problema, tanto em disponibilidade quanto em velocidade de resposta; tenho uns amigos que utilizam woocommerce com o plugin dos correios (que consome o webservice dos correios diretamente) e reclamam que toda semana da problema. :cry:

[symonlopes]

Deus tenha misericórdia de vocês... kkkk

[rafa-acioly]

@blinter tem algo que acrescente na conversa ou alguma ideia? se sim será muito bem vindo, se não evite enviar notificações desnecessárias.

[symonlopes]

Sim, revelar que uma idéia é uma má ideia é uma grande contribuição. É muito nítida a empolgação com tecnologias, e muito provavelmente nenhuma dessas ideias foi para frente.

"Desempenho superior" em uma API de consulta por CEP é um atestado de desenvolvedor empolgado em fazer certo a coisa errada. Fora outros clássicos traços de desenvolvedores inexperientes se empolgando a toa.

Pessoas mais experientes entenderão, e aos inocentes que lerem saberão quando estão prestes a desperdiçar horas de trabalho em coisa inútil.

De nada.

[rafa-acioly]

@blinter você se deu ao trabalho de vir em uma thread que o ultimo comentário foi a mais de um ano só pra querer mostrar o quão superior e inteligente você é? você não tem ideia do que já foi desenvolvido com tudo que falamos aqui porque as conversas sairam dessa thread a mais de um ano.

Leia com mais atenção algumas partes que eu escrevi como por exemplo;

1. https://github.com/backend-br/forum/issues/44#issuecomment-371593210
2. disponibilidade

   Aconteceu comigo pouco tempo atrás; estavamos consultando uma api "x" para consultar CEP e fazer um calculo de frete e a api em questão simplesmente saiu do ar, tive alguns problemas pois ocorreram diversos erros em alguns pedidos. Se eu tivesse uma aplicação na minha propria infraestrutura para que eu pudesse consumir seria ideal porque assim eu não ficaria refem de uma api que eu não sei até quando vai funcionar. (sem falar no desempenho que fica fora do alcance para realizar melhorias)

Se pra você continuar usando alguma API de cep gratuita atende sua demanda, parabéns! espero que você faça bastante doação pra essas APIs gratuitas continuarem a funcionar, espero do fundo do coração que você já tenha doado algum centavo, se ainda não, considere doar.