Zoeken toevoegen aan je app: van eenvoudige filters tot full-text search
Om zoeken aan je app toe te voegen, begin je met het eenvoudigste dat werkt: een zoekvak dat een serverroute aanroept, die je databaserijen filtert door de zoekterm op een paar kolommen te matchen, plus filters voor zaken als categorie of prijs. Als dat niet genoeg is, omdat je relevantie-rangschikking, woordstammen of veel records nodig hebt, schakel je over op full-text search van je database. Alleen als je sterke tolerantie voor typefouten of directe resultaten over zeer grote hoeveelheden data nodig hebt, ga je naar een gehoste zoekmachine. Wat je ook kiest: zoeken moet rechten respecteren. Gebruikers mogen nooit records vinden die ze niet mogen zien.
Wat "zoeken" betekent voor je app
Zoeken omvat een paar verschillende dingen, en de meeste apps hebben er meer dan één nodig:
- Zoeken op trefwoord: een tekstvak, bijvoorbeeld "vermeldingen met 'tuin'".
- Filters: gestructureerde keuzes zoals categorie, stad, prijsklasse, datum of status.
- Sorteren: nieuwste, goedkoopste, meest relevant.
- Autocomplete: suggesties terwijl je typt.
- Tolerantie voor typefouten: "restarant" vindt nog steeds "restaurant".
Voor een directory, vacaturesite of winkel zijn filters vaak belangrijker dan het tekstvak. Bepaal welke van deze je echt nodig hebt voordat je een tool kiest.
Je opties
| Aanpak | Hoe het werkt | Geschikt voor | Beperkingen |
|---|---|---|---|
| Filteren in de browser | De lijst laden en in JavaScript filteren | Kleine publieke lijsten (enkele honderden items) | Stuurt alle data naar elke bezoeker; traag bij grote lijsten |
| Patroonmatching in de database | Serverquery zoals "naam bevat de tekst", hoofdletterongevoelig | Kleine tot middelgrote apps, admintools | Geen rangschikking; kan traag worden bij grote tabellen; geen stemming |
| Full-text search in de database | Postgres indexeert woorden en rangschikt matches | De meeste apps met veel content | Zwak bij typefouten, tenzij je fuzzy matching toevoegt |
| Fuzzy matching (trigrammen) | Postgres vergelijkt tekenreeksen op gelijkenis | Namen, korte velden, tolerantie voor typefouten | Vraagt om een extensie en index; afstemmen kost tijd |
| Gehoste zoekmachine | Een aparte dienst indexeert je data (Algolia, Meilisearch, Typesense, Elasticsearch en andere) | Grote catalogi, direct zoeken, veel tolerantie voor typefouten | Nog een dienst om synchroon te houden, te betalen en te beveiligen |
Als je data al in Postgres staat, is de ingebouwde full-text search een sterk tussenweg. Die splitst tekst in woorden, herleidt ze tot stammen (zodat "lopen" bij "loop" hoort), negeert veelvoorkomende woorden, en kan resultaten rangschikken op hoe goed ze passen. Met de juiste index blijft het snel op grote tabellen.
Voorbeeldprompts
Een eenvoudige start:
Voeg een zoekvak en filters toe aan de advertentiepagina. Zoeken moet de zoekterm matchen op titel en beschrijving, hoofdletterongevoelig. Filters: categorie (dropdown), stad (dropdown) en maximale prijs. Doe het zoeken op de server met een gepagineerde API-route, 20 resultaten per pagina. Houd zoekterm en filters in de URL zodat resultaten gedeeld kunnen worden en de terugknop werkt. Toon een vriendelijke lege staat als niets matcht.
Overstappen naar full-text search:
Zet de zoekfunctie voor advertenties om naar Postgres full-text search op titel (zwaarder gewogen) en beschrijving. Voeg de juiste index toe, rangschik resultaten op relevantie, en behoud de bestaande filters en paginering. Verander geen bestaande data.
Tolerantie voor typefouten bij namen toevoegen:
Voeg fuzzy matching toe op de bedrijfsnaam, zodat kleine typefouten nog resultaten opleveren. Gebruik trigram-gelijkenis als die beschikbaar is, met een index, en val terug op de huidige zoekfunctie als dat niet kan.
Stap voor stap
- Maak een lijst van wat mensen zoeken. Welke velden (titel, beschrijving, tags, naam)? Welke filters? Vraag, als het kan, een paar echte gebruikers.
- Begin op de server. Voeg een API-route toe die de zoekterm en filters neemt, en één pagina resultaten teruggeeft. Laad niet alles in de browser.
- Pas rechten toe in de query. Als gebruikers alleen hun eigen records of alleen gepubliceerde records zien, hoort die voorwaarde in dezelfde query als de zoekopdracht.
- Voeg paginering toe vanaf de eerste dag: paginanummers of "meer laden".
- Zet de zoekstatus in de URL (bijvoorbeeld
?q=tuin&city=leeds). Dan zijn links deelbaar, werkt de terugknop, en kunnen zoekmachines gefilterde pagina's crawlen als je dat wilt. - Vertraag zoeken terwijl je typt (debounce). Wacht een paar honderd milliseconden nadat je stopt met typen voordat je zoekt, zodat je niet bij elke toetsaanslag een verzoek stuurt.
- Voeg indexen toe zodra je weet op welke kolommen je filtert en zoekt.
- Upgrade naar full-text search, dan fuzzy matching, dan een gehoste zoekmachine, maar alleen als de eenvoudigere stap echte gebruikers niet genoeg helpt.
- Test met realistische data: honderden of duizenden rijen, rare tekens, lege zoektermen, zeer lange zoektermen, andere talen als je die ondersteunt.
Veelgemaakte fouten
- De hele tabel in de browser laden. Prima bij 50 items, pijnlijk bij 50.000, en het toont elk record, ook de records die de gebruiker niet mag zien.
- Zoeken dat rechten negeert. Zoeken is een veelvoorkomend lek: een privé- of conceptrecord duikt op omdat de zoekquery de voorwaarde "alleen van mij" of "alleen gepubliceerd" vergat.
- SQL bouwen met ruwe gebruikersinvoer. Gebruik altijd geparametriseerde queries. Een AI-builder doet dat meestal, maar controleer of er strings aan elkaar worden geplakt.
- Geen lege staat. "Geen resultaten" met een suggestie (filters wissen, spelling controleren) houdt mensen tegen om weg te gaan.
- Geen indexen. Zoeken voelt prima met testdata en wordt trager naarmate de echte data groeit.
- Meteen naar een zoekdienst springen. Dan moet je een tweede kopie van je data synchroon houden, verwijderingen afhandelen en nog een set sleutels beveiligen, vaak zonder zichtbaar voordeel.
- Mobiel vergeten. Filters moeten op een telefoon passen; een filterlade of inklapbaar paneel werkt meestal beter dan een zijbalk.
Checklist
- Je weet welke velden doorzocht worden en welke filters er zijn
- Zoeken draait op de server en geeft gepagineerde resultaten terug
- De query past dezelfde rechten toe als de rest van de app
- Gebruikersinvoer wordt als parameter doorgegeven, nooit in SQL geplakt
- Zoekstatus staat in de URL
- Typen wordt vertraagd (debounce)
- Doorzochte en gefilterde kolommen zijn geïndexeerd
- Lege, geen-resultaten- en foutstatussen zijn duidelijk
- Getest met realistische datavolumes en rommelige invoer
Zoeken toevoegen met Mythex
In een app die op Mythex is gebouwd staat de data meestal in de Postgres-database van het project. Je kunt dus starten met de prompts hierboven: eerst patroonmatching, en full-text search van Postgres zodra je rangschikking nodig hebt. Als je een gehoste zoekmachine wilt, neem je je eigen account en sleutel mee, sla je die op als projectgeheim, en vraag je de agent om te indexeren en op de server te zoeken, zoals beschreven in Integreer elke API.
Zoeken is de kern van veel apps. Zie hoe bouw je een directorywebsite, hoe bouw je een vacaturesite en hoe bouw je een marktplaats om te zien hoe zoeken in het geheel van het product past.
Veelgestelde vragen
Wat is de makkelijkste manier om zoeken aan een app toe te voegen?
Als je data in een database staat, is een serverroute die rijen filtert met een hoofdletterongevoelige match op een paar kolommen de makkelijkste start. Voor een kleine lijst die al in de browser is geladen, is filteren in de browser nog eenvoudiger.
Heb ik Algolia of Elasticsearch nodig voor zoeken?
Meestal niet in het begin. Postgres full-text search verwerkt woordmatching, rangschikking en duizenden tot miljoenen rijen goed. Een gehoste zoekmachine is de moeite waard als je sterke tolerantie voor typefouten nodig hebt, resultaten die direct verschijnen terwijl je typt bij grote hoeveelheden data, of geavanceerde relevantie-afstemming.
Waarom vindt mijn zoekfunctie geen resultaten bij typefouten?
Basale matching en standaard full-text search zoeken naar de woorden zoals ze zijn getypt (of hun stam), dus een spelfout mist. Je hebt fuzzy matching nodig, zoals trigram-gelijkenis in Postgres of een zoekmachine met tolerantie voor typefouten.
Moet zoeken in de browser of op de server draaien?
Op de server voor alles wat groter is dan een kleine publieke lijst. Zoeken op de server schaalt, respecteert rechten en stuurt niet je hele dataset naar elke bezoeker.