ترجمة المقالة إلى العربية

إذا كنت تبني مشروعًا مدعومًا بـ CMS بدون رأس في عام 2026 وقد ضيقت خياراتك إلى Payload CMS و Directus، مبروك — لديك ذوق جيد. كلاهما مفتوح المصدر وقابل للاستضافة الذاتية ومبني على Node.js. كلاهما لديه مجتمعات نشطة وتطلق الميزات بسرعة. لكنهما يمثلان فلسفات مختلفة جوهريًا حول كيفية ظهور مخطط المحتوى الخاص بك، وهذا الفرق سيؤثر على كل قرار تتخذه في المشروع.

لقد أطلقت مواقع إنتاجية مع كليهما خلال السنتين الماضيتين. إليك ما أعتقده بالفعل، وليس ما تقوله صفحات التسويق.

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

• الانقسام الفلسفي الأساسي
• تصميم المخطط: Code-First مقابل Database-First
• TypeScript وتجربة المطور
• طبقة API وقدرات الاستعلام
• لوحة المسؤول وتحرير المحتوى
• المصادقة والتحكم في الوصول
• الأداء وقابلية التوسع
• النشر والاستضافة
• التسعير والترخيص في عام 2026
• متى تختار أيهما
• الأسئلة الشائعة

الانقسام الفلسفي الأساسي

دعني أقول هذا بوضوح لأنها أهم شيء يجب أن تفهمه:

Payload CMS هو code-first. تقوم بتعريف مخطط بياناتك في ملفات تكوين TypeScript. قاعدة البيانات تتوافق مع الكود.

Directus هو database-first. يمكنك توجيهه إلى قاعدة بيانات موجودة وسيتم فحص المخطط. واجهة المسؤول تتوافق مع قاعدة البيانات الخاصة بك.

لا يوجد نهج أفضل بشكل موضوعي. لكن أحدهما سيكون أفضل بشكل كبير لمشروعك، والخطأ في هذا يعني الألم لاحقًا.

إذا كنت مطورًا تبني مشروعًا من الصفر وتريد أن يكون مخطط CMS الخاص بك في السيطرة على الإصدارات جنبًا إلى جنب مع كود التطبيق، فإن Payload سيشعرك وكأنك في البيت. إذا كان لديك قاعدة بيانات PostgreSQL موجودة بها 200 جدول وتحتاج إلى طبقة إدارة محتوى فوقها، فإن Directus سيوفر لك أسابيع.

تصميم المخطط: Code-First مقابل Database-First

نهج Payload للـ Code-First

في Payload 3.x (الإصدار الرئيسي الحالي اعتبارًا من 2026)، تقوم بتعريف المجموعات في ملفات تكوين TypeScript:

// collections/Posts.ts
import type { CollectionConfig } from 'payload'

export const Posts: CollectionConfig = {
  slug: 'posts',
  admin: {
    useAsTitle: 'title',
  },
  fields: [
    {
      name: 'title',
      type: 'text',
      required: true,
    },
    {
      name: 'content',
      type: 'richText',
    },
    {
      name: 'author',
      type: 'relationship',
      relationTo: 'users',
    },
    {
      name: 'publishedAt',
      type: 'date',
    },
    {
      name: 'status',
      type: 'select',
      options: [
        { label: 'Draft', value: 'draft' },
        { label: 'Published', value: 'published' },
      ],
      defaultValue: 'draft',
    },
  ],
}

هذا التكوين هو مصدر الحقيقة الخاص بك. عندما يبدأ Payload، يقوم بإنشاء تهجيرات قاعدة البيانات تلقائيًا (Payload 3.x يستخدم Drizzle ORM تحت الغطاء مع دعم PostgreSQL أو SQLite، وتستمر في دعم MongoDB). المخطط الخاص بك يعيش في Git. تراجع تغييرات المخطط في عمليات الدمج. إنه نفس سير العمل الذي ستستخدمه لكود التطبيق، وهذه هي النقطة.

يقوم Payload أيضًا بإنشاء أنواع TypeScript تلقائيًا من هذه التكوينات. لذا عندما تستعلم عن posts في واجهة Next.js الأمامية، تحصل على سلامة نوع كاملة دون الحاجة إلى الحفاظ على تعريفات نوع منفصلة.

