أفضل مجموعة تقنيات لمواقع الدلائل والأسواق في 2026

معظم مقالات "أفضل مجموعة تقنيات" تبدو وكأن شخصاً تصفح Product Hunt ليوم واحد وكتب ما وجده. سيخبرونك باستخدام React وربما Postgres، يرمون Stripe، ويعتبرونها انتهت. هذا ليس مفيداً عندما تحاول بناء موقع دليل به 137,000 صفحة قائمة تحتاج إلى التصيير بسرعة، وتدعم البحث الجغرافي في نطاق 50 ميلاً، وتسمح للمستخدمين بالعثور على النتائج باستخدام الاستعلامات باللغة الطبيعية.

لقد أمضيت السنتين الماضيتين ببناء هذه الأنواع من المواقع بالضبط. ليست مشاريع لعبة -- منصات دليل وسوق إنتاجية تتعامل مع مئات الآلاف من السجلات، معالجة الدفع متعددة الدول (بما في ذلك حالات الحافة الممتعة مثل العملات بدون فاصلة عشرية)، وأنظمة البحث التي تجمع بين البحث النصي الكامل والذكاء الاصطناعي الدلالي والاستعلامات الجغرافية في نفس الوقت. تشرح هذه المقالة كل طبقة من الحزمة التي نستخدمها في Social Animal، ولماذا اخترنا كل جزء، والبيانات الإنتاجية التي تدعم هذه القرارات.

جدول المحتويات

أفضل مجموعة تقنيات لمواقع الدليل والسوق في 2026

لماذا مواقع الدليل والسوق معمارياً فريدة

مواقع الدليل والسوق تبدو بسيطة على السطح. اسرد بعض الأشياء، دع الناس يبحثون، ربما معالجة الدفع. لكن في اللحظة التي تبدأ فيها بناء واحد مع بيانات حقيقية، تواجه مشاكل لم تعدك لها معمارية SaaS القياسية.

أولاً، هناك مشكلة عدد الصفحات. دليل يحتوي على 100K+ قوائم يحتاج 100K+ صفحة. لا يمكنك تصيير الخادم لجميعهم في كل طلب، ولا يمكنك توليد جميعهم بشكل ثابت في وقت البناء (ستستغرق بناءاتك ساعات). تحتاج إلى شيء أذكى -- Incremental Static Regeneration (ISR) أو إعادة التحقق حسب الطلب.

ثانياً، البحث متعدد الأبعاد. يريد المستخدمون البحث حسب النص ("معالج أسري")، حسب المعنى ("شخص يساعد في قلق العلاقات")، وحسب الموقع ("في غضون 20 ميلاً من أوستن"). معظم الحزم تتعامل مع واحد من هذه. التعامل مع جميعها في نفس الوقت يتطلب معمارية قاعدة بيانات محددة.

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

شكلت هذه القيود كل قرار في حزمتنا. دعنا نمر بكل طبقة.

نظرة عامة على حزمة الطبقات 10

قبل أن نتعمق، إليك الصورة الكاملة:

الطبقة الأداة السبب
الواجهة الأمامية Next.js 15 (App Router) ISR لـ 100K+ صفحة، Server Components
قاعدة البيانات Supabase PostgreSQL pgvector + PostGIS + full-text في قاعدة بيانات واحدة
المصادقة Supabase Auth Row-Level Security، الوصول المبني على الأدوار
الدفع Stripe Connect عمولات السوق، متعدد العملات
البحث نمط ثلاثي (tsvector + pgvector + PostGIS) نص + دلالي + جغرافي في نفس الوقت
الوسائط Supabase Storage + Next.js Image التسليم المُحسَّن، التحميلات البسيطة
الاستضافة Vercel نشر الحافة، دعم ISR، عناوين URL المعاينة
البريد الإلكتروني Brevo API معاملات + التسويق من مسارات API
الذكاء الاصطناعي Claude API البحث الدلالي، إثراء المحتوى، الدردشات
المراقبة Vercel Analytics + PostHog تتبع حركة المرور + سلوك المستخدم

كل طبقة هنا تعمل في الإنتاج عبر مشاريع متعددة. دعني أريك كيف يبدو هذا فعلياً.

