Alguém abre o app e toca no botão. Antes de o mapa aparecer, antes de um preço surgir, o sistema precisa responder a uma pergunta: de todos os motoristas por aí, qual está mais perto dessa pessoa agora?
Você não precisa resolver isso por conta própria. Guarde cada localização no tipo certo de campo e o banco de dados ordena todo mundo por distância para você, do mais próximo ao mais distante. A novidade é que você também não precisa mais montar isso à mão: um assistente de IA conectado à sua conta consegue criar as tabelas, preenchê-las e fazer a pergunta.
Este guia faz exatamente isso, e depois faz a parte que a maioria dos tutoriais pula: confere a resposta calculando as distâncias separadamente e comparando. Medido em 23 de setembro de 2026 — três tabelas em 516 ms, 15 registros em 729 ms.
Prefere assistir?
O passo a passo original constrói as mesmas três classes e faz a mesma pergunta sobre o motorista mais próximo, inteiramente em conversa.
Como deve ser o modelo de dados?
Três classes e um tipo de campo. Motoristas, passageiros e pontos de interesse precisam, cada um, de um nome e de uma posição, e a posição tem de ser um GeoPoint, não um par de números.
Essa escolha é o guia inteiro em uma decisão. Um GeoPoint guarda latitude e longitude como um único valor, e é a única coisa que os operadores geoespaciais do Parse leem. Guarde os dois números separados e os dados continuam lá, mas $nearSphere e seus parentes deixam de estar disponíveis para você.
| Classe | Campos |
|---|---|
Driver | name (String), position (GeoPoint) |
Passenger | name (String), position (GeoPoint) |
PointOfInterest | name (String), position (GeoPoint) |
Como conectar o cliente de IA?
Por um servidor MCP, que expõe sua conta Back4app ao assistente como um conjunto de ferramentas. Crie uma account key em Account Settings → Account Keys e aponte seu editor para o servidor — o pacote é baixado sob demanda.
{
"mcpServers": {
"back4app": {
"command": "npx",
"args": ["-y", "@back4app/mcp-server-back4app@latest",
"--account-key", "YOUR_ACCOUNT_KEY"]
}
}
}Duas das ferramentas dele carregam este guia: create_parse_app cria o app, e call_parse_server_rest_api faz todo o resto — definir schemas, inserir registros e rodar queries, em lotes.
Como criar as classes e os dados?
Descrevendo-os. O app foi criado primeiro, depois os três schemas, depois os registros — cada etapa uma instrução, não um arquivo.
Crie um app chamado uber-clone-demo. Nele, crie as classes Driver, Passenger e PointOfInterest, cada uma com uma string name e um GeoPoint position. Depois adicione cinco de cada, usando coordenadas reais de Nova York para os pontos de interesse.
Criar o app levou 3,4 segundos. Os três schemas voltaram juntos em 516 ms, cada um reportando os campos que tinha definido. Os 15 registros entraram em um único lote em 729 ms, todos os quinze devolvendo HTTP 201.
Para os pontos de referência, coordenadas reais importam: as distâncias mais adiante só fazem sentido se a Estátua da Liberdade estiver onde a Estátua da Liberdade está.
Como encontrar o motorista mais próximo?
Com $nearSphere, que ordena por distância para você. Leia a posição do passageiro e consulte Driver com esse ponto — o Parse devolve as linhas já ordenadas do mais próximo ao mais distante, então não há etapa de ordenação nem cálculo de distância no seu código.
{
"position": {
"$nearSphere": {
"__type": "GeoPoint",
"latitude": 40.7291,
"longitude": -73.9965
}
}
}Para o passageiro parado em 40.7291, −73.9965, isso devolveu Nadia Okonkwo, depois Priya Raman, depois Ana Ferreira. A ordem não é óbvia a olho nu: Ana Ferreira tem longitude quase idêntica à do passageiro, o que a faz parecer a mais próxima até você levar a latitude em conta.
A resposta do banco de dados está mesmo certa?
Não confie na palavra dele. A ordenação foi recalculada a partir das mesmas coordenadas com uma fórmula de haversine simples, fora do banco de dados, e comparada.
1. Nadia Okonkwo 1.231 mi (1.981 km)
2. Priya Raman 1.448 mi (2.331 km)
3. Ana Ferreira 1.589 mi (2.558 km)
4. Marcus Hale 2.078 mi (3.344 km)
5. Tomas Vidal 4.058 mi (6.531 km)Mesma ordem, incluindo a troca nada óbvia. Mas bater a ordem é um teste fraco — uma ordenação pode estar certa com as distâncias erradas. Então as magnitudes também foram testadas, adicionando $maxDistanceInMiles e percorrendo o raio pelos intervalos calculados.
| Raio pedido | Motoristas devolvidos | Esperado pela tabela |
|---|---|---|
| 1,2 mi | 0 | o mais próximo está a 1,231 — nenhum deveria entrar |
| 1,3 mi | 1 | só Nadia |
| 1,5 mi | 2 | Nadia, Priya |
| 1,6 mi | 3 | + Ana |
| 2,1 mi | 4 | + Marcus |
Toda fronteira caiu exatamente onde o cálculo independente disse que cairia. O Parse não está aproximando aqui, e os números são seguros para precificar uma corrida.
Como calcular o preço da corrida?
Peça a distância entre dois pontos armazenados e multiplique. Com as posições já no banco de dados, a tarifa é uma query e uma multiplicação.
A corrida daquele passageiro até a Estátua da Liberdade mede 3,731 milhas; a um dólar por milha, sai por US$ 3,73. Isso é distância em linha reta, que é o número certo para uma demo e o número errado para uma tarifa real — a distância por ruas é maior, e qualquer precificação em produção precisa de um serviço de rotas, não de uma fórmula de grande círculo.
O banco de dados diz de bom grado a distância entre dois pontos. O que ele não diz é que ninguém consegue atravessar o rio Hudson dirigindo em linha reta.
O que precisa mudar antes de isso virar algo real?
As permissões, primeiro. Abra o Database browser e todo registro criado nesta execução mostra uma ACL de Public Read + Write — qualquer pessoa com a chave de cliente consegue ler ou sobrescrever qualquer um deles. Esse é o padrão do Parse, não uma decisão do cliente de IA, e numa classe que guarda a posição de pessoas em tempo real é exatamente o padrão errado.
As posições dos motoristas também precisam se mover. Tudo aqui é um retrato estático; um sistema de verdade atualiza o GeoPoint de um motorista continuamente e consulta o valor atual, o que muda o volume de escritas em ordens de grandeza e torna um índice no campo de posição obrigatório.
Nada disso muda o modelo, e esse é o ponto que vale levar. Três classes, um campo GeoPoint em cada uma e um operador de query que faz a geometria — a forma está certa desde o primeiro prompt, e o que sobra é o trabalho de deixá-la segura e mantê-la atualizada.