نهج Directus للـ Database-First

يتخذ Directus الموقف المعاكس. يمكنك:

1. توجيه Directus إلى قاعدة بيانات موجودة وقراءة المخطط
2. إنشاء مجموعات من خلال واجهة المسؤول، التي تنشئ تهجيرات SQL
3. استخدام Directus SDK لإدارة المخطط برمجيًا

// إنشاء مجموعة عبر Directus SDK
import { createDirectus, rest, createCollection } from '@directus/sdk'

const client = createDirectus('http://localhost:8055').with(rest())

await client.request(
  createCollection({
    collection: 'posts',
    schema: {
      name: 'posts',
    },
    meta: {
      icon: 'article',
      note: 'Blog posts',
    },
  })
)

Directus 11 (تم إصداره في أواخر 2025) حسّن أدوات إدارة المخطط بشكل كبير. يمكنك الآن تصدير واستيراد لقطات مخطط كملفات YAML، مما يجعل التحكم في الإصدارات أكثر عملية مما كان عليه من قبل:

# تصدير المخطط الحالي
npx directus schema snapshot ./schema-snapshot.yaml

# تطبيق فرق المخطط على بيئة أخرى
npx directus schema apply ./schema-snapshot.yaml

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

جدول مقارنة المخطط

الجانب	Payload CMS	Directus
مصدر الحقيقة للمخطط	ملفات تكوين TypeScript	قاعدة البيانات نفسها
إدارة إصدارات المخطط	سير عمل Git الأصلي	لقطات YAML (محسّنة في v11)
دعم قاعدة البيانات الموجودة	محدود (مسار الترحيل)	ممتاز (فحص)
الأنواع المُنشأة تلقائيًا	نعم، من التكوين	نعم، عبر SDK + CLI
دعم قاعدة البيانات	PostgreSQL, SQLite, MongoDB	PostgreSQL, MySQL, MariaDB, SQLite, MS SQL, CockroachDB, OracleDB
ORM / طبقة الاستعلام	Drizzle ORM (v3)	محرك استعلام مخصص (قائم على Knex)
إنشاء التهجير	تلقائي من تغييرات التكوين	لقطات فرق المخطط

TypeScript وتجربة المطور

قصة Payload الخاصة بـ TypeScript

Payload هو TypeScript في صميمه. المشروع بأكمله مكتوب بـ TypeScript وتم تكوينه في TypeScript وينشئ TypeScript. عندما تشغل payload generate:types، تحصل على واجهات لكل مجموعة:

// مُنشأ تلقائيًا
export interface Post {
  id: string
  title: string
  content?: RichTextContent
  author?: string | User
  publishedAt?: string
  status?: 'draft' | 'published'
  createdAt: string
  updatedAt: string
}

تتدفق هذه الأنواع عبر Local API واستجابات REST API واستعلامات GraphQL. في Payload 3.x، نظرًا لأنه يعمل داخل تطبيق Next.js الخاص بك، يمكنك استيراد واستخدام هذه الأنواع مباشرة. لا يوجد SDK منفصل مطلوب. لا توجد استدعاءات API لعرض الخادم — أنت تستعلم قاعدة البيانات مباشرة:

// في Next.js Server Component
import { getPayload } from 'payload'
import config from '@payload-config'

export default async function BlogPage() {
  const payload = await getPayload({ config })
  
  const posts = await payload.find({
    collection: 'posts',
    where: {
      status: { equals: 'published' },
    },
  })
  // posts.docs مكتوبة بالكامل كـ Post[]
  
  return <PostList posts={posts.docs} />
}

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

قصة Directus الخاصة بـ TypeScript

حسّنت Directus دعمها لـ TypeScript بشكل كبير. تدعم حزمة @directus/sdk معاملات النوع العامة:

import { createDirectus, rest, readItems } from '@directus/sdk'

interface Schema {
  posts: Post[]
  users: User[]
}

interface Post {
  id: number
  title: string
  content: string
  author: number | User
  published_at: string
  status: 'draft' | 'published'
}

const client = createDirectus<Schema>('http://localhost:8055').with(rest())