الطبقة 1: الواجهة الأمامية -- Next.js 15

لقد بنينا مواقع الدليل مع كل Next.js وAstro. كلاهما ممتاز. لكن بالنسبة للدلائل والأسواق على وجه التحديد، فإن Next.js 15 مع App Router يفوز بسبب ميزة واحدة: Incremental Static Regeneration.

إليك السيناريو الحقيقي. يقدم أحد مشاريع الدليل الخاصة بنا 137,000 صفحة قائمة. آخر يتعامل مع 91,000. لا يمكنك توليد جميع هذه بشكل ثابت في وقت البناء -- سيستغرق البناء الوقت والوقت وستتجاوز حدود تنفيذ وظيفة Vercel. ولا يمكنك تصيير الخادم لجميعهم في كل طلب لأن تكاليف الخادم الخاصة بك ستكون سخيفة وسيعاني Time to First Byte الخاص بك.

يعطيك ISR أفضل ما في الحالتين. يؤدي الزائر الأول للصفحة إلى تصيير على الخادم، والذي يتم تخزينه في الحافة. يحصل الزوار اللاحقون على النسخة الثابتة. تقوم بتعيين فاصل إعادة التحقق (نستخدم عادة 3600 ثانية لصفحات القائمة)، وتتحدث الذاكرة المؤقتة في الخلفية.

// app/listings/[slug]/page.tsx
export const revalidate = 3600; // إعادة التحقق كل ساعة

export async function generateStaticParams() {
  // قم بإنشاء أفضل 1000 قائمة الأكثر زيارة فقط
  const { data } = await supabase
    .from('listings')
    .select('slug')
    .order('view_count', { ascending: false })
    .limit(1000);
  
  return data?.map((listing) => ({ slug: listing.slug })) ?? [];
}

export default async function ListingPage({ params }: { params: { slug: string } }) {
  const { data: listing } = await supabase
    .from('listings')
    .select('*, categories(*), reviews(*)')
    .eq('slug', params.slug)
    .single();
    
  // Server Component -- لا يتم شحن أي عميل-جانب JS لهذا
  return <ListingDetail listing={listing} />;
}

Server Components هي الفوز الكبير الآخر. صفحات تفاصيل القائمة معظمها محتوى ثابت -- الاسم والوصف والصور والتقييمات. لا توجد أسباب لشحن وقت تشغيل React للعميل لذلك. يقدم Server Components على الخادم وإرسال HTML نقي. صفحات القائمة الخاصة بك تحمل بسرعة وحزمة JavaScript الخاصة بك تبقى صغيرة.

نستخدم Client Components بشكل نادر: شريط البحث، الخرائط التفاعلية، نماذج الحجز، وأي شيء يحتاج إلى تفاعل المستخدم. كل شيء آخر يبقى على الخادم.

لماذا لا Astro?

Astro رائعة للدلائل الثقيلة بالمحتوى حيث التفاعل ضئيل. لقد استخدمناها لمواقع التوثيق والمشاريع التي تركز على المحتوى. لكن مواقع السوق تحتاج إلى حالات مصرح بها، ميزات في الوقت الفعلي، ونماذج معقدة. Next.js يتعامل مع هذه بشكل أكثر طبيعية. إذا كان الدليل الخاص بك بشكل أساسي للقراءة فقط (فكر: دليل أعمال ثابت)، فإن Astro تستحق النظر -- تحقق من قدرات تطوير Astro.

أفضل مجموعة تقنيات لمواقع الدليل والسوق في 2026 - العمارة

الطبقة 2: قاعدة البيانات -- Supabase PostgreSQL

هذا هو الخيار الأكثر رأياً في الحزمة، وهو الذي أنا أكثر ثقة به. يعطيك Supabase PostgreSQL مع جميع ملحقاته -- وللدلائل/مواقع السوق، ثلاثة ملحقات مهمة جداً: pgvector، PostGIS، وبحث PostgreSQL الكامل النصي المدمج.

