Sådan tilføjer du søgning til din app: fra simple filtre til fuldtekstsøgning

For at tilføje søgning til din app skal du starte med det enkleste, der virker: en søgeboks, der kalder en serverrute, som filtrerer dine databaserækker ved at matche forespørgslen mod nogle få kolonner, plus filtre for ting som kategori eller pris. Når det ikke er godt nok — du har brug for relevansrangering, ordstammer eller mange poster — skal du skifte til din databases fuldtekstsøgning, og kun gå over til en hostet søgemaskine, hvis du har brug for stærk tolerance over for tastefejl eller øjeblikkelige resultater på meget store data. Uanset hvad du vælger, skal søgningen respektere rettigheder: brugere må aldrig finde poster, de ikke har lov til at se.

Hvad "søgning" betyder for din app

Søgning dækker over et par forskellige ting, og de fleste apps har brug for mere end én:

• Nøgleordssøgning: en tekstboks — "find annoncer, der nævner 'have'".
• Filtre: strukturerede valg — kategori, by, prisinterval, dato, status.
• Sortering: nyeste, billigste, mest relevante.
• Autofuldførelse: forslag mens du skriver.
• Tolerance over for tastefejl: "restuarant" finder stadig "restaurant".

Til et katalog, et jobopslag eller en butik betyder filtrene ofte mere end tekstboksen. Beslut hvilke af disse du faktisk har brug for, før du vælger et værktøj.

Dine muligheder

Hvis dine data allerede ligger i Postgres, er dens indbyggede fuldtekstsøgning en stærk mellemvej. Den deler tekst op i ord, reducerer dem til stammer (så "løbe" matcher "løb"), ignorerer almindelige ord og kan rangere resultater efter, hvor godt de matcher. Med det rette indeks forbliver den hurtig på store tabeller.

Eksempelprompts

En simpel start:

Tilføj en søgeboks og filtre til listesiden. Søgningen skal matche forespørgslen mod titel og beskrivelse, uafhængigt af store/små bogstaver. Filtre: kategori (dropdown), by (dropdown) og maks. pris. Lav søgningen på serveren med en pagineret API-rute, 20 resultater pr. side. Behold søgningen og filtrene i URL'en, så resultaterne kan deles, og tilbage-knappen virker. Vis en venlig tom tilstand, når intet matcher.

Opgradering til fuldtekstsøgning:

Skift søgningen i annoncerne til Postgres fuldtekstsøgning på titel (vægtet højere) og beskrivelse. Tilføj det rette indeks, rangér resultater efter relevans, og behold de eksisterende filtre og paginering. Ændr ingen eksisterende data.

Tilføjelse af tolerance over for tastefejl i navne:

Tilføj fuzzy matching på virksomhedsnavn, så små tastefejl stadig finder resultater. Brug trigram-lighed, hvis det er tilgængeligt, med et indeks, og fald tilbage til den nuværende søgning, hvis ikke.

Trin for trin

1. Liste hvad folk søger efter. Hvilke felter (titel, beskrivelse, tags, navn)? Hvilke filtre? Spørg nogle rigtige brugere, hvis du kan.
2. Start på serveren. Tilføj en API-rute, der tager forespørgslen og filtrene, og returnerer én side med resultater. Indlæs ikke alt i browseren.
3. Anvend rettigheder i forespørgslen. Hvis brugere kun ser deres egne poster, eller kun offentliggjorte, hører den betingelse hjemme i samme forespørgsel som søgningen.
4. Tilføj paginering fra dag ét — sidenumre eller "indlæs flere".
5. Behold søgetilstanden i URL'en (f.eks. ?q=have&city=leeds). Delbare links, en fungerende tilbage-knap, og søgemaskiner kan crawle filtrerede sider, hvis du ønsker det.
6. Debounce søgning mens du skriver. Vent nogle hundrede millisekunder, efter du er holdt op med at skrive, før du forespørger, så du ikke sender en forespørgsel pr. tastetryk.
7. Tilføj indekser, når du ved, hvilke kolonner du filtrerer og søger i.
8. Opgradér til fuldtekstsøgning, derefter fuzzy matching, derefter en hostet motor — kun når det enklere trin fejler rigtige brugere.
9. Test med realistisk udseende data: hundreder eller tusinder af rækker, mærkelige tegn, tomme forespørgsler, meget lange forespørgsler, andre sprog hvis du understøtter dem.

Almindelige fejl

• At indlæse hele tabellen i browseren. Fint til 50 elementer, smertefuldt for 50.000, og det eksponerer hver post — inklusive dem brugeren ikke må se.
• Søgning der ignorerer rettigheder. Søgning er et almindeligt datalæk: en privat eller kladde-post dukker op, fordi søgeforespørgslen glemte betingelsen "kun mine" eller "kun offentliggjorte".
• At bygge SQL af rå brugerinput. Brug altid parametriserede forespørgsler. En AI-builder gør normalt det, men tjek, hvis du ser strenge der klæbes sammen.
• Ingen tom tilstand. "Ingen resultater" med et forslag (ryd filtre, tjek stavningen) forhindrer folk i at forlade siden.
• Ingen indekser. Søgning føles fin med testdata og bliver langsommere, når de rigtige data vokser.
• At springe direkte til en søgetjeneste. Så skal du holde en ekstra kopi af dine data synkroniseret, håndtere sletninger og sikre endnu et sæt nøgler — ofte uden synlig gevinst.
• At glemme mobil. Filtrene skal kunne være på en telefon; en filterskuffe eller et sammenklappeligt panel fungerer normalt bedre end en sidebar.

Tjekliste

• Du ved hvilke felter der søges i, og hvilke filtre der findes
• Søgning kører på serveren og returnerer pagineret resultater
• Forespørgslen håndhæver de samme rettigheder som resten af appen
• Brugerinput sendes som parametre, aldrig klæbet ind i SQL
• Søgetilstanden ligger i URL'en
• Indtastning er debounced
• Søgte og filtrerede kolonner er indekseret
• Tomme, ingen-resultat- og fejltilstande er tydelige
• Testet med realistiske datamængder og rodet input

Tilføj søgning med Mythex

I en app bygget på Mythex ligger data normalt i projektets egen Postgres-database, så du kan starte med prompts ovenfor: mønstermatch først, derefter Postgres fuldtekstsøgning, når du har brug for rangering. Hvis du vil have en hostet søgemaskine, skal du medbringe din egen konto og nøgle, gemme den som en projekthemmelighed og bede agenten om at indeksere og forespørge den fra serveren, som beskrevet i Integrér enhver API.

Søgning er kernen i mange apps: se sådan bygger du en katalogside, sådan bygger du et jobopslag og sådan bygger du en markedsplads for, hvordan det passer ind i resten af produktet.

Spørgsmål