const posts = await client.request(
  readItems('posts', {
    filter: { status: { _eq: 'published' } },
    fields: ['id', 'title', 'content', 'author.*'],
  })
)

المشكلة؟ يجب عليك كتابة والحفاظ على تعريفات النوع هذه بنفسك (أو إنشاؤها باستخدام أدوات مجتمعية مثل directus-typescript-gen). لم يتم اشتقاق الأنواع من المخطط تلقائيًا بنفس الطريقة الأولى التي يقوم بها Payload. هذا هو المقابل لـ database-first: قاعدة البيانات لا تعرف TypeScript.

طبقة API وقدرات الاستعلام

كلاهما ينشئ واجهات برمجة تطبيقات REST و GraphQL، لكن بنكهات مختلفة.

Payload يمنحك:

• REST API مع التحكم في العمق للعلاقات
• GraphQL API (مُنشأ تلقائيًا من التكوين)
• Local API (استعلامات قاعدة البيانات المباشرة، بدون فوائض HTTP)
• عوامل استعلام كاملة: equals, not_equals, greater_than, in, contains, إلخ.

Directus يمنحك:

• REST API مع اختيار الحقول الدقيق
• GraphQL API (مُنشأ تلقائيًا من فحص المخطط)
• Directus SDK (يغلف REST، مكتوب إذا قدمت واجهات)
• الفلترة الغنية بـ _eq, _neq, _gt, _in, _contains, العوامل المنطقية _and/_or
• استعلامات التجميع المدمجة في API (count, sum, avg, إلخ.)

يتمتع Directus بميزة طفيفة على مرونة API للاستعلامات المعقدة، خاصة التجميع. إذا كنت بحاجة إلى استعلامات من نمط GROUP BY من خلال API، يتعامل Directus مع ذلك بشكل أصلي. مع Payload، ستنخفض عادةً إلى طبقة Drizzle ORM أو تكتب نقطة نهاية مخصصة.

الميزة الحاسمة لـ Payload هي Local API. عندما يكون CMS والواجهة الأمامية Next.js في نفس العملية، فإنك تتجاوز HTTP بالكامل. بالنسبة للصفحات المعروضة على الخادم، هذا يعني إنشاءات أسرع وزمن انتقال أقل.

لوحة المسؤول وتحرير المحتوى

يتم إنشاء لوحة مسؤول Payload 3.x باستخدام React وتُشحن كجزء من تطبيق Next.js الخاص بك. إنها قابلة للتخصيص باستخدام مكونات React — يمكنك تجاوز أي جزء من الواجهة الفعلية تقريبًا. محرر النص الغني المستند إلى الكتل (المبني على Lexical اعتبارًا من v3) قوي وقابل للتوسع.

تم بناء لوحة مسؤول Directus باستخدام تطبيق Vue.js منفصل (Directus Data Studio). إنها مصقولة وتتمتع بتصميم بصري قوي ويميل المستخدمون غير التقنيين إلى التقاطها بسرعة. منشئ التدفق/الأتمتة في Directus أكثر مرئية وسهولة الوصول من نظام hooks الخاص بـ Payload.

الميزة	Payload CMS	Directus
إطار عمل المسؤول	React (Next.js)	Vue.js (مستقل)
محرر النص الغني	قائم على Lexical	TipTap / WYSIWYG
الحقول المخصصة	مكونات React	تمديدات Vue
سير العمل/الأتمتة	Hooks + نقاط نهاية مخصصة	Directus Flows (منشئ بصري)
التحليل المحلي	قيم المجال المدمجة i18n	قيم المجال المدمجة i18n
إدارة إصدارات المحتوى	مسودة/نشر + إصدارات	إدارة إصدارات المحتوى + المراجعات
إدارة الملفات	مكتبة الوسائط المدمجة	مكتبة الوسائط المدمجة مع التحويلات

إليك رأيي الصريح: بالنسبة للفرق الثقيلة على المطورين، يعتبر المسؤول الخاص بـ Payload أكثر طبيعية للتوسع لأنك تكتب React. بالنسبة للفرق حيث يكون محررو المحتوى هم المستخدمون الأساسيون وتريد تجربة UX منخفضة الاحتكاك، لوحة مسؤول Directus أكثر سهولة الوصول قليلاً من الصندوق.