عبر مشاريع الدليل الخاصة بنا، نحن ندير 253,000+ سجل في Supabase. يتضمن ذلك القوائم وملفات تعريف المستخدمين والتقييمات والحجوزات وبيانات الاشتراك. يتعامل PostgreSQL مع هذا دون تقصير -- تم تصميمه لمجموعات البيانات أكبر بأوامر من حيث الحجم.

الرؤية الحقيقية هي هذه: بالاحتفاظ بالبحث النصي الكامل وتضمينات المتجهات والبيانات الجغرافية في نفس قاعدة البيانات، تتجنب تعقيد المعمارية المتعلقة بمزامنة البيانات عبر خدمات متعددة. لا تحتاج Elasticsearch للبحث النصي. لا تحتاج Pinecone للبحث المتجهي. لا تحتاج خدمة جغرافية منفصلة. قاعدة بيانات واحدة. مصدر حقيقة واحد.

-- استعلام واحد يجمع بين البحث النصي وتشابه المتجهات والقرب الجغرافي
SELECT 
  l.id,
  l.name,
  l.description,
  ts_rank(l.search_vector, plainto_tsquery('english', 'family therapist')) AS text_rank,
  1 - (l.embedding <=> $1::vector) AS semantic_similarity,
  ST_Distance(
    l.location::geography, 
    ST_MakePoint(-97.7431, 30.2672)::geography
  ) / 1609.34 AS distance_miles
FROM listings l
WHERE 
  l.search_vector @@ plainto_tsquery('english', 'family therapist')
  AND ST_DWithin(
    l.location::geography, 
    ST_MakePoint(-97.7431, 30.2672)::geography, 
    80467  -- 50 ميل بالمتر
  )
ORDER BY 
  (text_rank * 0.3) + (semantic_similarity * 0.5) + ((1 - distance_miles/50) * 0.2) DESC
LIMIT 20;

هذا استعلام واحد. ترتيب النص الكامل، تصنيف تشابه دلالي، وتصفية مسافة جغرافية -- كل هذا يحدث في PostgreSQL. حاول عمل ذلك عبر ثلاث خدمات منفصلة والحفاظ على النتائج متسقة.

للحصول على نظرة أعمق على خيارات قاعدة البيانات للدلائل، تحقق من مقارنة نظام إدارة المحتوى بدون رأس وقاعدة البيانات.

أمان مستوى الصف في Supabase

يستحق RLS ذكره الخاص لأنه يحل مشكلة تطارد backends السوق: التحكم في الوصول إلى البيانات على مستوى قاعدة البيانات. بدلاً من كتابة فحوصات التفويض في كل نقطة نهاية API، تقوم بتحديد السياسات على قاعدة البيانات نفسها.

-- يمكن للمعالجين رؤية سجلات عملائهم الخاصة فقط
CREATE POLICY "therapists_own_clients" ON client_records
  FOR SELECT USING (
    auth.uid() = therapist_id
    OR auth.jwt() ->> 'role' = 'admin'
  );

حتى إذا كان لديك خطأ في كود API الخاص بك يكشف عن استعلام بطريق الخطأ، فإن RLS يمنع الوصول إلى البيانات غير المصرح بها. لمواقع السوق التي تتعامل مع بيانات المستخدم الحساسة، هذا غير قابل للتفاوض.

الطبقة 3: المصادقة -- Supabase Auth

نظراً لأننا بالفعل في نظام Supabase ecosystem لقاعدة البيانات، فإن استخدام Supabase Auth يناسب بشكل طبيعي. لكن السبب الحقيقي الذي نستخدمه لمواقع السوق هو المصادقة المستندة إلى الأدوار التي تتكامل مباشرة مع RLS.

يقوم أحد مشاريع السوق الخاصة بنا بتشغيل المصادقة المستندة إلى الأدوار عبر ثلاثة أنواع من المستخدمين المتميزين: المسؤولون ومقدمو الخدمات والعملاء. ترى كل دور بيانات مختلفة ولديها أذونات مختلفة وتصل إلى ميزات مختلفة. مشروع آخر يقوم بتشغيل نظام عضوية ذو 4 مستويات حيث يفتح كل مستوى تدريجياً ميزات أكثر.

