قد لا تحتاج Algolia™

المواقع الثابتة ربما لا تحتاج إلى بحث مستضاف

Image by Dan Levy

معظم قرارات البحث في المواقع تُتخذ بعد فوات الأوان.

عندما يقول أحدهم “يجب أن نستخدم Algolia”، يكون الفريق عادةً قد تخطى السؤال المفيد: أي نوع من المحتوى نبحث عنه؟

إذا كانت الإجابة “صفحات HTML نبنيها بالفعل”، فإن Pagefind يجب أن يكون أول ما تجربه. ليس لأن Algolia سيئة. Algolia جيدة جدًا في مجموعة من المشكلات الصعبة. لكن إذا كان فهرس البحث يتغير عند نشر موقعك، فقد تكون خدمة البحث المستضافة مجرد تمثيل للبنية التحتية.

استخدم Pagefind عندما يتم إنشاء المحتوى القابل للبحث في وقت البناء. استخدم Algolia عندما يحتاج البحث إلى قبول كتابات حية، أو قواعد عمل، أو ترتيب خاص بالمستخدم، أو ضمانات تشغيلية لا يستطيع بناؤك الثابت توفيرها.

تغطي هذه القاعدة مواقع أكثر مما يتوقعه الناس: المدونات، التوثيق، مواقع التسويق، الكتيبات الداخلية، أدلة المنتجات، كتالوجات الدورات، وعدد مدهش من “التطبيقات” التي تنشر صفحات في الغالب.

شكل المشكلة

يمنحك Algolia نظام بحث خارجي. تنشئ سجلات، وتدفعها إلى فهرس، وتضبط الترتيب، وتوصل واجهة المستخدم، وتحافظ على مزامنة الشيء مع مصدر الحقيقة.

ينظر Pagefind إلى HTML الذي شحنته بالفعل ويبني فهرس بحث ثابتًا بجانبه.

يبدو هذا التمييز مملًا حتى تقوم بصيانة التكامل.

مع Algolia، موقعك لديه نسخة ثانية من محتواك. الآن تحتاج إلى الإجابة عن أسئلة مثل:

• هل انتهى النشر لكن فشل تحديث الفهرس؟
• أي الحقول هي الأساسية: حقول نظام إدارة المحتوى، الصفحة المقدمة، أم سجل البحث؟
• من يملك تعديلات الترتيب عندما تتوقف عن مطابقة الصفحة؟
• ماذا يحدث عندما تتبين أن الطبقة المجانية ليست الشكل الحقيقي لحركة المرور الخاصة بك؟

أحيانًا تستحق هذه الأسئلة العناء. بالنسبة لسوق، أو بوابة دعم، أو كتالوج تجارة إلكترونية كبير، فمن المحتمل أنها تستحق. بالنسبة لموقع توثيق ثابت، فهي غالبًا تعقيد مفتعل.

يعمل Pagefind لأنه يرفض النظام الإضافي

حيلة Pagefind ليست سحرًا. إنها ذوق.

ينتظر حتى توجد صفحاتك، ويفهرس HTML النهائي، ويكتب مجموعة من الأصول الثابتة التي يمكنك وضعها على نفس CDN مثل باقي موقعك. يقوم المتصفح بتنزيل الأجزاء التي يحتاجها فقط. لا يوجد خادم بحث للحفاظ على دفئه، ولا حصة زاحف لمراقبتها، ولا خط أنابيب webhook يحاول تذكر ما تغير.

هذا يجعل نمط الفشل أسهل بكثير في الفهم:

• إذا تم نشر الصفحة، فإن المحتوى المفهرس جاء من تلك الصفحة.
• إذا لم يتم نشر الصفحة، لا يمكن للمستخدمين رؤيتها على أي حال.
• إذا كان البحث خاطئًا، فالمشكلة عادة في ترميزك المقدم أو تكوين Pagefind، وليس في وظيفة مزامنة بعيدة.

لهذا أحبه لمواقع المحتوى. يتبع الفهرس الأثر.

كيف يبدو الإعداد الفعلي

بالنسبة لموقع ثابت بسيط، سير العمل ممل بشكل لطيف:

• CLI: امسح ملفات HTML لموقعك، أنشئ فهرسًا، وانشره على شبكة توصيل محتوى عالمية (CDN)—كل ذلك في دقائق.
• مولدات المواقع الثابتة: استخدم إضافات PageFind الخاصة بـ Astro أو Hugo لأتمتة عملية الفهرسة.
• الحلول المخصصة: استخدم واجهة برمجة تطبيقات PageFind لبناء تجارب بحث مخصصة تناسب متطلباتك الفريدة.

دليل البدء كافٍ للانطلاق. الاختبار الأفضل هو العملياتي: هل يمكنك إعادة بناء الفهرس في CI، ونشر المخرجات، وتفسير كل خطأ بحث من خلال فحص HTML المُقدَّم؟

أين لا يزال Algolia متفوقًا

Pagefind ليس نسخة مصغرة من Algolia مختبئة في معطف طويل. إنه إجابة مختلفة.

استخدم Algolia، أو OpenSearch، أو بحث Postgres، أو أي نظام حي آخر عندما يحتاج فهرس البحث الخاص بك إلى التغيير بشكل مستقل عن نشر الموقع.

يشمل ذلك:

• أعداد المخزون التي تتغير كل بضع دقائق
• أذونات لكل مستخدم أو نتائج خاصة
• ترتيب مخصص يعتمد على الإيرادات، أو الحداثة، أو الشعبية، أو التجارب
• بحث موحد عبر أنظمة لا تُعرض في موقع ثابت واحد
• دعم تحليلات وعمليات تتوقعها الشركة من مزود مُدار

تلك احتياجات حقيقية. التظاهر بأن Pagefind يعالجها لأنه سريع سيكون النوع الآخر من صوت المدونات الترويجية.

القرار الذي أستخدمه

اسأل سؤالًا واحدًا أولًا:

هل يمكن إعادة بناء فهرس البحث من نفس المخرجات الثابتة التي يتصفحها المستخدمون؟

إذا كانت الإجابة بنعم، ابدأ بـ Pagefind. ستحصل على بحث خاص افتراضيًا، وأصولًا صديقة لشبكات توصيل المحتوى (CDN)، وحساب خدمة واحدًا أقل مع آرائه.

إذا كانت الإجابة بلا، سمِّ الشيء الذي يجعل الفهرس حيًا: المخزون، الأذونات، التخصيص، التحليلات، الترتيب، أو تكرار الكتابة. ثم اختر قاعدة البيانات أو خدمة البحث التي تمتلك تلك المهمة صراحة.

Algolia ليس الشرير هنا. الشرير هو اعتماد نظام ثانٍ قبل إثبات أن الأداة الأولى لم تكن كافية.