المصادقة والتحكم في الوصول

كلا النظامين لديهما مصادقة ناضجة، لكنهما يعملان بشكل مختلف.

يستخدم Payload المصادقة القائمة على المجموعة. تقوم بوضع علامة على مجموعة كمجموعة مصادقة (عادة users)، وتحصل على تسجيل الدخول والتسجيل وإعادة تعيين كلمة المرور والتحقق من البريد الإلكتروني وجلسات JWT/القائمة على ملفات تعريف الارتباط. يتم تعريف التحكم في الوصول لكل مجموعة وحقل باستخدام الدوال:

{
  slug: 'posts',
  access: {
    read: () => true, // عام
    create: ({ req: { user } }) => Boolean(user), // مصرح
    update: ({ req: { user } }) => user?.role === 'admin',
    delete: ({ req: { user } }) => user?.role === 'admin',
  },
  fields: [
    {
      name: 'internalNotes',
      type: 'text',
      access: {
        read: ({ req: { user } }) => user?.role === 'admin',
      },
    },
  ],
}

هذا قوي جدًا. تتلقى دوال التحكم في الوصول سياق الطلب الكامل، لذا يمكنك تنفيذ أي نمط — RBAC, ABAC, متعدد الاستئجار، أمان على مستوى الصف.

يستخدم Directus نظام أذونات قائم على الدور يتم تكوينه من خلال لوحة المسؤول. تقوم بإنشاء أدوار وتعيين أذونات دقيقة (CRUDS لكل مجموعة) وإضافة أذونات مخصصة بالتصفية. إنها مرئية وحدسية، لكن أقل مرونة للأنماط المعقدة التي لا تناسب نموذج الدور.

بالنسبة لمعظم المشاريع، كلاهما كافٍ. بالنسبة لـ SaaS متعدد المستأجرين أو منطق التفويض المعقد، التحكم في الوصول القائم على الكود الخاص بـ Payload يصعب التغلب عليه.

الأداء وقابلية التوسع

لقد أجريت اختبارات تحميل على كليهما في ظروف واقعية. إليك ما لاحظته مع خوادم PostgreSQL:

المقياس	Payload CMS 3.x	Directus 11
قراءة بسيطة (عنصر واحد)	~2-5ms local API، ~15-25ms REST	~15-30ms REST
استعلام القائمة (100 عنصر، لا توجد علاقات)	~8-15ms local API، ~30-50ms REST	~25-50ms REST
استعلام القائمة (100 عنصر، عمق 2)	~20-40ms local API، ~60-100ms REST	~50-120ms REST
وقت البداية البارد	~3-6s (بدء تشغيل Next.js)	~2-4s (مستقل)
خط الأساس للذاكرة	~200-350MB (مع Next.js)	~150-250MB

ميزة Local API الخاصة بـ Payload حقيقية وكبيرة لأعباء عمل SSR/SSG. عندما تنشئ 10000 صفحة ثابتة، تضيف تخطي HTTP لكل استعلام.

Directus ليس بطيء على الإطلاق. يتعامل مع أعباء عمل REST عالية الإنتاجية جيدًا، وطبقة التخزين المؤقت الخاصة به (المدعومة بـ Redis) ناضجة.

النشر والاستضافة

Payload 3.x هو تطبيق Next.js، مما يعني يمكنك نشره في أي مكان يعمل فيه Next.js: Vercel, Netlify, AWS, Docker, إلخ. يبدأ Payload Cloud (استضافتهم المدارة) من $30/شهر لمشاريع الإنتاج اعتبارًا من أوائل 2026.

يعمل Directus كتطبيق Node.js مستقل. Docker هو طريقة النشر الموصى بها. يبدأ Directus Cloud من $29/شهر. الاستضافة الذاتية على VPS مباشرة — إنها فقط حاوية Docker تحتاج إلى اتصال قاعدة بيانات.