يقوم التنفيذ بتخزين دور المستخدم في بيانات وصفهم JWT، مما يعني أن سياسات RLS يمكنها الرجوع إليها دون استعلامات قاعدة بيانات إضافية:

// تعيين الدور أثناء التسجيل
const { data, error } = await supabase.auth.signUp({
  email,
  password,
  options: {
    data: {
      role: 'therapist',
      tier: 'professional'
    }
  }
});

يدعم Supabase Auth موفري OAuth (Google و Apple وما إلى ذلك) والروابط السحرية وبريد إلكتروني/كلمة مرور -- كل شيء من الصندوق. بالنسبة للأسواق B2C، يعد تسجيل الدخول الاجتماعي مطلوباً عملياً. رأينا معدلات تحويل التسجيل تزيد بنسبة 30-40% عندما يتوفر OAuth من Google جنباً إلى جنب مع البريد الإلكتروني/كلمة المرور.

الطبقة 4: الدفع -- Stripe Connect

معالجة الدفع هي حيث تصبح مشاريع السوق معقدة حقاً. هناك فرق كبير بين "قبول الدفع" و"قبول الدفع، وأخذ عمولة منصة، والتعامل مع المبالغ المستردة، وإدارة الاشتراكات عبر 30 دولة، والتعامل مع العملات بدون فاصلة عشرية."

يتعامل Stripe Connect مع تدفق دفع السوق -- الانقسام بين المنصة ومقدم الخدمة. يقوم أحد مشاريعنا بمعالجة العمولات في كل معاملة، وتوجيه رسالة المنصة وحصة مقدم الخدمة تلقائياً.

لكن جانب الاشتراك هو المكان الذي يصبح مثيراً للاهتمام. نقوم بتشغيل نظام اشتراك ذو 4 مستويات مع التسعير الإقليمي عبر 30+ دولة. هذا يعني الحفاظ على كائنات Stripe Price منفصلة لمناطق عملة مختلفة.

خطأ العملة بدون فاصلة عشرية

هذه قصة أشاركها لأنها أنقذتنا (وعميلنا) أموالاً حقيقية. يتعامل Stripe مع معظم العملات في أصغر وحدة لها -- لذا $10.00 USD هو 1000 (سنتات). لكن بعض العملات مثل الين الياباني (JPY) والوون الكوري (KRW) لا تملك وحدات عشرية. ¥1000 فقط 1000، وليس 100000.

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

const ZERO_DECIMAL_CURRENCIES = [
  'BIF', 'CLP', 'DJF', 'GNF', 'JPY', 'KMF', 'KRW', 
  'MGA', 'PYG', 'RWF', 'UGX', 'VND', 'VUV', 'XAF', 'XOF', 'XPF'
];

function formatAmountForStripe(amount: number, currency: string): number {
  if (ZERO_DECIMAL_CURRENCIES.includes(currency.toUpperCase())) {
    return Math.round(amount);
  }
  return Math.round(amount * 100);
}

استثناءات التجربة الإقليمية

مشكلة أخرى: كان علينا استبعاد بعض دول جنوب شرق آسيا من عروض التجربة المجانية لأن معدلات الاحتيال جعلتها غير قابلة للحياة اقتصادياً في تلك المناطق. تسمح لك واجهة برمجة Stripe بتعيين هذا مع فحوصات موقع العميل الضريبي، لكن عليك أن تعرف أنها مشكلة أولاً. هذا هو نوع الشيء الذي تتعلمه فقط بتشغيل سوق متعدد الدول في الإنتاج.

الطبقة 5: البحث -- نمط البحث الثلاثي

هذا ربما يكون أكثر النمط المعماري قيمة في هذه المقالة. معظم مواقع الدليل توفر بحثاً نصياً أساسياً. الجيدة منها تضيف تصفية الموقع. نحن نقوم بتشغيل جميع أنواع البحث الثلاثة في نفس الوقت ومزج النتائج.

البحث النصي الكامل (PostgreSQL tsvector): يتعامل مع مطابقة الكلمات الرئيسية الدقيقة والمشتقة. عندما يبحث شخص ما عن "سباك"، فإنه يطابق أيضاً "السباكة". سريع وفهم جيد ومدمج في Postgres.

