چطور جست‌وجو به اپ اضافه کنیم: از فیلترهای ساده تا جست‌وجوی متنی کامل
برای افزودن جست‌وجو به اپ، با ساده‌ترین چیزی که کار می‌کند شروع کنید: یک کادر جست‌وجو که یک route سروری را صدا می‌زند، آن route ردیف‌های پایگاه داده را با تطابق پرس‌وجو روی چند ستون فیلتر می‌کند، و فیلترهایی مثل دسته‌بندی یا قیمت هم دارد. وقتی این کافی نبود — به رتبه‌بندی ربط، ریشه‌یابی کلمات یا رکوردهای زیاد نیاز دارید — به جست‌وجوی متنی کامل پایگاه داده‌تان بروید، و فقط اگر به تحمل قوی غلط املایی یا نتایج لحظه‌ای روی داده بسیار بزرگ نیاز داشتید، سراغ یک موتور جست‌وجوی میزبانی‌شده بروید. هر چه انتخاب کنید، جست‌وجو باید مجوزها را رعایت کند: کاربران هرگز نباید رکوردهایی را پیدا کنند که اجازه دیدنشان را ندارند.
«جست‌وجو» برای اپ شما یعنی چه
جست‌وجو چند چیز متفاوت را شامل می‌شود و بیشتر اپ‌ها بیش از یکی از آن‌ها را لازم دارند:
- جست‌وجوی کلیدواژه: یک کادر متن — «آگهی‌هایی که «باغ» را ذکر کرده‌اند».
- فیلترها: انتخاب‌های ساختاریافته — دسته‌بندی، شهر، بازه قیمت، تاریخ، وضعیت.
- مرتب‌سازی: جدیدترین، ارزان‌ترین، مرتبط‌ترین.
- تکمیل خودکار: پیشنهادها هنگام تایپ.
- تحمل غلط املایی: «رستورانت» همچنان «رستوران» را پیدا می‌کند.
برای یک دایرکتوری، تابلوی کاریابی یا فروشگاه، فیلترها اغلب مهم‌تر از کادر متن‌اند. قبل از انتخاب ابزار، مشخص کنید کدام‌یک از این‌ها واقعاً لازم دارید.
گزینه‌های شما
| روش | نحوه کار | مناسب برای | محدودیت‌ها |
|---|---|---|---|
| فیلتر در مرورگر | فهرست را بارگذاری و با JavaScript فیلتر کنید | فهرست‌های عمومی کوچک (چند صد مورد) | همه داده‌ها را برای هر بازدیدکننده می‌فرستد؛ با فهرست‌های بزرگ کند است |
| تطابق الگو در پایگاه داده | کوئری سروری مثل «نام شامل متن است»، بدون حساسیت به حروف | اپ‌های کوچک و متوسط، ابزارهای مدیریتی | رتبه‌بندی ندارد؛ روی جدول‌های بزرگ ممکن است کند شود؛ ریشه‌یابی ندارد |
| جست‌وجوی متنی کامل پایگاه داده | Postgres کلمات را ایندکس و نتایج را رتبه‌بندی می‌کند | بیشتر اپ‌های پرمحتوا | در برابر غلط املایی ضعیف است، مگر اینکه تطابق فازی اضافه کنید |
| تطابق فازی (trigram) | Postgres شباهت رشته‌های کاراکتری را مقایسه می‌کند | نام‌ها، فیلدهای کوتاه، تحمل غلط املایی | به افزونه و ایندکس نیاز دارد؛ تنظیم آن کار می‌برد |
| موتور جست‌وجوی میزبانی‌شده | یک سرویس جدا داده‌ها را ایندکس می‌کند (Algolia، Meilisearch، Typesense، Elasticsearch و دیگران) | کاتالوگ‌های بزرگ، جست‌وجوی لحظه‌ای، تحمل غلط املایی شدید | سرویس دیگری برای همگام نگه داشتن، پرداخت و امن کردن |
اگر داده‌هایتان از قبل در Postgres است، جست‌وجوی متنی کامل آن (full-text search) یک میانه قوی است. متن را به کلمات می‌شکند، آن‌ها را به ریشه تبدیل می‌کند (پس «running» با «run» تطابق دارد)، کلمات رایج را نادیده می‌گیرد و نتایج را بر اساس میزان تطابق رتبه‌بندی می‌کند. با ایندکس درست، روی جدول‌های بزرگ هم سریع می‌ماند.
درخواست‌های نمونه
یک شروع ساده:
یک کادر جست‌وجو و فیلتر به صفحه آگهی‌ها اضافه کن. جست‌وجو باید پرس‌وجو را با عنوان و توضیحات، بدون حساسیت به حروف بزرگ و کوچک، تطبیق دهد. فیلترها: دسته‌بندی (کشویی)، شهر (کشویی) و حداکثر قیمت. جست‌وجو را روی سرور با یک route API صفحه‌بندی‌شده انجام بده، ۲۰ نتیجه در هر صفحه. جست‌وجو و فیلترها را در URL نگه دار تا نتایج قابل اشتراک باشند و دکمه برگشت کار کند. وقتی چیزی پیدا نشد، یک حالت خالی دوستانه نشان بده.
ارتقا به جست‌وجوی متنی کامل:
جست‌وجوی آگهی را به جست‌وجوی متنی کامل Postgres روی عنوان (با وزن بیشتر) و توضیحات تغییر بده. ایندکس درست اضافه کن، نتایج را بر اساس ربط رتبه‌بندی کن و فیلترها و صفحه‌بندی فعلی را نگه دار. هیچ داده موجودی را تغییر نده.
افزودن تحمل غلط املایی برای نام‌ها:
تطابق فازی روی نام کسب‌وکار اضافه کن تا غلط‌های املایی کوچک هم نتیجه بدهند. در صورت امکان از شباهت trigram با ایندکس استفاده کن و اگر در دسترس نبود، به جست‌وجوی فعلی برگرد.
مرحله به مرحله
- فهرست کنید مردم دنبال چه چیزی می‌گردند. کدام فیلدها (عنوان، توضیحات، برچسب، نام)؟ کدام فیلترها؟ اگر می‌توانید از چند کاربر واقعی بپرسید.
- از سمت سرور شروع کنید. یک route API اضافه کنید که پرس‌وجو و فیلترها را می‌گیرد و یک صفحه از نتایج را برمی‌گرداند. همه‌چیز را در مرورگر بارگذاری نکنید.
- مجوزها را در کوئری اعمال کنید. اگر کاربران فقط رکوردهای خودشان یا فقط رکوردهای منتشرشده را می‌بینند، آن شرط باید در همان کوئری جست‌وجو باشد.
- صفحه‌بندی را از روز اول اضافه کنید — شماره صفحه یا «بارگذاری بیشتر».
- وضعیت جست‌وجو را در URL نگه دارید (مثلاً
?q=garden&city=leeds). پیوندهای قابل اشتراک، دکمه برگشت کارآمد، و امکان خزیدن موتورهای جست‌وجو روی صفحات فیلترشده اگر بخواهید. - جست‌وجوی هنگام تایپ را debounce کنید. چند صد میلی‌ثانیه بعد از توقف تایپ صبر کنید تا برای هر کلید یک درخواست نفرستید.
- ایندکس‌ها را اضافه کنید وقتی دانستید روی کدام ستون‌ها فیلتر و جست‌وجو می‌کنید.
- ارتقا دهید: اول جست‌وجوی متنی کامل، بعد تطابق فازی، بعد موتور میزبانی‌شده — فقط وقتی مرحله ساده‌تر برای کاربران واقعی شکست می‌خورد.
- با داده‌های واقع‌گرایانه تست کنید: صدها یا هزاران ردیف، کاراکترهای عجیب، پرس‌وجوی خالی، پرس‌وجوی خیلی بلند، و زبان‌های دیگر اگر پشتیبانی می‌کنید.
اشتباهات رایج
- بارگذاری کل جدول در مرورگر. برای ۵۰ مورد خوب است، برای ۵۰٬۰۰۰ دردناک است، و هر رکوردی، حتی آن‌هایی که کاربر نباید ببیند، را فاش می‌کند.
- جست‌وجویی که مجوزها را نادیده می‌گیرد. جست‌وجو یک نشت رایج است: رکورد خصوصی یا پیش‌نویس نشان داده می‌شود چون کوئری شرط «فقط مال من» یا «فقط منتشرشده» را فراموش کرده.
- ساختن SQL از ورودی خام کاربر. همیشه از کوئری‌های پارامتری استفاده کنید. ساز اپ هوش مصنوعی معمولاً این کار را می‌کند، اما اگر دیدید رشته‌ها به هم چسبانده می‌شوند بررسی کنید.
- نبود حالت خالی. «نتیجه‌ای نیست» همراه با پیشنهاد (پاک کردن فیلترها، بررسی املا) جلوی ترک صفحه را می‌گیرد.
- نبود ایندکس. جست‌وجو با داده‌های تست خوب به نظر می‌رسد و با رشد داده واقعی کند می‌شود.
- پرش مستقیم به سرویس جست‌وجو. بعد باید یک کپی دوم از داده‌ها را همگام نگه دارید، حذف‌ها را مدیریت کنید و مجموعه کلیدهای دیگری را امن کنید — اغلب بدون سود قابل‌مشاهده.
- فراموش کردن موبایل. فیلترها باید در گوشی جا شوند؛ یک کشوی فیلتر یا پنل جمع‌شونده معمولاً بهتر از نوار کناری عمل می‌کند.
چک‌لیست
- می‌دانید کدام فیلدها جست‌وجو می‌شوند و کدام فیلترها وجود دارند
- جست‌وجو روی سرور اجرا می‌شود و نتایج صفحه‌بندی‌شده برمی‌گرداند
- کوئری همان مجوزهای بقیه اپ را اعمال می‌کند
- ورودی کاربر به‌صورت پارامتر فرستاده می‌شود، هرگز داخل SQL چسبانده نمی‌شود
- وضعیت جست‌وجو در URL نگه داشته می‌شود
- تایپ debounce شده است
- ستون‌های جست‌وجو و فیلتر شده ایندکس دارند
- حالت‌های خالی، بدون نتیجه و خطا واضح‌اند
- با حجم واقع‌گرایانه داده و ورودی‌های نامرتب تست شده است
افزودن جست‌وجو با Mythex
در اپی که روی Mythex ساخته می‌شود، داده‌ها معمولاً در پایگاه داده Postgres خود پروژه زندگی می‌کنند، پس می‌توانید با درخواست‌های بالا شروع کنید: اول تطابق الگو، بعد جست‌وجوی متنی کامل وقتی به رتبه‌بندی نیاز داشتید. اگر یک موتور جست‌وجوی میزبانی‌شده می‌خواهید، حساب و کلید خودتان را بیاورید، آن را به‌عنوان راز پروژه ذخیره کنید و از عامل بخواهید آن را از سمت سرور ایندکس و کوئری کند، طبق یکپارچه‌سازی هر API.
جست‌وجو هسته بسیاری از اپ‌هاست: برای دیدن اینکه چطور در بقیه محصول جا می‌گیرد، نحوه ساخت وب‌سایت دایرکتوری، نحوه ساخت تابلوی کاریابی و نحوه ساخت بازار را ببینید.
پرسش‌ها
ساده‌ترین راه افزودن جست‌وجو به یک اپ چیست؟
اگر داده‌هایتان در پایگاه داده است، یک route سروری که ردیف‌ها را با تطابق بدون حساسیت به حروف بزرگ و کوچک روی چند ستون فیلتر می‌کند، ساده‌ترین شروع است. برای فهرست کوچکی که از قبل در مرورگر بارگذاری شده، فیلتر کردن در مرورگر حتی ساده‌تر است.
آیا برای جست‌وجو به Algolia یا Elasticsearch نیاز دارم؟
معمولاً در ابتدا نه. جست‌وجوی متنی Postgres تطابق کلمات، رتبه‌بندی و هزاران تا میلیون‌ها ردیف را به‌خوبی انجام می‌دهد. یک موتور جست‌وجوی میزبانی‌شده وقتی ارزش دارد که به تحمل غلط‌املایی قوی، نتایج لحظه‌ای هنگام تایپ روی داده‌های بزرگ، یا تنظیم پیشرفته ربط نتایج نیاز داشته باشید.
چرا جست‌وجوی من با غلط املایی نتیجه پیدا نمی‌کند؟
تطابق پایه و جست‌وجوی متنی استاندارد دنبال کلمات دقیقاً همان‌طور که تایپ شده‌اند (یا ریشه‌هایشان) می‌گردند، پس غلط املایی جواب نمی‌دهد. به تطابق فازی نیاز دارید، مثل شباهت trigram در Postgres یا یک موتور جست‌وجو با تحمل غلط املایی.
جست‌وجو باید در مرورگر انجام شود یا روی سرور؟
برای هر چیزی فراتر از یک فهرست عمومی کوچک، روی سرور. جست‌وجوی سمت سرور مقیاس‌پذیر است، مجوزها را رعایت می‌کند و کل داده‌هایتان را برای هر بازدیدکننده نمی‌فرستد.