شيء واحد جدير بالملاحظة: نظرًا لأن Payload 3.x هو تطبيق Next.js الخاص بك، يتم نشر CMS والواجهة الأمامية معًا. هذا يبسط البنية الأساسية لكن يعني أن لوحة مسؤول CMS الخاصة بك تتسع مع الواجهة الأمامية. بالنسبة للمواقع عالية الحركة حيث تحتاج الواجهة الأمامية و CMS إلى احتياجات تحجيم مختلفة جدًا، قد تريد التفكير في تشغيلهما بشكل منفصل.

Directus، كخدمة منفصلة، ينفصل بشكل طبيعي عن هذه الاهتمامات. تتصل الواجهة الأمامية (سواء كانت Next.js أو Astro أو أي شيء آخر) بـ Directus عبر HTTP. هذه هندسة headless أكثر تقليدية.

في Social Animal، قمنا بنشر كلا الهندستين للعملاء. نهج Payload-in-Next.js يعمل بشكل جميل لمعظم مواقع التسويق والتطبيقات على نطاق متوسط. بالنسبة للإعدادات الكبيرة بمستهلكين واجهات أمامية متعددة، قد يكون نهج Directus المنفصل أنظف.

التسعير والترخيص في عام 2026

	Payload CMS	Directus
الترخيص	MIT	GPL-3.0 (مع BSL للميزات السحابية)
تكلفة الاستضافة الذاتية	مجاني	مجاني
استضافة سحابية	من $30/شهر (Payload Cloud)	من $29/شهر (Directus Cloud)
المستوى الكبير	تسعير مخصص	تسعير مخصص (يبدأ من ~$1,500/شهر)
الميزات المميزة	بعض الميزات الحصرية السحابية	اشتراك Directus+ ($99/شهر لامتدادات السوق)

كلاهما مفتوح المصدر حقًا للاستضافة الذاتية. ترخيص Payload MIT أكثر تساهلاً — يمكنك دمجه في منتجات تجارية بدون قيود. ترخيص Directus GPL-3.0 يعني أن الأعمال المشتقة يجب أن تكون أيضًا GPL، مما قد يكون مهمًا لمنتجات SaaS.

أدخلت Directus Directus+ في أواخر 2025، وهو اشتراك يفتح امتدادات سوق مميزة وأولوية الدعم. إنه اختياري لكن بعض الامتدادات الأكثر تقدمًا (مثل مساعد المحتوى المدعوم بالذكاء الاصطناعي) موجود خلف هذا الجدار الحاجز.

متى تختار أيهما

اختر Payload CMS عندما:

• تبني مشروعًا جديدًا من الصفر (greenfield)
• فريقك ثقيل على TypeScript ويريد schema-as-code
• تستخدم Next.js وتريد أقرب تكامل ممكن
• تحتاج إلى التحكم في الوصول المعقد المعرف بالكود
• تريد كل شيء في وحدة قابلة للنشر واحدة
• تقيّم ترخيص MIT

اختر Directus عندما:

• لديك قاعدة بيانات موجودة تحتاج إلى إدارتها
• فريقك يتضمن غير مطورين يحتاجون إلى تعديل الأنظمة
• تحتاج إلى دعم واجهات أمامية متعددة (ويب وجوال وإنترنت الأشياء) من CMS واحد
• تريد منشئ تدفق/أتمتة بصري
• تحتاج إلى دعم قاعدة بيانات واسع (MySQL و MSSQL و Oracle إلخ.)
• تفضل CMS كخدمة منفصلة مستقلة

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

بالنسبة للمشاريع التي تستخدم Astro كإطار عمل الواجهة الأمامية، يقترن نهج API المستقل الخاص بـ Directus بشكل طبيعي، حيث يجلب Astro البيانات وقت الإنشاء أو عبر نقاط نهاية الخادم. يعمل Payload أيضًا، لكنك تفقد ميزة Local API لأن Astro و Payload ستكون عمليات منفصلة.

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

هل Payload CMS حقًا مجاني في 2026؟ نعم. Payload CMS مرخص بموجب MIT وحر تماما للاستضافة الذاتية. Payload Cloud هي خدمة استضافة مدارة مدفوعة الأجر، لكن CMS نفسه — بما في ذلك جميع الميزات الأساسية — مفتوح المصدر. لا توجد بوابات ميزات على الإصدار المستضاف ذاتيًا.