البحث الدلالي (pgvector + تضمينات Claude): يتعامل مع الاستعلامات القائمة على المعنى. "شخص يمكنه مساعدتي على الشعور بقلق أقل بشأن علاقتي" لا يحتوي على كلمة "معالج"، لكن البحث الدلالي يفهم القصد. نقوم بإنشاء تضمينات لكل قائمة باستخدام واجهة برمجة Claude API ونخزنها كمتجهات في pgvector.

البحث الجغرافي (PostGIS): يتعامل مع استعلامات القرب. "في غضون 25 ميلاً من وسط مدينة شيكاغو" يصبح استعلام مكاني مفهرس وسريع.

المزج هو المكان الذي يصبح مثيراً للاهتمام. نحن نزن كل نوع بحث بشكل مختلف اعتماداً على الاستعلام:

interface SearchWeights {
  textWeight: number;
  semanticWeight: number;
  geoWeight: number;
}

function calculateWeights(query: string, hasLocation: boolean): SearchWeights {
  const isNaturalLanguage = query.split(' ').length > 4;
  
  if (hasLocation && isNaturalLanguage) {
    return { textWeight: 0.2, semanticWeight: 0.5, geoWeight: 0.3 };
  } else if (hasLocation) {
    return { textWeight: 0.4, semanticWeight: 0.2, geoWeight: 0.4 };
  } else if (isNaturalLanguage) {
    return { textWeight: 0.2, semanticWeight: 0.7, geoWeight: 0.1 };
  }
  return { textWeight: 0.7, semanticWeight: 0.2, geoWeight: 0.1 };
}

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

الطبقة 6: الوسائط -- Supabase Storage + Next.js Image

مواقع الدليل ثقيلة الصور. صور القائمة وصور ملفات تعريف المستخدمين والشعارات -- يتراكم. نستخدم Supabase Storage للتحميل ومكون Next.js <Image> لتسليم محسّن.

الإعدادات الرئيسية هي إعداد دلاء Supabase Storage مع سياسات الوصول المناسبة (عام لصور القائمة، خاص لوثائق المستخدم) ثم استخدام تحسين الصور في Next.js لتقديم صيغ WebP/AVIF بالأبعاد الصحيحة:

<Image
  src={`${process.env.NEXT_PUBLIC_SUPABASE_URL}/storage/v1/object/public/listings/${listing.image_path}`}
  alt={listing.name}
  width={800}
  height={600}
  sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
  loading="lazy"
/>

يتعامل Next.js مع تحويل التنسيق وتغيير الحجم والتخزين المؤقت تلقائياً عند النشر على Vercel. رأينا تخفيضات حمل الصور بنسبة 60-70% مقارنة بتقديم التحميلات الأصلية مباشرة.

الطبقة 7: الاستضافة -- Vercel

جميع مواقع الدليل والسوق الإنتاجية الخاصة بنا تعمل على Vercel. السبب مباشر: Vercel هي حيث يعمل Next.js بشكل أفضل. ISR، Server Components، middleware الحافة، عناوين URL المعاينة -- كل شيء يعمل دون تكوين.

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

تعتبر النشرات المعاينة كبيرة أيضاً لمشاريع السوق ذات أصحاب المصلحة المتعددين. يحصل كل طلب سحب على عنوان URL الخاص به. يمكن للعميل مراجعة واجهة البحث الجديدة على عنوان URL حقيقي مع بيانات حقيقية قبل أن يذهب أي شيء إلى الإنتاج.

يغطي خطة Vercel Pro بسعر $20/شهر لكل عضو فريق معظم مشاريع الدليل. قد تحتاج المواقع الأكبر حجماً (100K+ صفحة) إلى خطة Enterprise للحصول على حدود ISR أعلى والدعم المخصص.

الطبقة 8: البريد الإلكتروني -- Brevo API

ينقسم البريد الإلكتروني في مشاريع السوق إلى فئتين: معاملات (تأكيدات الحجز وإعادة تعيين كلمة المرور وإيصالات الدفع) وتسويق (رسائل إخبارية وإعلانات الميزات وإعادة التشغيل).

نستخدم Brevo (سابقاً Sendinblue) لكليهما، يُستدعى من مسارات API في Next.js:

