Como funciona a busca por restaurante perto e o que você precisa saber antes de implementar
O conceito de restaurante perto é basicamente uma consulta geoespacial simples na teoria, mas na prática ela quebra de formas bem específicas que poucos documentam. Quando você digita isso num app ou site, o sistema precisa fazer três coisas: capturar sua coordenada GPS atual, converter endereços de restaurantes em coordenadas também, e calcular a distância entre os dois pontos usando uma fórmula de Haversine ou aproximadores mais rápidos como Geohash. O resultado é ordenado por distância, mas é aí que as coisas começam a ficar confusas.
restaurante perto: a realidade técnica por trás da busca
A primeira coisa que todo mundo subestima é a precisão do GPS em ambientes urbanos. Eu passei duas semanas tentando debugar um sistema onde usuários reportavam que restaurantes apareciam com distâncias de 800 metros quando estavam literalmente do outro lado da rua. O problema não era o algoritmo de cálculo de distância, era que o GPS do celular, especialmente em ruas com prédios altos que bloqueiam sinal de satélite, pode ter um erro de até 50 metros. Isso significa que um restaurante que deveria aparecer como "perto" às vezes nem aparece nos primeiros resultados. Minha solução foi implementar um fallback que usa o IP do usuário como coordenada secundária quando a confiabilidade do GPS cai abaixo de um certo nível, e adicionar um raio de busca progressivo. Em vez de buscar apenas num raio de 500 metros, o sistema começa com 300, e se não encontrar resultados suficientes, expande para 500, depois 800. Isso resolve 90% dos casos, mas introduz outro problema que vou mencionar mais abaixo.
Outro ponto que desenvolvedores amadores sempre erram: distância em linha reta versus distância real de navegação. Um restaurante que aparece a 200 metros pela fórmula de Haversine pode na verdade estar a 600 metros walking distance porque precisa cruzar uma via expressa ou dar uma volta grande. A solução profissional é usar a API de Directions do Google ou OpenStreetMap's OSRM para calcular a distância real de pedestre ou carro. Isso adiciona latência à resposta, então o ideal é fazer essa conversão apenas para os top 10 resultados mais próximos, não para todos.
implementação prática: do zero até funcionando
Se você quer construir algo do zero, aqui está o caminho mais direto. Você precisa de uma base de dados com localização geográfica. O formato mais eficiente é usar o tipo GEOGRAPHY do PostgreSQL, que já vem nativamente com funções de distância e indexação espacial via GiST. Cada restaurante fica registrado com um point ou um polygon, dependendo do tamanho do estabelecimento. Restaurantes pequenos podem usar point, mas se o lugar for grande como um shopping food court, polygon é mais preciso. O query básico seria algo como:
👉 Clique no botão abaixo para saber mais sobre o assunto!
SELECT nome, endereco, distancia FROM restaurantes ORDER BY geometria <-> ST_MakePoint(?longitude, ?latitude) LIMIT 10; O operador <-> é o de distância euclidiana no espaço geográfico, e é absurdamente rápido graças ao índice GiST. Em testes práticos com 50 mil restaurantes, essa consulta retorna resultados em menos de 15 milissegundos. Sem indexação espacial, o mesmo query levaria segundos porque faria um scan completo.
Se estiver usando MongoDB, o equivalente é usar o operador $near com um índice 2dsphere. Funciona de forma similar, mas note que o MongoDB não oferece funções de distância tão refinadas quanto o PostGIS para casos como cálculo de trajeto real.
o problema que ninguém conta sobre os dados
A maior dor de cabeça na prática não é o código, é a qualidade dos dados. Já perdi dias inteiros caçando por quê certos restaurantes não apareciam nas buscas. A causa era cadastro desatualizado: o restaurante havia fechado, mudado de endereço, ou tinha coordenadas erradas no banco de dados. Fontes como o Google Places API ajudam, mas elas próprias têm problemas de atualização, especialmente para estabelecimentos pequenos em cidades menores. Uma workaround que funcionou bem foi implementar um sistema de feedback do usuário. Se alguém clica num restaurante que não existe mais ou está no endereço errado, registra isso. Após 5 feedbacks conflitantes para o mesmo estabelecimento, o registro entra em revisão automática. Não é perfeito, mas reduziu drasticamente reclamações.
limitações e quando isso simplesmente não funciona
Você precisa saber os pontos cegos antes de entregar algo pro usuário. Em primeiro lugar, busca por "perto" depende inteiramente da localização atual do usuário. Se a pessoa estiver num avião, num barco, ou com GPS desligado, a funcionalidade fica inútil sem um fallback de localização manual. Segundo, em zonas rurais com poucos restaurantes, o raio de busca precisa ser bastante ampliado, e aí a lista perde completamente o sentido do que "perto" significa. Um problema mais sutil é o viés algorítmico. Plataformas como Google Maps priorizam estabelecimentos que pagam por publicidade ou têm avaliações altas, então um restaurante genuinely mais perto pode aparecer atrás de outro mais distante mas melhor avaliado. Isso é aceitável para apps comerciais, mas se seu objetivo é pureza geográfica, você precisa desconsiderar ranking e mostrar estritamente por proximidade. Aí surge outro conflito: o usuário pode preferir ver restaurantes bem avaliados próximos em vez dos absolutamente mais próximos.
Para quem não quer construir do zero, existem soluções prontas. A Google Places Nearby Search é a mais óbvia, com uma taxa generosa gratuita. O Mapbox Places API é uma alternativa sólida e mais barato em volume. Para projetos open source, o Nominatim do OpenStreetMap permite buscas por proximidade sem custo direto, mas tem limitações sérias de rate limit e precisão inferior em comparação.