هل يمكن لـ Directus أن يعمل مع قاعدة بيانات موجودة دون تعديلها؟ في الغالب نعم. يمكن لـ Directus فحص قاعدة بيانات موجودة وإنشاء طبقة إدارة فوقها. يضيف بعض جداول النظام (مع البادئة directus_) لتكوينها الخاص، لكنه لا يعدّل الجداول الموجودة لديك. هذا أحد أقوى الفروقات له.

أيهما أفضل لمطور واحد؟ يميل Payload CMS إلى أن يكون المفضل لدى المطورين الوحيدين الذين يرتاحون مع TypeScript. يعني سير عمل code-first أنه يمكنك إعداد المجموعات بسرعة، والأنواع المُنشأة تلقائيًا تقلل المكرر. Directus أفضل إذا كنت تريد واجهة مرئية للنماذج الأولية السريعة للمخطط دون كتابة ملفات التكوين.

هل يمكنني استخدام Payload CMS بدون Next.js؟ اعتبارًا من Payload 3.x، Next.js هو المحول الأساسي ولوحة المسؤول تعمل على Next.js. ومع ذلك، تعمل واجهات برمجة تطبيقات REST و GraphQL مع أي واجهة أمامية. لست مغلقًا في Next.js لموقعك الذي يتم تقديمه للمستهلكين — أنت تحتاج فقط إلى Next.js لتشغيل مسؤول Payload. كانت هناك نقاشات مجتمعية حول محولات إضافية (مثل Nuxt)، لكن لا شيء رسمي حتى الآن.

كيف يتعامل Directus مع تحليل المحتوى؟ يدعم Directus الترجمات على مستوى الحقل. تقوم بوضع علامة على الحقول كقابلة للترجمة وتكوين اللغات وتتعامل Directus مع تخزين الترجمات في جدول ذي صلة. تتيح API لك طلب محتوى بلغات محددة عبر معاملات ?fields واللغة. تم تنفيذها جيدًا وتكون مستقرة منذ سنوات.

أيهما لديه دعم أفضل للمكثفة/الإضافات؟ يمتلك Directus سوق امتداد أكبر، خاصة مع إضافات Directus+. يمكنك إنشاء واجهات مخصصة وعروض وأماكن نهاية وأجهزة استشعار وأوضاع. نموذج امتداد Payload قائم على تجاوزات مكونات React والمكثفات — إنه قوي لكن النظام البيئي أصغر. تميل مكثفات Payload إلى التركيز أكثر (مكثف SEO، منشئ النماذج، إعادة التوجيه) بينما تغطي امتدادات Directus نطاقًا أوسع.

هل هناك فرق في الأداء للمجموعات البيانات الكبيرة؟ بالنسبة للمجموعات البيانات التي تحتوي على ملايين الصفوف، كلاهما يؤدي بشكل جيد عند فهرسة مناسبة. يتمتع Directus بميزة طفيفة على مرونة استعلام الخام لأنه ينشئ SQL أكثر مباشرة من استعلامات API. طبقة Drizzle ORM الخاصة بـ Payload فعالة لكن تضيف تكلفة تجريد صغيرة. في الممارسة العملية، يكون ضبط قاعدة البيانات الخاصة بك أكثر أهمية بكثير من CMS الذي تختاره. كلاهما يدعم تجميع الاتصالات ويمكن أن يعمل مع نسخ القراءة.

هل يمكنني الترحيل من واحد إلى آخر لاحقًا؟ يمكنك، لكنه ليس تافهًا. بيانات المحتوى نفسها (المخزنة في PostgreSQL لكليهما) يمكن ترحيلها باستخدام أدوات قاعدة البيانات القياسية. الجزء الأصعب هو إعادة إنشاء تعريفات المخطط وقواعد التحكم في الوصول وأي منطق مخصص. إذا كنت تبني لـ بنية headless، فإن الحفاظ على فصل الواجهة الأمامية عن واجهات برمجة تطبيقات CMS المحددة (باستخدام طبقة تجريد) سيجعل أي ترحيل CMS مستقبلي أسهل بشكل كبير.