[DÚVIDA] Contribuição e utilização

[LorhanSohaky]

Olá, sou um dos mantenedores do BrasilAPI e estamos estudando maneiras de melhorar nossa API de ceps e encontramos vocês.

Tenho pensado em todo request de cep bater na API de vocês e caso não encontre consultar API de terceiros. Com isso podemos contribuir para a construção dessa base aberta de ceps.

1. Podemos automatizar a abertura de PRs para que os ceps que não encontramos no OpenCEP, buscar em outra fonte e abrir PR?
2. Quando vocês não encontram algum CEP, vocês buscam em alguma fonte? Porque se isso acontece e o BrasilAPI for uma das fontes, teremos um "loop"

Desde já agradeço a atenção

[hiuryanderson]

Olá Lorhan,

Fiquei impressionado com a Brasil API; será uma ferramenta valiosa para acessar informações básicas sobre o Brasil.

Quanto à nossa API, foi projetada para lidar com um grande volume de acessos, então você pode utilizá-la sem preocupações!

Atualmente, temos um script automatizado que verifica outras bases de dados e cria Pull Requests automaticamente, além de atualizar o conteúdo online.

https://update.opencep.com/13650007

Este script força a atualização dos CEPs através dos Correios (Não utilizamos a Brasil API), gera um novo arquivo JSON e limpa o cache para permitir novos acessos.

No entanto, ele enfrenta duas questões:

• Há um atraso na atualização do sistema de cache, devido à demora na compilação do novo JSON pelo sistema do GitHub Pages.

• A capacidade de acessos é limitada, pois a função utiliza o CloudFlare Works, o que nos obriga a restringir o acesso para evitar custos elevados decorrentes do uso excessivo, em detrimento do sistema de cache.

Recomendo a utilização dele somente caso a resposta a primeira solicitação não seja conforme o esperado.

[LorhanSohaky]

Olá Lorhan,

Fiquei impressionado com a Brasil API; será uma ferramenta valiosa para acessar informações básicas sobre o Brasil.

Quanto à nossa API, foi projetada para lidar com um grande volume de acessos, então você pode utilizá-la sem preocupações!

Atualmente, temos um script automatizado que verifica outras bases de dados e cria Pull Requests automaticamente, além de atualizar o conteúdo online.

https://update.opencep.com/13650007

Este script força a atualização dos CEPs através dos Correios (Não utilizamos a Brasil API), gera um novo arquivo JSON e limpa o cache para permitir novos acessos.

No entanto, ele enfrenta duas questões:

• Há um atraso na atualização do sistema de cache, devido à demora na compilação do novo JSON pelo sistema do GitHub Pages.
• A capacidade de acessos é limitada, pois a função utiliza o CloudFlare Works, o que nos obriga a restringir o acesso para evitar custos elevados decorrentes do uso excessivo, em detrimento do sistema de cache.

Recomendo a utilização dele somente caso a resposta a primeira solicitação não seja conforme o esperado.

1. Esse script roda automaticamente para os ceps que foram pesquisados, mas não encontrados? Caso contrário podemos chamar essa rota para caso não encontremos na rota principal.
2. Para essa rota de update, vocês já têm uma blacklist para não consultar ceps que já foram dados como inexistentes? Pelo menos por x dias? Digo isso porque alguns dos nossos usuários tentam fazer fullscan, então podemos gerar diversas consultas repetidas para ceps como 00000000.
3. Sobre a função de update, recomendo dar uma olhada no cep promise. Ele faz a busca em diversos provedores ao mesmo tempo, o que diminui o tempo de resposta

[hiuryanderson]

Olá Lorhan,
Fiquei impressionado com a Brasil API; será uma ferramenta valiosa para acessar informações básicas sobre o Brasil.
Quanto à nossa API, foi projetada para lidar com um grande volume de acessos, então você pode utilizá-la sem preocupações!
Atualmente, temos um script automatizado que verifica outras bases de dados e cria Pull Requests automaticamente, além de atualizar o conteúdo online.
https://update.opencep.com/13650007
Este script força a atualização dos CEPs através dos Correios (Não utilizamos a Brasil API), gera um novo arquivo JSON e limpa o cache para permitir novos acessos.
No entanto, ele enfrenta duas questões:

