Skip to content

Refatorar busca de municípios (IBGE): definir estratégia de dados #572

Description

@camilamaia

Descrição

Hoje temos duas funções que consultam fontes distintas para o mesmo domínio (códigos/nomes de municípios IBGE):

  • get_municipality_by_code(code) → API do IBGE (on-line)
  • get_code_by_municipality_name(name, uf) → arquivo local data/cities_code.json (off-line)

Isso abre margem para divergências e comportamentos inconsistentes.

Objetivo

Refatorar para adotar uma estratégia única de acesso a dados, utilizando apenas a API oficial do IBGE

Activity

  1. added
    release blockerEssa issue precisa ser resolvida antes do próximo release, pois é essencial p/ garantir a qualidade
    and removed on Sep 9, 2025
  2. GomesMarcos commented on Sep 11, 2025

    @GomesMarcos

    Olá! Posso pegar essa?

  3. GomesMarcos commented on Sep 14, 2025

    @GomesMarcos

    @camilamaia

    Tenho uma dúvida acerca da atualização do arquivo local: um GET na API do IBGE retorna todas as cidades.

    Dito isto, atualizar o arquivo de cidades de tempos em tempos utilizando este endpoint é uma opção? Se sim, o versionamento deste arquivo se daria como?

    Ignorar este versionamento e, ao fazer um primeiro GET com code, poderíamos realizar um segundo GET na API do IBGE e criar um arquivo local a partir deste seria uma opção?

    Só falto este detalhe para finalizar este refactor e, caso sigamos pela opção de criar um arquivo com base na consulta da API sem passar o code muda toda a estrutura do data/cities_code.json. A vantagem é que "espelharíamos" a API localmente e, para atualizar, de mês em mês poderíamos refazer esta consulta na base da API.

    Podemos validar esse período pela última data de atualização.
    Ex: last_modified = datetime.fromtimestamp(file_path.stat().st_mtime)

  4. camilamaia commented on Sep 19, 2025

    @camilamaia
    MemberAuthor

    Oii @GomesMarcos ! Claro, vou te dar o assign da issue!

    Conversando com o @niltonpimentel02, achamos que pode ser mais interessante seguir pelo caminho simples e trabalhar direto com a API do IBGE, sem versionar o arquivo local, sem nenhum fallback. Dessa forma, reduzimos a complexidade de mantermos um dataset “espelhado” e evitamos o risco de desatualização ou divergências entre a API e o arquivo.

    Se para o cliente for importante ter esse dataset versionado, nada impede que ele próprio mantenha um arquivo a partir da API — mas não precisamos assumir isso como responsabilidade do projeto neste momento.

    A ideia é validar primeiro a estratégia mais enxuta (API como fonte única). Se em algum momento isso se mostrar um problema (ex.: requisitos de disponibilidade offline, performance, auditoria ou compliance), podemos revisar a abordagem e introduzir o versionamento local no futuro.

    Vai ficar mais simples e mais fácil de manter por agora!

  5. camilamaia commented on Sep 19, 2025

    @camilamaia
    MemberAuthor

    @GomesMarcos já atualizei a descrição da issue também! Valeu demais!

  6. GomesMarcos commented on Sep 19, 2025

    @GomesMarcos

    Valeeeu! Vou ajustar e em breve mando o PR!
    Vamo que Vamo! 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

refactorrelease blockerEssa issue precisa ser resolvida antes do próximo release, pois é essencial p/ garantir a qualidade

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions