Come aggiungere la ricerca alla tua app: dai filtri semplici alla ricerca full-text

Per aggiungere la ricerca alla tua app, parti dalla soluzione più semplice che funziona: una casella di ricerca che chiama una route del server, la quale filtra le righe del database confrontando la query con alcune colonne, più dei filtri per cose come categoria o prezzo. Quando non basta — ti servono il ranking di pertinenza, la riduzione delle parole alla radice o molti record — passa alla ricerca full-text del tuo database, e passa a un motore di ricerca ospitato solo se ti servono una forte tolleranza ai refusi o risultati istantanei su dati molto grandi. Qualunque cosa scegli, la ricerca deve rispettare i permessi: gli utenti non devono mai trovare record che non sono autorizzati a vedere.

Cosa significa "ricerca" per la tua app

La ricerca copre cose diverse, e la maggior parte delle app ne richiede più di una:

Ricerca per parole chiave: una casella di testo — "trova annunci che contengono 'giardino'".
Filtri: scelte strutturate — categoria, città, fascia di prezzo, data, stato.
Ordinamento: dal più recente, dal più economico, dal più pertinente.
Completamento automatico: suggerimenti mentre scrivi.
Tolleranza ai refusi: "ristornate" trova comunque "ristorante".

Per una directory, una bacheca di lavoro o un negozio, i filtri spesso contano più della casella di testo. Decidi di cosa hai davvero bisogno prima di scegliere uno strumento.

Le tue opzioni

Approccio	Come funziona	Ideale per	Limiti
Filtrare nel browser	Carichi l'elenco e lo filtri in JavaScript	Piccoli elenchi pubblici (qualche centinaio di voci)	Invia tutti i dati a ogni visitatore; lento con elenchi grandi
Corrispondenza di pattern nel database	Query lato server tipo "il nome contiene il testo", senza distinzione di maiuscole	App piccole e medie, strumenti di amministrazione	Nessun ranking; può rallentare su tabelle grandi; nessuna riduzione alla radice
Ricerca full-text nel database	Postgres indicizza le parole e ordina le corrispondenze	La maggior parte delle app ricche di contenuti	Debole con i refusi, a meno di aggiungere una corrispondenza approssimata
Corrispondenza approssimata (trigrammi)	Postgres confronta sequenze di caratteri per similarità	Nomi, campi brevi, tolleranza ai refusi	Richiede un'estensione e un indice; la messa a punto richiede attenzione
Motore di ricerca ospitato	Un servizio separato indicizza i tuoi dati (Algolia, Meilisearch, Typesense, Elasticsearch e altri)	Cataloghi grandi, ricerca istantanea, forte tolleranza ai refusi	Un altro servizio da tenere sincronizzato, pagare e proteggere

Se i tuoi dati sono già in Postgres, la sua ricerca full-text integrata è un ottimo punto di equilibrio. Spezza il testo in parole, riduce ciascuna alla radice (così "correndo" corrisponde a "correre"), ignora le parole comuni e può ordinare i risultati in base a quanto corrispondono. Con l'indice giusto resta veloce anche su tabelle grandi.

Prompt di esempio

Un avvio semplice:

Aggiungi una casella di ricerca e dei filtri alla pagina degli annunci. La ricerca deve confrontare la query con titolo e descrizione, senza distinzione tra maiuscole e minuscole. Filtri: categoria (menu a tendina), città (menu a tendina) e prezzo massimo. Esegui la ricerca sul server con una route API paginata, 20 risultati per pagina. Mantieni la ricerca e i filtri nell'URL così i risultati si possono condividere e il pulsante indietro funziona. Mostra uno stato vuoto chiaro quando non c'è nessuna corrispondenza.

Passare alla ricerca full-text:

Passa la ricerca degli annunci alla ricerca full-text di Postgres su titolo (con peso maggiore) e descrizione. Aggiungi l'indice giusto, ordina i risultati per pertinenza e mantieni i filtri e la paginazione esistenti. Non cambiare nessun dato esistente.

Aggiungere tolleranza ai refusi per i nomi:

Aggiungi una corrispondenza approssimata sul nome dell'attività, così anche piccoli refusi trovano risultati. Usa la similarità con i trigrammi se disponibile, con un indice, e torna alla ricerca attuale se non lo è.

Passo dopo passo