• Há um atraso na atualização do sistema de cache, devido à demora na compilação do novo JSON pelo sistema do GitHub Pages.
• A capacidade de acessos é limitada, pois a função utiliza o CloudFlare Works, o que nos obriga a restringir o acesso para evitar custos elevados decorrentes do uso excessivo, em detrimento do sistema de cache.

Recomendo a utilização dele somente caso a resposta a primeira solicitação não seja conforme o esperado.

1. Esse script roda automaticamente para os ceps que foram pesquisados, mas não encontrados? Caso contrário podemos chamar essa rota para caso não encontremos na rota principal.
2. Para essa rota de update, vocês já têm uma blacklist para não consultar ceps que já foram dados como inexistentes? Pelo menos por x dias? Digo isso porque alguns dos nossos usuários tentam fazer fullscan, então podemos gerar diversas consultas repetidas para ceps como 00000000.
3. Sobre a função de update, recomendo dar uma olhada no cep promise. Ele faz a busca em diversos provedores ao mesmo tempo, o que diminui o tempo de resposta

1. Ele não roda automaticamente, pois isso elevaria muito o custo para utilização para ceps incorretos! O ideal seria chamar essa rota para atualizar um cep que encontrou em algum outro sistema! Essa seria uma rota automática para abertura de PR e atualização do sistema ao mesmo tempo.

2. Realmente não temos essa função, pois o ideal dessa rota seria para atualizar com um CEP que já foi confirmado que está incorreto no sistema principal.

3. Não conhecia, mas darei uma olhada com certeza. Essa rota é muito mais lenta pois faz as seguintes funções:

• Verifica a existência e atualização do CEP nos Correios
• Acessa o GitHub e cria um commit
• Limpa o Cache do CloudFlare para os próximos acessos.

Essas várias apis que fazem ele ficar lento, já que dependemos de 3 servidores distintos.

[LorhanSohaky]

Olá Lorhan,
Fiquei impressionado com a Brasil API; será uma ferramenta valiosa para acessar informações básicas sobre o Brasil.
Quanto à nossa API, foi projetada para lidar com um grande volume de acessos, então você pode utilizá-la sem preocupações!
Atualmente, temos um script automatizado que verifica outras bases de dados e cria Pull Requests automaticamente, além de atualizar o conteúdo online.
https://update.opencep.com/13650007
Este script força a atualização dos CEPs através dos Correios (Não utilizamos a Brasil API), gera um novo arquivo JSON e limpa o cache para permitir novos acessos.
No entanto, ele enfrenta duas questões:

• Há um atraso na atualização do sistema de cache, devido à demora na compilação do novo JSON pelo sistema do GitHub Pages.
• A capacidade de acessos é limitada, pois a função utiliza o CloudFlare Works, o que nos obriga a restringir o acesso para evitar custos elevados decorrentes do uso excessivo, em detrimento do sistema de cache.

Recomendo a utilização dele somente caso a resposta a primeira solicitação não seja conforme o esperado.

1. Esse script roda automaticamente para os ceps que foram pesquisados, mas não encontrados? Caso contrário podemos chamar essa rota para caso não encontremos na rota principal.
2. Para essa rota de update, vocês já têm uma blacklist para não consultar ceps que já foram dados como inexistentes? Pelo menos por x dias? Digo isso porque alguns dos nossos usuários tentam fazer fullscan, então podemos gerar diversas consultas repetidas para ceps como 00000000.
3. Sobre a função de update, recomendo dar uma olhada no cep promise. Ele faz a busca em diversos provedores ao mesmo tempo, o que diminui o tempo de resposta

1. Ele não roda automaticamente, pois isso elevaria muito o custo para utilização para ceps incorretos! O ideal seria chamar essa rota para atualizar um cep que encontrou em algum outro sistema! Essa seria uma rota automática para abertura de PR e atualização do sistema ao mesmo tempo.
2. Realmente não temos essa função, pois o ideal dessa rota seria para atualizar com um CEP que já foi confirmado que está incorreto no sistema principal.
3. Não conhecia, mas darei uma olhada com certeza. Essa rota é muito mais lenta pois faz as seguintes funções:

