तुमच्या अ‍ॅपमध्ये शोध कसा जोडावा: साध्या फिल्टर्सपासून पूर्ण-मजकूर शोधापर्यंत
तुमच्या अ‍ॅपमध्ये शोध जोडण्यासाठी, सर्वात सोप्या कामाने सुरुवात करा: एक शोध बॉक्स जो सर्व्हर route कॉल करतो, जो काही कॉलम्सशी क्वेरी जुळवून तुमच्या डेटाबेस ओळी फिल्टर करतो, श्रेणी किंवा किंमतीसारख्या गोष्टींसाठी फिल्टर्स सोबत. ते पुरेसे नसेल — relevance क्रमवारी, शब्द stemming किंवा खूप रेकॉर्ड्स हवे असतील — तर तुमच्या डेटाबेसचा full-text search वापरा, आणि मजबूत typo सहनशीलता किंवा खूप मोठ्या डेटावर त्वरित निकालांसाठीच होस्ट केलेल्या search engine कडे जा. तुम्ही काहीही निवडले तरी, शोधाने परवानग्या पाळल्या पाहिजेत: वापरकर्त्यांना त्यांना पाहण्याची परवानगी नसलेले रेकॉर्ड कधीही सापडू नयेत.
तुमच्या अ‍ॅपसाठी "शोध" म्हणजे काय
शोधात काही वेगवेगळ्या गोष्टी येतात, आणि बहुतेक अ‍ॅप्सना एकापेक्षा जास्त हवे असतात:
- कीवर्ड शोध: एक मजकूर बॉक्स — "'garden' उल्लेख असलेल्या सूची शोधा".
- फिल्टर्स: संरचित निवडी — श्रेणी, शहर, किंमत मर्यादा, तारीख, स्थिती.
- क्रमवारी: नवीनतम, सर्वात स्वस्त, सर्वात संबंधित.
- Autocomplete: टाइप करताना सूचना.
- Typo सहनशीलता: "restuarant" ला तरीही "restaurant" सापडते.
डिरेक्टरी, जॉब बोर्ड किंवा दुकानासाठी फिल्टर्स अनेकदा मजकूर बॉक्सपेक्षा जास्त महत्त्वाचे असतात. साधन निवडण्यापूर्वी कोणते खरोखर हवे ते ठरवा.
तुमचे पर्याय
| दृष्टिकोन | ते कसे काम करते | यासाठी चांगले | मर्यादा |
|---|---|---|---|
| ब्राउझरमध्ये फिल्टर | यादी लोड करा, JavaScript मध्ये फिल्टर करा | लहान सार्वजनिक यादी (काही शे आयटम) | प्रत्येक अभ्यागताला सर्व डेटा पाठवतो; मोठ्या यादीत मंद |
| डेटाबेस पॅटर्न जुळवणी | सर्व्हर क्वेरी जसे "नावात मजकूर आहे", केस-इन्सेन्सिटिव्ह | लहान ते मध्यम अ‍ॅप्स, अ‍ॅडमिन टूल्स | क्रमवारी नाही; मोठ्या टेबलवर मंद होऊ शकते; stemming नाही |
| डेटाबेस full-text search | Postgres शब्द इंडेक्स करते आणि जुळणी क्रमवारी लावते | बहुतेक कंटेंट-जड अ‍ॅप्स | fuzzy matching जोडल्याशिवाय typos ला कमकुवत |
| Fuzzy matching (trigrams) | Postgres वर्णांच्या अनुक्रमांची समानता तुलना करते | नावे, लहान फील्ड्स, typo सहनशीलता | extension आणि इंडेक्स लागतो; ट्यूनिंगला वेळ लागतो |
| होस्ट केलेले search engine | वेगळी सेवा तुमचा डेटा इंडेक्स करते (Algolia, Meilisearch, Typesense, Elasticsearch आणि इतर) | मोठे कॅटलॉग, त्वरित शोध, जास्त typo सहनशीलता | आणखी एक सेवा समक्रमित ठेवायची, पैसे द्यायचे आणि सुरक्षित करायची |
तुमचा डेटा आधीच Postgres मध्ये असेल, तर त्याचा अंगभूत full-text search एक मजबूत मध्यम मार्ग आहे. तो मजकूर शब्दांमध्ये तोडतो, त्यांना stems मध्ये आणतो (त्यामुळे "running" "run" शी जुळते), सामान्य शब्द वगळतो, आणि जुळणी किती चांगली आहे त्यानुसार निकालांची क्रमवारी लावू शकतो. योग्य इंडेक्ससह तो मोठ्या टेबलवरही वेगवान राहतो.
उदाहरण प्रॉम्प्ट्स
सोपी सुरुवात:
सूची पानावर शोध बॉक्स आणि फिल्टर्स जोडा. क्वेरी शीर्षक आणि वर्णनाशी केस-इन्सेन्सिटिव्ह पद्धतीने जुळवा. फिल्टर्स: श्रेणी (ड्रॉपडाउन), शहर (ड्रॉपडाउन) आणि कमाल किंमत. शोध सर्व्हरवर पेजिनेटेड API route द्वारे करा, प्रति पान 20 निकाल. शोध आणि फिल्टर्स URL मध्ये ठेवा, जेणेकरून निकाल शेअर करता येतील आणि back बटण काम करेल. काहीही जुळले नाही तर मैत्रीपूर्ण रिकामी स्थिती दाखवा.
Full-text search वर अपग्रेड:
सूची शोध Postgres full-text search वर शीर्षक (जास्त वजनाने) आणि वर्णनावर हलवा. योग्य इंडेक्स जोडा, निकालांची relevance नुसार क्रमवारी लावा, आणि विद्यमान फिल्टर्स व पेजिनेशन ठेवा. कोणताही विद्यमान डेटा बदलू नका.
नावांसाठी typo सहनशीलता:
व्यवसायाच्या नावावर fuzzy matching जोडा, जेणेकरून छोटे typos तरीही निकाल शोधतील. उपलब्ध असल्यास trigram similarity वापरा, इंडेक्ससह, आणि नसल्यास सध्याच्या शोधावर परत जा.
टप्प्याटप्प्याने
- लोक काय शोधतात ते यादी करा. कोणते फील्ड्स (शीर्षक, वर्णन, टॅग्ज, नाव)? कोणते फिल्टर्स? शक्य असल्यास काही खऱ्या वापरकर्त्यांना विचारा.
- सर्व्हरवर सुरुवात करा. एक API route जोडा जो क्वेरी आणि फिल्टर्स घेतो, आणि एक पान निकाल परत करतो. सर्व काही ब्राउझरमध्ये लोड करू नका.
- क्वेरीमध्ये परवानग्या लागू करा. वापरकर्ते फक्त त्यांचे रेकॉर्ड्स, किंवा फक्त प्रकाशित रेकॉर्ड्स पाहू शकतात, तर ती अट शोधाच्या त्याच क्वेरीत असायला हवी.
- पहिल्या दिवसापासून पेजिनेशन जोडा — पान क्रमांक किंवा "अधिक लोड करा".
- शोध स्थिती URL मध्ये ठेवा (उदाहरणार्थ
?q=garden&city=leeds). शेअर करता येणाऱ्या लिंक्स, काम करणारे back बटण, आणि तुम्हाला हवे असल्यास search engines फिल्टर केलेली पाने क्रॉल करू शकतात. - टाइप करत असताना शोध debounce करा. क्वेरी पाठवण्यापूर्वी टायपिंग थांबल्यानंतर काही शंभर मिलिसेकंद थांबा, जेणेकरून प्रत्येक कीस्ट्रोकसाठी विनंती जाणार नाही.
- इंडेक्स जोडा, एकदा कोणत्या कॉलम्सवर फिल्टर आणि शोध होतो हे कळले की.
- अपग्रेड करा full-text search, मग fuzzy matching, मग होस्ट केलेले engine — फक्त जेव्हा सोपी पायरी खऱ्या वापरकर्त्यांसाठी अपयशी ठरते तेव्हा.
- वास्तविक दिसणाऱ्या डेटाने चाचणी करा: शेकडो किंवा हजारो ओळी, विचित्र वर्ण, रिकाम्या क्वेरी, खूप लांब क्वेरी, आणि तुम्ही समर्थन करत असल्यास इतर भाषा.
सामान्य चुका
- संपूर्ण टेबल ब्राउझरमध्ये लोड करणे. 50 आयटमसाठी ठीक, 50,000 साठी त्रासदायक, आणि त्यामुळे प्रत्येक रेकॉर्ड उघड होतो — ज्यात वापरकर्त्याने पाहू नयेत असे रेकॉर्ड्सही.
- परवानग्या दुर्लक्षित करणारा शोध. शोध हा सामान्य गळतीचा मार्ग आहे: क्वेरीत "फक्त माझे" किंवा "फक्त प्रकाशित" अट विसरल्याने खाजगी किंवा मसुदा रेकॉर्ड दिसते.
- कच्च्या वापरकर्ता इनपुटवरून SQL तयार करणे. नेहमी parameterised queries वापरा. AI बिल्डर सहसा असे करतो, पण स्ट्रिंग्स जोडल्या जात असल्याचे दिसल्यास तपासा.
- रिकामी स्थिती नसणे. सूचनेसह "निकाल नाहीत" (फिल्टर्स साफ करा, स्पेलिंग तपासा) लोकांना निघून जाण्यापासून रोखते.
- इंडेक्स नसणे. चाचणी डेटासह शोध ठीक वाटतो आणि खरा डेटा वाढल्यावर मंद होतो.
- थेट शोध सेवेकडे उडी. मग तुमच्याकडे डेटाची दुसरी प्रत समक्रमित ठेवणे, हटवणे हाताळणे आणि आणखी एक keys संच सुरक्षित करणे आले — अनेकदा कोणताही दृश्य फायदा नसताना.
- मोबाइलचा विचार न करणे. फिल्टर्स फोनवर बसले पाहिजेत; फिल्टर ड्रॉवर किंवा दुमडता येणारे पॅनल सहसा साइडबारपेक्षा चांगले काम करते.
चेकलिस्ट
- कोणते फील्ड्स शोधले जातात आणि कोणते फिल्टर्स आहेत हे माहीत आहे
- शोध सर्व्हरवर चालतो आणि पेजिनेटेड निकाल परत करतो
- क्वेरी अ‍ॅपच्या उर्वरित भागासारख्याच परवानग्या लागू करते
- वापरकर्ता इनपुट parameters म्हणून पाठवला जातो, कधीही SQL मध्ये जोडला जात नाही
- शोध स्थिती URL मध्ये राहते
- टायपिंग debounce केलेले आहे
- शोधलेले आणि फिल्टर केलेले कॉलम्स इंडेक्स केलेले आहेत
- रिकाम्या, निकाल-नसलेल्या आणि त्रुटी स्थिती स्पष्ट आहेत
- वास्तविक डेटा प्रमाणात आणि गोंधळलेल्या इनपुटसह चाचणी केली
Mythex सह शोध जोडणे
Mythex वर बांधलेल्या अ‍ॅपमध्ये डेटा सहसा प्रोजेक्टच्या स्वतःच्या Postgres डेटाबेस मध्ये असतो, त्यामुळे वरील प्रॉम्प्ट्सने सुरुवात करता येते: आधी पॅटर्न जुळवणी, मग रेलेव्हन्सीची गरज असेल तेव्हा Postgres full-text search. होस्ट केलेले search engine हवे असल्यास, तुमचे स्वतःचे खाते आणि key आणा, ती प्रोजेक्ट secret म्हणून साठवा, आणि Integrate any API मध्ये वर्णन केल्याप्रमाणे सर्व्हरवरून इंडेक्स आणि क्वेरी करण्यासाठी एजंटला सांगा.
अनेक अ‍ॅप्सचा गाभा शोध असतो: उर्वरित उत्पादनात तो कसा बसतो ते पाहण्यासाठी डिरेक्टरी वेबसाइट कशी बनवावी, जॉब बोर्ड कसा बनवावा आणि मार्केटप्लेस कसा बनवावा पहा.
प्रश्न
अ‍ॅपमध्ये शोध जोडण्याचा सर्वात सोपा मार्ग कोणता?
तुमचा डेटा डेटाबेसमध्ये असेल तर, काही कॉलम्सवर केस-इन्सेन्सिटिव्ह जुळवणी करून ओळी फिल्टर करणारा सर्व्हर route हा सुरुवातीसाठी सर्वात सोपा आहे. ब्राउझरमध्ये आधीच लोड केलेल्या लहान यादीसाठी ब्राउझरमध्येच फिल्टर करणे त्याहूनही सोपे आहे.
शोधासाठी मला Algolia किंवा Elasticsearch लागते का?
सुरुवातीला सहसा नाही. Postgres full-text search शब्द जुळवणी, क्रमवारी आणि हजारो ते लाखो ओळी उत्तम हाताळते. होस्ट केलेले search engine तेव्हा फायदेशीर ठरते जेव्हा तुम्हाला मजबूत typo सहनशीलता, मोठ्या डेटावर टाइप करताना त्वरित निकाल, किंवा प्रगत relevance ट्यूनिंग हवे असते.
माझ्या शोधाला typo असलेले निकाल का सापडत नाहीत?
मूलभूत जुळवणी आणि मानक full-text search शब्द जसे टाइप केले जातात तसे (किंवा त्यांचे stems) शोधते, त्यामुळे चुकीचे स्पेलिंग जुळत नाही. तुम्हाला fuzzy matching हवे, जसे Postgres मधील trigram similarity किंवा typo सहनशीलता असलेले search engine.
शोध ब्राउझरमध्ये चालावा की सर्व्हरवर?
छोट्या सार्वजनिक यादीपेक्षा मोठ्यासाठी सर्व्हरवर. सर्व्हर-साइड शोध स्केल होतो, परवानग्या पाळतो आणि प्रत्येक अभ्यागताला तुमचा संपूर्ण डेटासेट पाठवत नाही.