अपने ऐप में Search कैसे जोड़ें: सरल फ़िल्टर से लेकर Full-Text Search तक
अपने ऐप में search जोड़ने के लिए, सबसे सरल तरीके से शुरू करें: एक search box जो सर्वर route को call करे, जो आपकी database rows को कुछ columns से query मिलान करके फ़िल्टर करे, साथ में category या price जैसी चीज़ों के फ़िल्टर। जब यह काफ़ी न हो, यानी आपको relevance ranking, word stemming या बहुत सारे records चाहिए, तो अपने database के full-text search पर जाएँ, और hosted search engine पर तभी जाएँ जब आपको मज़बूत typo tolerance या बहुत बड़े डेटा पर तुरंत नतीजे चाहिए हों। आप जो भी चुनें, search permissions का पालन करे: users को वे records कभी नहीं दिखने चाहिए जिन्हें देखने की उन्हें अनुमति नहीं है।
आपके ऐप के लिए "search" का मतलब
Search में कई अलग-अलग चीज़ें आती हैं, और ज़्यादातर ऐप्स को एक से ज़्यादा की ज़रूरत होती है:
- Keyword search: एक text box, जैसे "'garden' लिखी हुई listings ढूँढो"।
- Filters: संरचित विकल्प, जैसे category, शहर, price range, तारीख, status।
- Sorting: सबसे नया, सबसे सस्ता, सबसे relevant।
- Autocomplete: type करते समय सुझाव।
- Typo tolerance: "restuarant" लिखने पर भी "restaurant" मिल जाए।
डायरेक्टरी, जॉब बोर्ड या स्टोर के लिए, filters अक्सर text box से ज़्यादा मायने रखते हैं। किसी टूल को चुनने से पहले तय करें कि इनमें से आपको वास्तव में क्या चाहिए।
आपके विकल्प
| तरीका | यह कैसे काम करता है | किसके लिए अच्छा | सीमाएँ |
|---|---|---|---|
| Browser में फ़िल्टर | सूची लोड करें, JavaScript में फ़िल्टर करें | छोटी सार्वजनिक सूचियाँ (कुछ सौ आइटम) | सारा डेटा हर visitor को जाता है; बड़ी सूचियों पर धीमा |
| Database pattern match | सर्वर query, जैसे "name में यह टेक्स्ट है", case-insensitive | छोटे से मध्यम ऐप, admin tools | कोई ranking नहीं; बड़ी tables पर धीमा हो सकता है; stemming नहीं |
| Database full-text search | Postgres शब्दों को index करता है और matches को rank करता है | ज़्यादा content वाले ज़्यादातर ऐप्स | typos पर कमज़ोर, जब तक fuzzy matching न जोड़ें |
| Fuzzy matching (trigrams) | Postgres character sequences की समानता की तुलना करता है | नाम, छोटे fields, typo tolerance | एक extension और index चाहिए; tuning में समय लगता है |
| Hosted search engine | एक अलग सेवा आपके डेटा को index करती है (Algolia, Meilisearch, Typesense, Elasticsearch और दूसरी) | बड़े catalogs, तुरंत search, भारी typo tolerance | एक और सेवा जिसे sync रखना, भुगतान करना और सुरक्षित रखना है |
अगर आपका डेटा पहले से Postgres में है, तो उसका built-in full-text search एक मज़बूत बीच का रास्ता है। यह टेक्स्ट को शब्दों में तोड़ता है, उन्हें stems में बदलता है (ताकि "running" "run" से मिले), आम शब्दों को अनदेखा करता है, और नतीजों को मिलान की गुणवत्ता से rank कर सकता है। सही index के साथ यह बड़ी tables पर भी तेज़ रहता है।
उदाहरण prompts
एक सरल शुरुआत:
Listings page पर एक search box और filters जोड़ो। Search query को title और description से case-insensitive तरीके से मिलाए। Filters: category (dropdown), city (dropdown) और max price। Searching सर्वर पर paginated API route से करो, हर पेज पर 20 नतीजे। Search और filters URL में रखो ताकि नतीजे साझा हो सकें और back button काम करे। कुछ न मिलने पर एक अच्छा खाली-स्टेट दिखाओ।
Full-text search पर अपग्रेड करना:
Listing search को title (ज़्यादा वज़न के साथ) और description पर Postgres full-text search पर बदलो। सही index जोड़ो, नतीजों को relevance से rank करो, और मौजूदा filters और pagination रखो। कोई मौजूदा डेटा मत बदलो।
नामों के लिए typo tolerance जोड़ना:
Business name पर fuzzy matching जोड़ो ताकि छोटी typos वाली query भी नतीजे दे। अगर उपलब्ध हो तो trigram similarity का इस्तेमाल करो, index के साथ, और न हो तो मौजूदा search पर लौट जाओ।
चरण दर चरण
- लिखें कि लोग क्या खोजते हैं। कौन से fields (title, description, tags, name)? कौन से filters? अगर संभव हो तो कुछ असली users से पूछें।
- सर्वर-साइड से शुरू करें। एक API route जोड़ें जो query और filters ले और नतीजों का एक पेज लौटाए। सब कुछ browser में लोड न करें।
- Query में permissions लागू करें। अगर users सिर्फ़ अपने records या सिर्फ़ published records देख सकते हैं, तो वह शर्त उसी query में होनी चाहिए जिसमें search है।
- पहले दिन से pagination जोड़ें। पेज नंबर या "और लोड करें"।
- Search की स्थिति URL में रखें (उदाहरण के लिए
?q=garden&city=leeds)। इससे लिंक साझा हो सकते हैं, back button काम करता है, और अगर चाहें तो search engines फ़िल्टर किए गए पेज crawl कर सकते हैं। - Type करते समय search को debounce करें। Typing रुकने के बाद कुछ सौ मिलीसेकंड रुकें, ताकि हर keystroke पर request न जाए।
- Index जोड़ें, जब आप जान लें कि किन columns पर filter और search करते हैं।
- अपग्रेड करें: पहले full-text search, फिर fuzzy matching, फिर hosted engine, और तभी जब सरल कदम असली users के लिए काम न करे।
- टेस्ट करें असली जैसे डेटा से: सैकड़ों या हज़ारों rows, अजीब characters, खाली queries, बहुत लंबी queries, और अगर आप दूसरी भाषाएँ सपोर्ट करते हैं तो उनमें भी।
आम गलतियाँ
- पूरी table browser में लोड करना। 50 आइटम के लिए ठीक है, 50,000 के लिए दर्दनाक, और यह हर record उजागर कर देता है, उन्हें भी जो user को नहीं देखने चाहिए।
- Permissions को अनदेखा करने वाली search। Search एक आम leak है: कोई private या draft record दिख जाता है क्योंकि search query में "केवल मेरे" या "केवल published" वाली शर्त भूल गए।
- कच्चे user input से SQL बनाना। हमेशा parameterised queries इस्तेमाल करें। AI builder आमतौर पर ऐसा ही करता है, पर देखें कि कहीं strings जोड़कर तो नहीं बनाई जा रहीं।
- खाली-स्टेट न होना। "कोई नतीजा नहीं" के साथ सुझाव (filters साफ़ करें, spelling जाँचें) लोगों को जाने से रोकता है।
- Index न होना। टेस्ट डेटा के साथ search ठीक लगती है और असली डेटा बढ़ने पर धीमी होती जाती है।
- सीधे search सेवा पर चले जाना। तब आपको अपने डेटा की दूसरी कॉपी sync रखनी पड़ती है, deletes संभालने पड़ते हैं, और keys की एक और सेट सुरक्षित रखनी पड़ती है, अक्सर बिना किसी दिखने वाले फ़ायदे के।
- Mobile को भूल जाना। Filters फ़ोन पर फ़िट होने चाहिए; filter drawer या collapsible panel आमतौर पर sidebar से बेहतर काम करता है।
चेकलिस्ट
- आप जानते हैं कि कौन से fields खोजे जाते हैं और कौन से filters मौजूद हैं
- Search सर्वर पर चलती है और paginated नतीजे लौटाती है
- Query वही permissions लागू करती है जो ऐप के बाकी हिस्से में हैं
- User input parameters के रूप में पास होता है, कभी SQL में जोड़ा नहीं जाता
- Search की स्थिति URL में रहती है
- Typing debounced है
- Search और filter किए जाने वाले columns indexed हैं
- खाली, बिना नतीजे वाली और error स्थितियाँ साफ़ हैं
- असली डेटा मात्रा और गड़बड़ input के साथ टेस्ट किया गया
Mythex के साथ search जोड़ना
Mythex पर बने ऐप में डेटा आमतौर पर प्रोजेक्ट के अपने Postgres database में रहता है, इसलिए आप ऊपर दिए prompts से शुरू कर सकते हैं: पहले pattern matching, फिर ranking की ज़रूरत पड़ने पर Postgres full-text search। अगर आप hosted search engine चाहते हैं, तो अपना account और key ख़ुद लाएँ, उसे प्रोजेक्ट secret के रूप में सहेजें, और agent से कहें कि वह सर्वर से उसे index और query करे, जैसा Integrate any API में बताया गया है।
Search कई ऐप्स का केंद्र है: देखें डायरेक्टरी वेबसाइट कैसे बनाएँ, जॉब बोर्ड कैसे बनाएँ और मार्केटप्लेस कैसे बनाएँ, ताकि समझ आए कि यह बाकी प्रोडक्ट में कैसे फ़िट होता है।
सवाल
अपने ऐप में search जोड़ने का सबसे आसान तरीका क्या है?
अगर आपका डेटा डेटाबेस में है, तो एक सर्वर route शुरू करने का सबसे आसान तरीका है जो कुछ columns पर case-insensitive match करके rows फ़िल्टर करे। छोटी सूची के लिए, जो पहले से browser में लोड है, browser में ही फ़िल्टर करना और भी सरल है।
क्या search के लिए Algolia या Elasticsearch की ज़रूरत है?
शुरुआत में आमतौर पर नहीं। Postgres full-text search शब्दों के मिलान, ranking और हज़ारों से लाखों rows को अच्छी तरह संभालता है। hosted search engine तब काम का है जब आपको मज़बूत typo tolerance, बड़े डेटा पर type करते ही तुरंत नतीजे, या उन्नत relevance tuning चाहिए।
मेरी search typos वाले शब्दों पर नतीजे क्यों नहीं दिखाती?
सामान्य matching और standard full-text search शब्दों को वैसे ही ढूँढते हैं जैसे लिखे गए हैं (या उनके stems), इसलिए गलत spelling मिलान से चूक जाती है। आपको fuzzy matching चाहिए, जैसे Postgres में trigram similarity, या ऐसा search engine जो typos सहन करे।
Search browser में चले या सर्वर पर?
किसी छोटी सार्वजनिक सूची से बड़ी किसी भी चीज़ के लिए सर्वर पर। सर्वर-साइड search स्केल होती है, permissions का सम्मान करती है और आपका पूरा डेटासेट हर visitor को नहीं भेजती।