Search vs Filtered no Bubble: Qual usar e quando? (Guia Técnico)

Search vs Filtered no Bubble: O que realmente muda?

Se você já desenvolve no Bubble há algum tempo, com certeza se deparou com essa dúvida:

"Devo usar um Search direto no banco ou puxar tudo e depois filtrar com :filtered?"

A resposta não é tão simples quanto parece — e impacta diretamente na performance do seu app.

Neste post, vamos entender:

• A diferença real entre Search e Filtered

• Quando cada um acontece (client vs server)

• O que isso impacta no seu app

• Exemplos práticos e armadilhas comuns

• Boas práticas para apps escaláveis

1. O que é o Search no Bubble?

O Search for [Tipo de Dado] é a forma padrão de buscar dados no banco. Ele executa uma consulta diretamente no servidor, trazendo apenas os registros que batem com os critérios definidos nos constraints.

Exemplo:

Search for Usuários:sorted by Data de criação (descending)

Características:

• Executado server-side

• Altamente performático, pois o Bubble só traz o necessário

• Suporta filtros, ordenação, busca por texto, etc.

• Pode ser paginado (usando :items until #, por exemplo)

2. E o que é :filtered?

O :filtered é um operador aplicado após uma lista já carregada. Isso significa que o Bubble primeiro traz todos os dados da busca inicial (ou de uma lista salva) para o navegador do usuário, e só depois aplica os filtros.

Exemplo:

Search for Usuários:filtered (Condição: idade > 30)

Nesse exemplo, todos os usuários serão carregados, e só depois o filtro será aplicado no navegador do usuário.

3. Client-side vs Server-side: A grande diferença

Usar :filtered em listas grandes é um dos erros mais comuns e graves que vejo em apps de iniciantes no Bubble. Isso pode:

• Deixar o app lento (trazendo centenas de registros desnecessários)

• Aumentar o tempo de carregamento

• Piorar a experiência em dispositivos móveis

• Prejudicar a escalabilidade

4. Quando usar Search?

Quase sempre.
Principalmente quando você precisa:

• Trazer muitos registros com condições claras

• Paginar resultados

• Filtrar antes mesmo do carregamento (como num repeating group)

Exemplo ideal:

Search for Pedidos (Constraint: Status = "Entregue")

5. Quando o :filtered pode ser útil?

Apesar dos riscos, :filtered tem seu lugar:

✅ Quando você já tem os dados carregados por outro motivo
✅ Quando precisa aplicar filtros dinâmicos e complexos que não são suportados diretamente nos constraints do Search (ex: OR entre campos, ou condições envolvendo listas internas)
✅ Em filtros locais após a busca inicial (como em filtros de frontend mais interativos, com pouca quantidade de dados)

Exemplo válido:

Você carrega os 10 últimos produtos visualizados por um usuário e permite filtrar localmente por categoria. Current User's produtos_visualizados:filtered (Categoria = "Eletrônicos")

6. Casos de uso e armadilhas reais

❌ Erro comum:

Search for Produtos:filtered (Preço > 100) → Aqui você está puxando todos os produtos do banco e filtrando no navegador. Péssimo para performance.

✅ Correto:

Search for Produtos (Constraint: Preço > 100) → Aqui você já pede ao servidor só os produtos com preço acima de 100.

7. Dica bônus: Combine com os operadores :sorted, :items until #, :unique

A forma como você encadeia operadores também afeta o desempenho.

Search for Usuários (Constraint: ativo = yes):sorted by Nome:items until #50 → Isso faz a busca paginada e ordenada diretamente no servidor. Muito mais leve do que puxar tudo e paginar via :filtered.

8. Conclusão

Saber a diferença entre Search e :filtered é mais do que questão técnica.
É estratégia de performance.

No Bubble, como em qualquer plataforma, escalar exige boas decisões desde o início.
Evitar :filtered em listas grandes é uma dessas decisões.
Usar Search corretamente é outra.

Se você quer construir apps profissionais, que aguentem dezenas ou centenas de usuários, isso faz toda a diferença.

Quer ajuda para deixar seu app mais performático?

Eu trabalho com automações, integrações e apps em Bubble com foco em performance real.
Se você quer otimizar um projeto ou precisa de ajuda com backend workflows, repensar filtros ou estruturar bem seu banco, me chama. Vamos conversar.