• Verifica a existência e atualização do CEP nos Correios
• Acessa o GitHub e cria um commit
• Limpa o Cache do CloudFlare para os próximos acessos.

Essas várias apis que fazem ele ficar lento, já que dependemos de 3 servidores distintos.

2. A resposta é diferente de quando é um cep inválido e de quando é um que ainda não está no git?
3. Se me permitir, posso sugerir algumas melhorias:

• em vez de invalidar o cache a cada novo push, criar um cron para rodar diariamente (ou a cada X horas) verificando se houve um novo push e só nesse caso invalidar o cache
• como vamos consultar outros provedores no caso de não ter na sua, talvez possamos enviar essa resposta para diminuir parte do tempo de requisição

[hiuryanderson]

Olá Lorhan,
Fiquei impressionado com a Brasil API; será uma ferramenta valiosa para acessar informações básicas sobre o Brasil.
Quanto à nossa API, foi projetada para lidar com um grande volume de acessos, então você pode utilizá-la sem preocupações!
Atualmente, temos um script automatizado que verifica outras bases de dados e cria Pull Requests automaticamente, além de atualizar o conteúdo online.
https://update.opencep.com/13650007
Este script força a atualização dos CEPs através dos Correios (Não utilizamos a Brasil API), gera um novo arquivo JSON e limpa o cache para permitir novos acessos.
No entanto, ele enfrenta duas questões:

• Há um atraso na atualização do sistema de cache, devido à demora na compilação do novo JSON pelo sistema do GitHub Pages.
• A capacidade de acessos é limitada, pois a função utiliza o CloudFlare Works, o que nos obriga a restringir o acesso para evitar custos elevados decorrentes do uso excessivo, em detrimento do sistema de cache.

Recomendo a utilização dele somente caso a resposta a primeira solicitação não seja conforme o esperado.

1. Esse script roda automaticamente para os ceps que foram pesquisados, mas não encontrados? Caso contrário podemos chamar essa rota para caso não encontremos na rota principal.
2. Para essa rota de update, vocês já têm uma blacklist para não consultar ceps que já foram dados como inexistentes? Pelo menos por x dias? Digo isso porque alguns dos nossos usuários tentam fazer fullscan, então podemos gerar diversas consultas repetidas para ceps como 00000000.
3. Sobre a função de update, recomendo dar uma olhada no cep promise. Ele faz a busca em diversos provedores ao mesmo tempo, o que diminui o tempo de resposta

1. Ele não roda automaticamente, pois isso elevaria muito o custo para utilização para ceps incorretos! O ideal seria chamar essa rota para atualizar um cep que encontrou em algum outro sistema! Essa seria uma rota automática para abertura de PR e atualização do sistema ao mesmo tempo.
2. Realmente não temos essa função, pois o ideal dessa rota seria para atualizar com um CEP que já foi confirmado que está incorreto no sistema principal.
3. Não conhecia, mas darei uma olhada com certeza. Essa rota é muito mais lenta pois faz as seguintes funções:

• Verifica a existência e atualização do CEP nos Correios
• Acessa o GitHub e cria um commit
• Limpa o Cache do CloudFlare para os próximos acessos.

Essas várias apis que fazem ele ficar lento, já que dependemos de 3 servidores distintos.

2. A resposta é diferente de quando é um cep inválido e de quando é um que ainda não está no git?
3. Se me permitir, posso sugerir algumas melhorias:

• em vez de invalidar o cache a cada novo push, criar um cron para rodar diariamente (ou a cada X horas) verificando se houve um novo push e só nesse caso invalidar o cache
• como vamos consultar outros provedores no caso de não ter na sua, talvez possamos enviar essa resposta para diminuir parte do tempo de requisição

2 - A verificação é bem simples: O script confirma checa o novo CEP nos Correios e adiciona no github, ele não faz nenhuma verificação no projeto atual. Ele só força a atualização independente de já existir ou não.

3.1 - Gostei muito da sugestão de fazer um cron para verificar o cache, assim com certeza diminuiria o tempo de cache deixaria muito mais estável a aplicação.
3.2 - Essa também é uma solicitação válida, mas eu teria que conferir os dados para ter certeza da validade dos dados, pois como são externos qualquer um poderia colocar dados inválidos.

Já vou arrumar esse script para ficar mais rápido.