// app/api/send-booking-confirmation/route.ts
import { NextResponse } from 'next/server';

export async function POST(request: Request) {
  const { to, bookingDetails } = await request.json();
  
  const response = await fetch('https://api.brevo.com/v3/smtp/email', {
    method: 'POST',
    headers: {
      'api-key': process.env.BREVO_API_KEY!,
      'content-type': 'application/json',
    },
    body: JSON.stringify({
      to: [{ email: to }],
      templateId: 12, // نموذج تأكيد الحجز
      params: bookingDetails,
    }),
  });
  
  return NextResponse.json({ success: response.ok });
}

تتعامل الطبقة المجانية من Brevo مع 300 بريد إلكتروني/يوم، وهو كافٍ للدلائل في المراحل الأولى. تبدأ خططهم المدفوعة من $9/شهر لـ 5,000 بريد إلكتروني. مقارنة بـ SendGrid أو Mailgun، وجدنا معدلات توصيل Brevo مماثلة والتسعير أكثر قابلية للتنبؤ للمشاريع المتنامية.

الطبقة 9: الذكاء الاصطناعي -- Claude API

الذكاء الاصطناعي ليس حيلة في حزمة الدليل الخاصة بنا -- إنه مكون بنية تحتية أساسي يتعامل مع ثلاث وظائف مميزة.

تضمينات البحث الدلالي: تحصل كل قائمة على تضمين تم إنشاؤه بواسطة Claude يجسد معناها. هذا يقوي طبقة البحث الدلالي الموصوفة أعلاه.

إثراء المحتوى: للدلائل التي تحتوي على قوائم مقدمة من المستخدمين، تختلف الجودة بشكل كبير. نستخدم Claude لتطبيع الأوصاف واستخراج البيانات المهيكلة (الساعات والتخصصات ومناطق الخدمة) وإنشاء ملخصات صديقة لـ SEO.

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

تسعير Claude API اعتباراً من 2025-2026: يكلف Claude 3.5 Sonnet $3 لكل مليون رمز إدخال و$15 لكل مليون رمز إخراج. بالنسبة لإنشاء التضمينات في دليل 100K قائمة، تبلغ التكلفة لمرة واحدة حوالي $50-80. تعمل التكاليف الجارية لاستعلامات البحث وتفاعلات الدردشة عادة $100-300/شهر اعتماداً على حركة المرور.

الطبقة 10: المراقبة -- Vercel Analytics + PostHog

تحتاج إلى نوعين من المراقبة لمواقع الدليل: مقاييس الأداء وتحليلات سلوك المستخدم.

Vercel Analytics يعطيك Web Vitals (LCP و CLS و INP) وتراقبة المستخدم الحقيقية وبيانات حركة المرور. تم بناؤها في لوحة تحكم Vercel ولا تتطلب أي تكوين. بالنسبة لمواقع الدليل، نراقب LCP بعناية على صفحات القائمة -- إذا زحفت فوق 2.5 ثانية، نعرف أن هناك شيء ما خاطئ مع إعدادات ISR الخاصة بنا أو تحسين الصور.

PostHog يتعامل مع تحليلات المنتج: استعلامات البحث التي تعيد نتائج صفرية (لذلك نعرف ما هي فجوات المحتوى التي يجب ملؤها) وفئات القائمة التي تحصل على أكثر الآراء وحيث يتسرب المستخدمون في تدفق الحجز أو التسجيل. تغطي الطبقة المجانية من PostHog حتى مليون حدث شهرياً، مما يتعامل مع معظم الأسواق في المراحل الأولى.

يعطيك التعديل "هل الموقع سريع؟" و"هل يجد المستخدمون ما يحتاجون؟" -- سؤالان مختلفان جداً لكن متساويان في الأهمية.

جدول مقارنة الحزمة الكاملة