Elenca cosa cercano le persone. Quali campi (titolo, descrizione, tag, nome)? Quali filtri? Se puoi, chiedi a qualche utente reale.
Parti dal server. Aggiungi una route API che riceve la query e i filtri, e restituisce una pagina di risultati. Non caricare tutto nel browser.
Applica i permessi nella query. Se gli utenti vedono solo i propri record, o solo quelli pubblicati, quella condizione va nella stessa query della ricerca.
Aggiungi la paginazione fin dall'inizio — numeri di pagina o "carica altri".
Metti lo stato della ricerca nell'URL (per esempio ?q=giardino&city=leeds). Così i link si condividono, il pulsante indietro funziona, e i motori di ricerca possono scansionare le pagine filtrate se lo vuoi.
Applica il debounce alla ricerca mentre scrivi. Aspetta qualche centinaio di millisecondi dopo l'ultimo tasto prima di interrogare, così non invii una richiesta per ogni carattere.
Aggiungi indici quando sai su quali colonne filtri e cerchi.
Passa di livello alla ricerca full-text, poi alla corrispondenza approssimata, poi a un motore ospitato — solo quando il passo più semplice non basta agli utenti reali.
Testa con dati realistici: centinaia o migliaia di righe, caratteri strani, query vuote, query molto lunghe, altre lingue se le supporti.

Errori comuni

Caricare l'intera tabella nel browser. Va bene per 50 voci, è doloroso per 50.000, e espone ogni record — inclusi quelli che l'utente non dovrebbe vedere.
Una ricerca che ignora i permessi. La ricerca è una fonte comune di perdite: un record privato o una bozza compaiono perché la query ha dimenticato la condizione "solo i miei" o "solo pubblicati".
Costruire SQL con l'input grezzo dell'utente. Usa sempre query parametrizzate. Un builder IA di solito lo fa, ma controlla se vedi stringhe incollate insieme.
Nessuno stato vuoto. "Nessun risultato" con un suggerimento (rimuovi i filtri, controlla l'ortografia) evita che le persone se ne vadano.
Nessun indice. La ricerca sembra andare bene con dati di test e rallenta man mano che crescono i dati reali.
Passare subito a un servizio di ricerca. Poi devi tenere sincronizzata una seconda copia dei dati, gestire le cancellazioni e proteggere un altro set di chiavi — spesso senza un vantaggio visibile.
Dimenticare il mobile. I filtri devono stare su un telefono; un cassetto dei filtri o un pannello richiudibile di solito funziona meglio di una barra laterale.

Checklist

Sai quali campi vengono cercati e quali filtri esistono
La ricerca gira sul server e restituisce risultati paginati
La query applica gli stessi permessi del resto dell'app
L'input dell'utente viene passato come parametri, mai incollato nell'SQL
Lo stato della ricerca vive nell'URL
La digitazione usa il debounce
Le colonne cercate e filtrate sono indicizzate
Gli stati vuoto, senza risultati ed errore sono chiari
Testata con volumi di dati realistici e input disordinato

Aggiungere la ricerca con Mythex

In un'app creata con Mythex, i dati di solito vivono nel database Postgres del progetto, quindi puoi partire dai prompt sopra: prima la corrispondenza di pattern, poi la ricerca full-text di Postgres quando ti serve il ranking. Se vuoi un motore di ricerca ospitato, porta il tuo account e la tua chiave, salvala come segreto del progetto e chiedi all'agente di indicizzarlo e interrogarlo dal server, come descritto in Integrare qualsiasi API.

La ricerca è il cuore di molte app: vedi come costruire un sito directory, come costruire una bacheca di lavoro e come costruire un marketplace per capire come si inserisce nel resto del prodotto.

Domande

Qual è il modo più semplice per aggiungere la ricerca a un'app?

Se i tuoi dati sono in un database, il punto di partenza più semplice è una route del server che filtra le righe con una corrispondenza senza distinzione tra maiuscole e minuscole su alcune colonne. Per un elenco piccolo già caricato nel browser, filtrare nel browser è ancora più semplice.

Per la ricerca mi servono Algolia o Elasticsearch?

Di solito no, almeno all'inizio. La ricerca full-text di Postgres gestisce bene la corrispondenza delle parole, il ranking e da migliaia a milioni di righe. Un motore di ricerca ospitato vale la pena quando ti servono una forte tolleranza agli errori di battitura, risultati istantanei mentre digiti su grandi quantità di dati, o una messa a punto avanzata della pertinenza.

Perché la mia ricerca non trova risultati con i refusi?

La corrispondenza di base e la ricerca full-text standard cercano le parole come sono state digitate (o le loro radici), quindi un errore di battitura non trova nulla. Ti serve una corrispondenza approssimata, come la similarità con i trigrammi in Postgres o un motore di ricerca con tolleranza agli errori.

La ricerca deve girare nel browser o sul server?

Sul server, per tutto ciò che va oltre un piccolo elenco pubblico. La ricerca lato server scala, rispetta i permessi e non invia l'intero set di dati a ogni visitatore.