Slik legger du til søk i appen: fra enkle filtre til fulltekstsøk

For å legge til søk i appen din, start med det enkleste som fungerer: en søkeboks som kaller en serverrute. Ruten filtrerer radene i databasen din ved å matche søket mot noen få kolonner, pluss filtre for ting som kategori eller pris. Når det ikke er godt nok, for eksempel fordi du trenger rangering etter relevans, ordstamming eller mange poster, bytt til databasens fulltekstsøk. Gå bare over til en hostet søkemotor hvis du trenger sterk toleranse for skrivefeil eller øyeblikkelige resultater over veldig store datamengder. Uansett hva du velger, må søket respektere tillatelser: brukere skal aldri finne poster de ikke har lov til å se.

Hva «søk» betyr for appen din

Søk dekker flere forskjellige ting, og de fleste apper trenger mer enn ett av dem:

• Nøkkelordsøk: en tekstboks, for eksempel «finn annonser som nevner «hage»».
• Filtre: strukturerte valg, som kategori, by, prisintervall, dato eller status.
• Sortering: nyeste, billigste, mest relevante.
• Autofullføring: forslag mens du skriver.
• Toleranse for skrivefeil: «restuarant» finner fortsatt «restaurant».

For en katalog, en jobbportal eller en butikk betyr filtrene ofte mer enn tekstboksen. Bestem hva du faktisk trenger før du velger verktøy.

Alternativene dine

Hvis dataene dine allerede ligger i Postgres, er det innebygde fulltekstsøket et sterkt mellomalternativ. Det deler tekst opp i ord, reduserer dem til stammer (slik at «running» matcher «run»), ignorerer vanlige småord og kan rangere resultater etter hvor godt de passer. Med riktig indeks er det raskt også på store tabeller.

Eksempler på ledetekster

En enkel start:

Legg til en søkeboks og filtre på annonsesiden. Søket skal matche spørringen mot tittel og beskrivelse, uten å skille store og små bokstaver. Filtre: kategori (nedtrekksliste), by (nedtrekksliste) og maks pris. Gjør søket på serveren med en paginert API-rute, 20 resultater per side. Behold søket og filtrene i URL-en slik at resultatene kan deles og tilbake-knappen fungerer. Vis en vennlig tom tilstand når ingenting treffer.

Oppgradering til fulltekstsøk:

Bytt annonsesøket til fulltekstsøk i Postgres på tittel (vektet høyere) og beskrivelse. Legg til riktig indeks, rangér resultatene etter relevans, og behold de eksisterende filtrene og paginering. Ikke endre eksisterende data.

Legge til toleranse for skrivefeil i navn:

Legg til uskarp matching på bedriftsnavn slik at små skrivefeil fortsatt gir treff. Bruk trigram-likhet hvis det er tilgjengelig, med en indeks, og fall tilbake til det eksisterende søket hvis ikke.

Steg for steg

1. Lag en liste over det folk søker etter. Hvilke felt (tittel, beskrivelse, tagger, navn)? Hvilke filtre? Spør noen ekte brukere hvis du kan.
2. Start på serveren. Legg til en API-rute som tar imot søket og filtrene og returnerer én side med resultater. Ikke last alt inn i nettleseren.
3. Bruk tillatelser i spørringen. Hvis brukere bare ser sine egne poster, eller bare publiserte, hører den betingelsen hjemme i samme spørring som søket.
4. Legg til paginering fra dag én: sidenumre eller «last inn mer».
5. Legg søketilstanden i URL-en (for eksempel ?q=hage&city=leeds). Delbare lenker, fungerende tilbake-knapp og søkemotorer kan crawle filtrerte sider hvis du ønsker det.
6. Forsink søk mens du skriver. Vent noen hundre millisekunder etter at du slutter å skrive, før du spør, slik at du ikke sender en forespørsel per tastetrykk.
7. Legg til indekser når du vet hvilke kolonner du filtrerer og søker på.
8. Oppgrader til fulltekstsøk, deretter uskarp matching og til slutt en hostet motor, men bare når det enklere steget ikke holder for ekte brukere.
9. Test med realistiske data: hundrevis eller tusener av rader, rare tegn, tomme søk, veldig lange søk, andre språk hvis du støtter dem.

Vanlige feil

• Laste hele tabellen inn i nettleseren. Greit for 50 elementer, smertefullt for 50 000, og det eksponerer hver eneste post, også dem brukeren ikke skal se.
• Søk som ignorerer tillatelser. Søk er en vanlig lekkasje: en privat eller upublisert post dukker opp fordi søket glemte betingelsen «bare mine» eller «bare publiserte».
• Bygge SQL av rå brukerinput. Bruk alltid parametriserte spørringer. En KI-bygger gjør vanligvis det, men sjekk hvis du ser strenger som er limt sammen.
• Ingen tom tilstand. «Ingen resultater» med et forslag (fjern filtre, sjekk stavingen) hindrer at folk forlater siden.
• Ingen indekser. Søk føles fint med testdata og blir tregere etter hvert som ekte data vokser.
• Hoppe rett til en søketjeneste. Da må du holde en andre kopi av dataene synkronisert, håndtere slettinger og sikre enda et sett med nøkler, ofte uten synlig gevinst.
• Glemme mobil. Filtre må få plass på en telefon. En filtermeny eller et sammenleggbart panel fungerer ofte bedre enn et sidepanel.

Sjekkliste

• Du vet hvilke felt som søkes i, og hvilke filtre som finnes
• Søket kjører på serveren og returnerer paginerte resultater
• Spørringen håndhever de samme tillatelsene som resten av appen
• Brukerinput sendes som parametere, aldri limt inn i SQL
• Søketilstanden ligger i URL-en
• Skriving er forsinket (debounce)
• Søkte og filtrerte kolonner er indeksert
• Tomme tilstander, tilstander uten resultater og feiltilstander er tydelige
• Testet med realistiske datamengder og rotete input

Legge til søk med Mythex

I en app bygget på Mythex ligger dataene vanligvis i prosjektets egen Postgres-database, så du kan starte med ledetekstene over: mønstermatch først, deretter fulltekstsøk i Postgres når du trenger rangering. Hvis du vil ha en hostet søkemotor, tar du med din egen konto og nøkkel, lagrer den som en prosjekthemmelighet, og ber agenten indeksere og søke mot den fra serveren, slik det er beskrevet i Integrer ethvert API.

Søk er kjernen i mange apper. Se slik bygger du en katalogside, slik bygger du en jobbportal og slik bygger du en markedsplass for hvordan søk passer inn i resten av produktet.

Spørsmål