الطبقة اختيارنا البديل السبب في اختيار اختيارنا
الواجهة الأمامية Next.js 15 Astro و Remix ISR لـ 100K+ صفحة
قاعدة البيانات Supabase PostgreSQL PlanetScale و Neon pgvector + PostGIS في قاعدة بيانات واحدة
المصادقة Supabase Auth Clerk و Auth.js تكامل RLS الأصلي
الدفع Stripe Connect Paddle و LemonSqueezy تقسيمات السوق والعملات المتعددة
البحث نمط ثلاثي (في قاعدة البيانات) Algolia و Elasticsearch لا مزامنة خارجية وتكلفة أقل
الوسائط Supabase Storage Cloudinary و S3 نفس النظام وفواتير أبسط
الاستضافة Vercel Netlify و AWS Amplify أفضل دعم Next.js ISR
البريد الإلكتروني Brevo API SendGrid و Resend نسبة السعر/التسليم
الذكاء الاصطناعي Claude API OpenAI و Gemini أفضل تفكير للمهام المتعلقة بالمحتوى
المراقبة Vercel + PostHog Datadog و Mixpanel الطبقات المجانية تغطي النمو المبكر

تكاليف هذه الحزمة في الإنتاج

دعنا نتحدث أرقام حقيقية لموقع دليل به ~50K قوائم وحركة مرور معتدلة (50K زوار شهريين):

الخدمة الخطة التكلفة الشهرية
Vercel Pro $20
Supabase Pro $25
Stripe الدفع حسب الاستخدام 2.9% + 30¢ لكل معاملة
Brevo Starter $9
Claude API مستندة إلى الاستخدام ~$150
PostHog الطبقة المجانية $0
إجمالي التكاليف الثابتة ~$204/شهر

هذا بأسعار معقولة للغاية لمنصة سوق إنتاجية. تعطيك خطة Supabase Pro 8GB من مساحة قاعدة البيانات و 250GB من النطاق الترددي و 100GB من التخزين -- أكثر من كافية لدليل بـ 50K قوائم.

مع تطورك متجاوزاً 100K قوائم وفي حركة مرور أعلى، توقع التكاليف للزيادة إلى حوالي $500-800/شهر. لا تزال أرخص بشكل كبير من النهج القديم لتشغيل خوادم مخصصة وعناقيد Elasticsearch المدارة وقواعد بيانات ناقلات منفصلة.

إذا كنت تخطط لمشروع دليل أو سوق وتريد فهم التسعير بمزيد من التفاصيل، تحقق من صفحة التسعير أو تواصل معنا للحصول على تقدير محدد للمشروع.

الأسئلة الشائعة

ما أفضل قاعدة بيانات لموقع دليل في 2026? PostgreSQL عبر Supabase هو توصيتنا الأفضل. تجمع pgvector للبحث الدلالي و PostGIS للاستعلامات الجغرافية والبحث النصي المدمج يعني أنه يمكنك التعامل مع جميع أبعاد البحث الثلاثة بدون خدمات خارجية. مع 253K+ سجل عبر مشاريع الإنتاج الخاصة بنا، فإنه يتعامل مع بيانات نطاق الدليل دون مشكلة. البدائل مثل PlanetScale (مستندة إلى MySQL) تفتقر دعم PostGIS، مما يجعل البحث الجغرافي أصعب بشكل كبير.

هل يمكن لـ Next.js التعامل مع 100,000+ صفحة لموقع دليل? نعم، لكن تحتاج ISR (Incremental Static Regeneration). أنت لا تولد جميع صفحات 100K في وقت البناء. بدلاً من ذلك، تقوم بإنشاء مسبق للصفحات الأكثر حركة مرور (ربما أفضل 1,000-5,000) وتسمح لـ ISR بإنشاء الباقي حسب الطلب. لقد فعلنا هذا مع 137K صفحة في الإنتاج. المفتاح هو تعيين فترات إعادة تحقق مناسبة -- نستخدم 3600 ثانية (ساعة واحدة) لصفحات القائمة وفترات أقصر لصفحات الفئة/البحث.

كيف يعمل البحث الدلالي في موقع الدليل? يتم تحويل كل قائمة إلى متجه رقمي ("تضمين") يجسد معناها باستخدام نموذج ذكاء اصطناعي مثل Claude. عندما يبحث مستخدم عن لغة طبيعية -- "شخص يساعد الأطفال على ADHD" -- يتم أيضاً تحويل هذا الاستعلام إلى متجه. تجد قاعدة البيانات القوائم التي تكون متجهاتها قريبة رياضياً من متجه الاستعلام باستخدام عامل تشابه جيب التمام في pgvector. هذا يعمل حتى عندما لا تحتوي القائمة على الكلمات الدقيقة من استعلام البحث.

