Paano Magdagdag ng Search sa Iyong App: Mula Simpleng Filter hanggang Full-Text Search
Para magdagdag ng search sa app, magsimula sa pinakasimpleng gumagana: isang search box na tumatawag sa server route, na nag-fi-filter ng mga row sa database mo sa pamamagitan ng pagtutugma ng query sa ilang column, kasama ang mga filter para sa mga bagay gaya ng kategorya o presyo. Kapag hindi pa sapat iyon — kailangan mo ng relevance ranking, word stemming o maraming record — lumipat sa full-text search ng database mo, at lumipat lang sa hosted na search engine kung kailangan mo ng malakas na typo tolerance o instant na resulta sa napakalaking data. Anuman ang piliin mo, dapat sumunod ang search sa permiso: hindi dapat makita ng mga user ang mga record na hindi nila pinapayagang makita.
Ano ang ibig sabihin ng "search" para sa app mo
Sakop ng search ang ilang magkakaibang bagay, at karamihan ng app ay nangangailangan ng higit sa isa:
- Keyword search: isang text box — "hanapin ang mga listing na may salitang 'garden'".
- Mga filter: mga structured na pagpili — kategorya, lungsod, saklaw ng presyo, petsa, status.
- Pag-aayos: pinakabago, pinakamura, pinakaangkop.
- Autocomplete: mga mungkahi habang nagta-type.
- Typo tolerance: nahahanap pa rin ang "restuarant" bilang "restaurant".
Para sa directory, job board o tindahan, kadalasang mas mahalaga ang mga filter kaysa sa text box. Pagpasyahan kung alin sa mga ito ang talagang kailangan mo bago pumili ng tool.
Mga opsyon mo
| Paraan | Paano ito gumagana | Angkop para sa | Mga limitasyon |
|---|---|---|---|
| Mag-filter sa browser | Ikarga ang listahan, i-filter sa JavaScript | Maliliit na pampublikong listahan (ilang daang item) | Ipinapadala ang lahat ng data sa bawat bisita; mabagal sa malalaking listahan |
| Pattern match sa database | Query sa server na tulad ng "nakalagay ang pangalan ang text", hindi case-sensitive | Maliliit hanggang katamtamang app, admin tool | Walang ranking; puwedeng bumagal sa malalaking table; walang stemming |
| Full-text search ng database | Nag-iindeks ang Postgres ng mga salita at nag-ra-rank ng mga tugma | Karamihan ng app na maraming content | Mahina sa typo maliban kung magdadagdag ka ng fuzzy matching |
| Fuzzy matching (trigrams) | Naghahambing ang Postgres ng mga pagkakasunod-sunod ng character para sa pagkakatulad | Mga pangalan, maiikling field, typo tolerance | Nangangailangan ng extension at index; may tuning |
| Hosted na search engine | Isang hiwalay na serbisyo ang nag-iindeks ng data mo (Algolia, Meilisearch, Typesense, Elasticsearch at iba pa) | Malalaking katalogo, instant na search, malakas na typo tolerance | Isa pang serbisyong dapat i-sync, bayaran at protektahan |
Kung nasa Postgres na ang data mo, malakas na gitnang opsyon ang built-in nitong full-text search. Hinahati nito ang text sa mga salita, binabawasan ang mga ito sa stem (kaya tumutugma ang "running" sa "run"), inaalis ang mga karaniwang salita, at kayang i-ranggo ang mga resulta ayon sa kung gaano sila tumutugma. Sa tamang index, nananatili itong mabilis sa malalaking table.
Mga halimbawang prompt
Isang simpleng simula:
Magdagdag ng search box at mga filter sa listings page. Dapat itugma ng search ang query sa title at description, hindi case-sensitive. Mga filter: category (dropdown), city (dropdown) at max price. Gawin ang paghahanap sa server gamit ang paginated na API route, 20 resulta kada page. Itago ang search at mga filter sa URL para maibahagi ang mga resulta at gumana ang back button. Magpakita ng magiliw na empty state kapag walang tumugma.
Pag-upgrade sa full-text search:
Ilipat ang listing search sa Postgres full-text search sa title (mas mataas ang timbang) at description. Magdagdag ng tamang index, i-ranggo ang mga resulta ayon sa relevance, at panatilihin ang kasalukuyang mga filter at pagination. Huwag baguhin ang anumang umiiral na data.
Pagdaragdag ng typo tolerance para sa mga pangalan:
Magdagdag ng fuzzy matching sa business name para mahanap pa rin ang mga resulta kahit may maliit na typo. Gamitin ang trigram similarity kung available, na may index, at bumalik sa kasalukuyang search kung hindi.
Hakbang-hakbang
- Ilista kung ano ang hinahanap ng mga tao. Aling field (title, description, tags, name)? Aling mga filter? Magtanong sa ilang totoong user kung kaya.
- Magsimula sa server. Magdagdag ng API route na tumatanggap ng query at mga filter, at nagbabalik ng isang page ng resulta. Huwag ikarga ang lahat sa browser.
- Ilapat ang permiso sa query. Kung nakikita lang ng mga user ang sarili nilang record, o ang mga na-publish lang, ang kondisyong iyon ay dapat nasa parehong query ng search.
- Magdagdag ng pagination mula pa sa simula — mga numero ng page o "load more".
- Ilagay ang estado ng search sa URL (halimbawa
?q=garden&city=leeds). Nagbibigay ito ng mga shareable na link, gumaganang back button, at nakakapag-crawl ang mga search engine ng mga naka-filter na page kung gusto mo. - I-debounce ang search-as-you-type. Maghintay ng ilang daang millisecond pagkatapos huminto ang pag-type bago mag-query, para hindi magpadala ng request kada keystroke.
- Magdagdag ng index kapag alam mo na kung aling mga column ang sinasala at hinahanap.
- Mag-upgrade sa full-text search, tapos sa fuzzy matching, tapos sa hosted na engine — kapag pumalya na ang mas simpleng hakbang sa totoong user.
- Mag-test gamit ang data na mukhang totoo: daan-daan o libu-libong row, kakaibang character, walang laman na query, napakahabang query, at ibang wika kung sinusuportahan mo ang mga ito.
Mga karaniwang pagkakamali
- Pag-load ng buong table sa browser. Ayos para sa 50 item, masakit para sa 50,000, at inilalantad nito ang bawat record — kasama ang mga hindi dapat makita ng user.
- Search na hindi pinapansin ang permiso. Karaniwang pagtagas ang search: lumilitaw ang pribado o draft na record dahil nakalimutan ng query ang kondisyong "sa akin lang" o "naka-publish lang".
- Pagbuo ng SQL mula sa raw na input ng user. Laging gumamit ng parameterised na query. Karaniwan itong ginagawa ng AI builder, pero suriin kung may nakikita kang mga string na idinidikit.
- Walang empty state. Ang "walang resulta" na may mungkahi (i-clear ang mga filter, suriin ang spelling) ang pumipigil sa tao na umalis.
- Walang index. Mukhang maayos ang search sa test data at bumabagal habang lumalaki ang totoong data.
- Diretsong pagtalon sa search service. Kailangan mo pagkatapos ng pangalawang kopya ng data na naka-sync, pangangasiwaan ang mga pagbura, at ipoprotekta ang isa pang set ng keys — madalas nang walang nakikitang pakinabang.
- Nakakalimutan ang mobile. Dapat kasya ang mga filter sa telepono; kadalasang mas mahusay ang filter drawer o collapsible na panel kaysa sidebar.
Checklist
- Alam mo kung aling mga field ang hinahanap at kung aling mga filter ang mayroon
- Tumatakbo ang search sa server at nagbabalik ng paginated na resulta
- Ipinapatupad ng query ang parehong permiso gaya ng iba pang bahagi ng app
- Ipinapasa ang input ng user bilang parameter, hindi idinidikit sa SQL
- Nasa URL ang estado ng search
- Naka-debounce ang pag-type
- May index ang mga column na hinahanap at sinasala
- Malinaw ang mga estado ng walang laman, walang resulta at error
- Nasubukan gamit ang makatotohanang dami ng data at magulong input
Pagdaragdag ng search gamit ang Mythex
Sa app na ginawa sa Mythex, kadalasang nasa Postgres database ng project ang data, kaya maaari kang magsimula sa mga prompt sa itaas: pattern matching muna, tapos Postgres full-text search kapag kailangan mo ng ranking. Kung gusto mo ng hosted na search engine, gamitin ang sarili mong account at key, itago ito bilang project secret, at ipahiling sa agent na mag-index at mag-query nito mula sa server, gaya ng nakasaad sa Integrate any API.
Ang search ang puso ng maraming app: tingnan ang paano gumawa ng directory website, paano gumawa ng job board at paano gumawa ng marketplace para makita kung paano ito nakakabit sa iba pang bahagi ng produkto.
Mga tanong
Ano ang pinakamadaling paraan para magdagdag ng search sa app?
Kung nasa database ang data mo, ang pinakamadaling simula ay server route na nagfi-filter ng mga row sa pamamagitan ng case-insensitive na paghahanap sa ilang column. Para sa maliit na listahan na nakakarga na sa browser, mas simple pa ang pag-filter sa browser.
Kailangan ko ba ng Algolia o Elasticsearch para sa search?
Karaniwang hindi sa simula. Kayang hawakan ng Postgres full-text search ang pagtutugma ng salita, pag-ranggo, at libu-libo hanggang milyon-milyong row nang maayos. Sulit ang hosted na search engine kapag kailangan mo ng malakas na typo tolerance, instant na resulta habang nagta-type sa malaking data, o advanced na pag-aayos ng relevance.
Bakit hindi nakakahanap ng resulta ang search ko kapag may typo?
Ang basic na pagtutugma at standard na full-text search ay naghahanap ng mga salita ayon sa pagkaka-type (o sa kanilang stem), kaya nagkukulang ang maling spelling. Kailangan mo ng fuzzy matching, gaya ng trigram similarity sa Postgres o search engine na may typo tolerance.
Dapat bang tumakbo ang search sa browser o sa server?
Sa server, para sa anumang lampas sa maliit na pampublikong listahan. Sumusukat ang server-side na search, iginagalang nito ang permiso, at hindi nito ipinapadala ang buong dataset mo sa bawat bisita.