هل Stripe Connect ضروري لسوق، أم يمكنني استخدام Stripe العادي? إذا كان سوقك يتضمن دفعات بين المشترين والبائعين (أو العملاء ومقدمي الخدمات)، فأنت بحاجة إلى Stripe Connect. Stripe العادي يسمح فقط لك بقبول الدفع إلى حسابك الخاص. يتعامل Connect مع الانقسام -- وأخذ عمولة منصة وتوجيه الباقي إلى مقدم الخدمة. كما أنه يتعامل مع تقارير 1099 للبائعين القائمين على الولايات المتحدة، وهي متطلب امتثال لا تريد بناءه بنفسك.

ما هي تكلفة بناء موقع دليل من الصفر? باستخدام الحزمة الموضحة هنا، تبدأ تكاليف البنية التحتية المستمرة حول $200/شهر لدليل متوسط الحجم. تختلف تكاليف التطوير على نطاق واسع بناءً على الميزات، لكن موقع دليل جاهز للإنتاج مع البحث وحسابات المستخدمين وإدارة القوائم يستغرق عادة 8-16 أسبوع للبناء. سوق كامل مع الدفع والحجوزات والاشتراكات يضيف 4-8 أسابيع أخرى. يمكنك استكشاف قدرات تطوير الدليل والسوق للمزيد من التفاصيل.

هل يجب أن استخدم Algolia أو Elasticsearch بدلاً من البحث داخل قاعدة البيانات? بالنسبة لمعظم مواقع الدليل، لا. يخلق تعقيد مزامنة البيانات بين قاعدة البيانات الأساسية وخدمة بحث منفصلة أخطاء ويضيف كمون ويزيد التكاليف. تفرض Algolia رسوم بناءً على عمليات البحث -- في النطاق، يصبح هذا باهظاً بسرعة (يبدأ التسعير الخاص بهم من $1/1,000 عملية بحث في خطة Build). تتعامل قدرات البحث المدمجة في PostgreSQL، خاصة في الجمع مع pgvector، مع البحث بنطاق الدليل بشكل جيد. الاستثناء: إذا كنت بحاجة إلى تسامح مع الأخطاء الإملائية والتصفية بالفئات مع أوقات استجابة أقل من 10 ملي ثانية على ملايين السجلات، فإن Algolia تستحق التعقيد.

ما الفرق بين بناء دليل مقابل سوق? دليل يسرد الأشياء ويسمح للمستخدمين بالعثور عليها. السوق يضيف معاملات -- دفع وحجوزات وعمولات وغالباً تفاعلات من جانبين بين مقدمي الخدمات والمستهلكين. الحزمة التقنية هي نفسها إلى حد كبير، لكن الأسواق تضيف Stripe Connect (أو ما يعادله) وأدوار مصادقة أكثر تعقيداً وتدفقات بريد إلكتروني معاملات. يصبح مخطط قاعدة البيانات أيضاً أكثر تعقيداً مع جداول الطلبات والفواتير والدفعات.

هل يمكنني إضافة ميزات ذكاء اصطناعي إلى موقع دليل موجود? بالتأكيد. طبقة الذكاء الاصطناعي في الحزمة الخاصة بنا إضافية وليست أساسية. يمكنك إضافة البحث الدلالي بإنشاء تضمينات لقوائمك الموجودة (وظيفة دفعة لمرة واحدة)، تخزينها في عمود pgvector، وإضافة نقطة نهاية بحث دلالي جنباً إلى جنب مع البحث النصي الموجود. يمكن إضافة ميزات إثراء المحتوى والدردشة كمسارات API مستقلة. أصعب جزء عادة ما يكون توليد التضمينات لمجموعة بيانات كبيرة موجودة -- ميزانية بضع ساعات من وقت المعالجة و $50-100 في تكاليف API لـ 100K قوائم.