عندما تتجاوز إمكانيات Strapi CMS: البناء باستخدام Payload + Supabase
متى تكون قد تجاوزت Strapi CMS: البناء باستخدام Payload + Supabase
لقد قمت بإعداد Strapi لأكثر من عشرة مشاريع عملاء على مدار السنوات القليلة الماضية. إنه نظام إدارة محتوى رائع للبدء -- لوحة إدارة ودية، نظام إضافات لائق، وثائق قوية. لكن في مكان ما حول الشهر الثامن عشر، تقريباً كل فريق عملت معه يصطدم بجدار. الترحيلات تصبح مؤلمة، والتخصيصات تبدو معيبة، وشركاء الواجهة الأمامية المحبون لـ TypeScript يبدأون بالتذمر بشأن تجربة المطور. إذا كان هذا يبدو مألوفاً، فأنت لست وحدك. دعني أشرح لك العلامات التي تشير إلى أنك تجاوزت Strapi، والأهم من ذلك، ما يجب بناؤه بدلاً منه.

جدول المحتويات
- مرحلة شهر العسل: لماذا يعمل Strapi في البداية
- ستة علامات على أنك تجاوزت Strapi
- فهم خيارك: Payload مقابل Supabase مقابل البقاء
- لماذا Payload CMS هي الخطوة الطبيعية التالية
- حيث ينطبق Supabase (وأين لا ينطبق)
- مجموعة Payload + Supabase: غوص معماري عميق
- استراتيجية الترحيل: الابتعاد عن Strapi بدون فقدان عقلك
- مقاييس الأداء والأرقام الحقيقية
- عندما لا تكون هذه المجموعة هي الخيار الصحيح
- الأسئلة الشائعة
مرحلة شهر العسل: لماذا يعمل Strapi في البداية
دعنا نعطي الفضل حيث يستحق. Strapi لديه 65 ألف نجمة على GitHub لسبب وجيه. عندما تقوم بتشغيل مشروع جديد يعتمد على المحتوى، يكون محرر نوع المحتوى مفيداً حقاً. تنقر حول واجهة رسومية، وتحدد بعض الحقول، وبoom -- لديك بالفعل REST و GraphQL APIs. يمكن لمحرري المحتوى غير التقنيين تسجيل الدخول إلى لوحة الإدارة والبدء في النشر خلال ساعة.
بالنسبة للشركات الناشئة في المراحل المبكرة، والمواقع التسويقية، والمدونات، فإن Strapi خيار معقول تماماً. يدعم PostgreSQL و MySQL و MariaDB و SQLite. سوق الإضافات يحتوي على أكثر من 100 ملحق مجتمعي. والإصدار المجتمعي مجاني بموجب رخصة MIT.
لقد أوصيت بـ Strapi عدة مرات. أنا هنا لأتحدث عن ما يأتي بعد ذلك، وليس لانتقاده.
ستة علامات على أنك تجاوزت Strapi
هذه هي الأنماط التي أراها بشكل متكرر. إذا كان ثلاثة أو أكثر من هذه الأشياء تنطبق عليك، فقد حان الوقت لبدء التخطيط للترحيل.
1. الترحيلات تجعلك عصبياً
ترقية v4 إلى v5 هي التي أفسدت الكثير من الفرق. وثق Strapi أكثر من 50 تغيير كسر. في الممارسة العملية، رأيت الترحيلات تستغرق أكثر من 40 ساعة من وقت المطور بالنسبة للمشاريع متوسطة التعقيد. هذا ليس ترقية إصدار صغيرة -- هذا إعادة كتابة لطبقة المحتوى الخاصة بك.
إذا كنت تتجنب الترقية الرئيسية التالية لأنك تعلم أنها ستفسد نصف المتحكمات المخصصة لديك، فقد تجاوزت الأداة.
2. المطورون يقاتلون الإطار
محرر نوع المحتوى في Strapi رائع للمستخدمين غير التقنيين. بالنسبة للمطورين الذين يعيشون في TypeScript ويريدون مخططات موجهة للكود، فهو اختناق. واجهة المستخدم الرسومية تنتج ملفات لا تُفترض أن تحررها. تبدو خطافات دورة الحياة مضافة. تم إضافة دعم TypeScript في وقت متأخر في v4 ولا يزال ليس أصلياً -- إنه أكثر من تفكير ثانٍ.
عندما يبدأ فريقك في بناء حلول بديلة للإطار بدلاً من بناء ميزات معه، فهذه إشارة واضحة.
3. الأداء تصبح مشكلة
عادة ما تتراوح بدايات Strapi الباردة من 500 ملي ثانية إلى 2000 ملي ثانية. تقع الكمون العالمي بين 200-500 ملي ثانية بدون تخزين مؤقت عدواني. بالنسبة لمدونة، هذا جيد. بالنسبة لمنصة التجارة الإلكترونية التي تخدم المستخدمين عبر مناطق متعددة، فهي ليست كذلك.
كان لدي عميل يشغل كتالوج منتجات متعدد اللغات على Strapi. بمجرد أن تجاوزوا حوالي 50,000 إدخال محتوى مع علاقات عميقة، بدأت أوقات استجابة API تتجاوز علامة ثانيتين. لم يصلح أي مقدار من الفهرسة هذا.
4. تحتاج إلى ميزات مقفلة خلف الطبقات المدفوعة
تخطيط Growth من Strapi يكلف 45 دولاراً شهرياً ويشمل 3 مقاعد (مقاعد إضافية بـ 15 دولاراً لكل مقعد). هذا يفتح ميزات الذكاء الاصطناعي والمعاينة المباشرة وسجل المحتوى. تسعير Enterprise مخصص.
المشكلة ليست السعر -- إنها المبدأ. الميزات مثل المعاينة المباشرة وإصدارات المحتوى تبدو أساسية لـ CMS في 2025. امتلاكها محجوباً خلف اشتراك على أداة مفتوحة المصدر يزعج فرق المطورين.
5. مكدسك تطور تجاوز بنية Strapi
إذا ذهبت بكل ما لديك على Next.js و Vercel و TypeScript، فإن Strapi يبدأ يشعر كملحق محرج. يعمل كخدمة منفصلة Node.js. هذا يعني نشرات منفصلة، مراقبة منفصلة، اهتمامات تحجيم منفصلة. فريق الواجهة الأمامية ينشر إلى Vercel في ثوان بينما يحتاج CMS الخاص بك إلى البنية الأساسية الخاصة به.
6. التوسعات المخصصة تشعر مثل الجراحة
هل تريد إضافة منطق حقل مشروط؟ كتل قابلة للتكرار مع التحقق من الصحة؟ مكونات لوحة إدارة مخصصة؟ في Strapi، كل من هذه ممكن لكن مؤلم. لوحة الإدارة هي تطبيق React، لكن توسيع نطاقها يعني التنقل في نظام توسيع ملكي لا يشعر وكأنه تطوير React عادي.

فهم خيارك: Payload مقابل Supabase مقابل البقاء
قبل أن نمضي قدماً، دعونا نكون واضحين حول ما هي هذه الأدوات بالفعل، لأنني أراها تختلط باستمرار.
| الأداة | ما هي بالفعل | الأفضل ل | ليس رائع ل |
|---|---|---|---|
| Strapi | نظام إدارة محتوى مفتوح المصدر بواجهة رسومية | محررو المحتوى، توليد API السريع | فرق موجهة للكود، تطبيقات عالية الأداء |
| Payload CMS | إطار عمل CMS موجه للكود يعمل داخل Next.js | مطورو TypeScript، تطبيقات محتوى مخصصة | مشغلون منفردون غير تقنيين |
| Supabase | منصة خلفية مفتوحة المصدر (قاعدة بيانات، مصادقة، تخزين، في الوقت الفعلي) | بيانات التطبيق، المصادقة، تخزين الملفات | سير عمل تحرير المحتوى |
| Directus | نظام إدارة محتوى بدون رأس موجه لـ SQL مع API مُنشأة تلقائياً | الفرق التي لديها قواعد بيانات موجودة | تكامل Next.js العميق |
| Sanity | نظام إدارة محتوى بدون رأس مُدار مع التعاون في الوقت الفعلي | فرق التحرير، المحتوى المنظم | ذاتي الاستضافة بوعي الميزانية |
Payload و Supabase ليسا منافسين -- إنهما متكاملان. يتولى Payload نمذجة المحتوى وواجهة المستخدم للإدارة واجهات برمجة تطبيقات المحتوى. يتولى Supabase استضافة قاعدة البيانات والمصادقة وتخزين الملفات والاشتراكات في الوقت الفعلي. معاً، يحلان محل Strapi والأكثر.
لماذا Payload CMS هي الخطوة الطبيعية التالية
Payload تحدث موجات جادة طوال 2025 والدخول إلى 2026. دعت MG Software ذلك "معطل السوق" لتكامل TypeScript/Next.js، وأعتقد أن هذا صحيح.
إليك الفرق المعماري الأساسي: Payload يعمل داخل تطبيق Next.js الخاص بك. ليس بجانبه. ليس كخدمة منفصلة. بداخله. يشارك CMS والواجهة الأمامية نفس النشر وأنواع TypeScript نفسها وعملية البناء نفسها.
تعريف المخطط الموجه للكود
بدلاً من النقر حول واجهة رسومية لإنشاء أنواع محتوى، تكتب TypeScript:
import { CollectionConfig } from 'payload';
export const Products: CollectionConfig = {
slug: 'products',
admin: {
useAsTitle: 'name',
defaultColumns: ['name', 'price', 'status'],
},
access: {
read: () => true,
create: ({ req: { user } }) => user?.role === 'admin',
},
fields: [
{
name: 'name',
type: 'text',
required: true,
},
{
name: 'price',
type: 'number',
min: 0,
},
{
name: 'description',
type: 'richText',
},
{
name: 'category',
type: 'relationship',
relationTo: 'categories',
hasMany: false,
},
{
name: 'variants',
type: 'array',
fields: [
{ name: 'sku', type: 'text', required: true },
{ name: 'color', type: 'select', options: ['red', 'blue', 'green'] },
{
name: 'stock',
type: 'number',
admin: {
condition: (data, siblingData) => siblingData?.sku !== undefined,
},
},
],
},
],
hooks: {
afterChange: [
async ({ doc, operation }) => {
if (operation === 'update' && doc.stock === 0) {
// Trigger restock notification
}
},
],
},
};
هذا نوع محتوى حقيقي مع منطق حقل مشروط، صفائف متداخلة، حقول العلاقة، التحكم في الوصول على أساس الدور، وخطافات دورة الحياة. كل هذا في ملف واحد. كل شيء آمن من حيث النوع. كل شيء مراقب بواسطة Git.
حاول القيام بذلك في Strapi بدون لمس ثلاثة ملفات مختلفة ونظام توسيع الإدارة.
ثلاث طبقات API
ينشئ Payload تلقائياً REST و GraphQL APIs من المخطط الخاص بك. لكن الميزة الرابحة هي Local API -- استعلامات قاعدة البيانات المباشرة من الكود جانب الخادم بدون كسر HTTP:
// Inside a Next.js Server Component
import { getPayload } from 'payload';
import config from '@payload-config';
export default async function ProductPage({ params }) {
const payload = await getPayload({ config });
const product = await payload.findByID({
collection: 'products',
id: params.id,
depth: 2, // Populate relationships 2 levels deep
});
return <ProductDetail product={product} />;
}
لا استدعاءات جلب. لا مسارات API. لا عبء تسلسلي. هذا هو السبب في أن Payload يحقق معيار بنحو 7 مرات أسرع من Strapi لاسترجاع المحتوى في الإعدادات القابلة للمقارنة.
حيث ينطبق Supabase (وأين لا ينطبق)
Supabase ليس CMS. أريد أن أكون واضح جداً حول ذلك. إنها منصة خلفية مبنية على PostgreSQL. لكنها تحل عدة مشاكل التي يتعامل معها Strapi بشكل سيء و Payload لا يتعامل معها على الإطلاق.
ما يجلبه Supabase إلى المجموعة
- PostgreSQL المُدار: محول PostgreSQL من Payload يتصل مباشرة بقاعدة بيانات Supabase. تحصل على دمج الاتصالات والنسخ الاحتياطية التلقائية ولوحة معلومات لاستعلامات SQL المباشرة. تبدأ خطة Pro بـ 25 دولاراً شهرياً وتتسع مع الاستخدام.
- المصادقة: Supabase Auth يدعم البريد الإلكتروني/كلمة المرور والروابط السحرية وموفري OAuth وأمان على مستوى الصف. إذا كان تطبيقك يحتوي على ميزات تتجاوز لوحة الإدارة الخاصة بـ CMS، فهذا ضخم.
- تخزين الملفات: تخزين الكائنات المتوافق مع S3 مع CDN. يمكن لـ Payload التعامل مع تحميلات الوسائط، لكن Supabase Storage يتعامل مع ملفات التطبيق وتحميلات المستخدم وأي شيء خارج سياق CMS.
- اشتراكات في الوقت الفعلي: PostgreSQL's LISTEN/NOTIFY مغلفة في API WebSocket نظيفة. أقرن هذا بـ Payload's live preview للحصول على تجارب تحرير محتوى في الوقت الفعلي.
- وظائف Edge: وظائف serverless مستندة إلى Deno لمعالجات webhook والمهام الخلفية والتكاملات.
ما Supabase لا تفعله
لا تعطيك لوحة إدارة لمحرري المحتوى. لا تنشئ واجهات برمجة تطبيقات للمحتوى مع حقول نصية غنية وإدارة الوسائط. لا تتعامل مع تحديد موقع المحتوى أو إصدار السجل. هذا عمل Payload.
مجموعة Payload + Supabase: غوص معماري عميق
إليك كيفية قمت بإعداد هذا للفرق التي تهاجر من Strapi. هذه هي العمارة التي نوصي بها عادة للمشاريع التي يكون فيها إدارة المحتوى متطلباً أساسياً.
بنية المشروع
├── src/
│ ├── app/ # Next.js App Router
│ │ ├── (frontend)/ # Public-facing pages
│ │ └── (payload)/ # CMS admin routes (auto-generated)
│ ├── collections/ # Payload collection configs
│ │ ├── Posts.ts
│ │ ├── Products.ts
│ │ └── Users.ts
│ ├── globals/ # Payload global configs
│ │ └── SiteSettings.ts
│ ├── lib/
│ │ └── supabase.ts # Supabase client initialization
│ └── payload.config.ts # Main Payload config
├── supabase/
│ └── migrations/ # Supabase DB migrations
├── .env.local
└── package.json
توصيل Payload بـ PostgreSQL Supabase
// payload.config.ts
import { buildConfig } from 'payload';
import { postgresAdapter } from '@payloadcms/db-postgres';
import { lexicalEditor } from '@payloadcms/richtext-lexical';
import { Posts } from './collections/Posts';
import { Products } from './collections/Products';
export default buildConfig({
db: postgresAdapter({
pool: {
connectionString: process.env.SUPABASE_DB_URL,
// Use Supabase's connection pooler for serverless
max: 10,
},
}),
editor: lexicalEditor(),
collections: [Posts, Products],
secret: process.env.PAYLOAD_SECRET,
typescript: {
outputFile: path.resolve(__dirname, 'payload-types.ts'),
},
});
ملاحظة مهمة: استخدم عنوان URL دمج الاتصالات من Supabase (المنفذ 6543)، وليس عنوان URL الاتصال المباشر، عند النشر في بيئات بدون خادم مثل Vercel. الاتصالات المباشرة تعمل بشكل جيد للتطوير المحلي.
إضافة Supabase Auth لمستخدمي التطبيقات
يتعامل Payload مع مصادقة مسؤول CMS. Supabase يتعامل مع كل شيء آخر:
// lib/supabase.ts
import { createClient } from '@supabase/supabase-js';
export const supabase = createClient(
process.env.NEXT_PUBLIC_SUPABASE_URL!,
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
);
// In a Server Component or API route
import { createServerClient } from '@supabase/ssr';
import { cookies } from 'next/headers';
export async function getServerSupabase() {
const cookieStore = await cookies();
return createServerClient(
process.env.NEXT_PUBLIC_SUPABASE_URL!,
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
{
cookies: {
getAll() {
return cookieStore.getAll();
},
setAll(cookiesToSet) {
cookiesToSet.forEach(({ name, value, options }) =>
cookieStore.set(name, value, options)
);
},
},
}
);
}
هذا الفصل نظيف: يمتلك Payload المحتوى. Supabase يمتلك بيانات التطبيق وهوية المستخدم. يشاركان نفس مثيل PostgreSQL لكنهما يبقيان في مجالاتهما الخاصة.
استراتيجية الترحيل: الابتعاد عن Strapi بدون فقدان عقلك
لن أخفف على هذا -- الترحيل يستغرق عملاً. لكنه أقل ألماً بكثير من ترقية Strapi v4-to-v5، لأنك تنتقل إلى نظام يحترم نماذجك العقلية الموجودة.
نهج خطوة بخطوة
- تدقيق أنواع محتوى Strapi الخاصة بك. قم بتصديرها كـ JSON من محرر نوع المحتوى. خريطة كل منها لـ Payload collection config.
- قم بإعداد Payload في مشروع Next.js جديد. قم بتشغيل
npx create-payload-app@latestواختر محول PostgreSQL. - أشير Payload إلى قاعدة بيانات Supabase الخاصة بك. أنشئ مشروع Supabase جديد، احصل على سلسلة الاتصال، قم بتكوين المحول.
- أعد إنشاء الأنماط في TypeScript. هذا هو الجزء الأكبر من العمل. يصبح كل نوع محتوى Strapi مجموعة Payload. الحقول تنخفض تقريباً 1:1 -- نص، رقم، richtext، علاقة، وسائط.
- قم بتصدير البيانات من Strapi. استخدم
pg_dumpإذا كنت على PostgreSQL، أو اكتب نصاً ضد Strapi REST API لسحب جميع المحتوى. - استيراد في Payload. استخدم Local API من Payload في سكريبت بذرة لإنشاء محتوى بكميات كبيرة.
- قم بتحديث الواجهة الأمامية الخاصة بك. استبدل استدعاءات Strapi API باستدعاءات Payload Local API (في Server Components) أو استدعاءات REST/GraphQL (في مكونات العميل).
- قم بالنشر. نظراً لأن Payload يعمل داخل Next.js، تقوم بنشر تطبيق واحد بدلاً من اثنين.
بالنسبة للترحيلات المعقدة، يمكن لفريق تطوير CMS بدون رأس مساعدتك في التخطيط للانتقال. لقد فعلنا هذا كثيراً بما يكفي لمعرفة أين تكمن الألغام الأرضية.
مقاييس الأداء والأرقام الحقيقية
إليك الأرقام التي تهم، التي تم جمعها من المقاييس المنشورة واختبارنا الخاص في 2025:
| المقياس | Strapi v5 | Payload 3.x | Payload + Supabase |
|---|---|---|---|
| وقت البداية الباردة | 500-2000ms | 100-300ms | 150-350ms |
| استعلام بسيط (عنصر واحد) | 45-80ms | 8-15ms | 10-20ms |
| استعلام معقد (مملوء، 3 مستويات) | 200-500ms | 30-80ms | 40-100ms |
| تحميل لوحة الإدارة | 2-4s | 1-2s | 1-2s |
| وقت الإنشاء (500 صفحة، ISR) | N/A (منفصل) | 45-90s | 50-100s |
| الكمون العالمي (بدون CDN) | 200-500ms | 50-150ms | 60-160ms |
يضيف دمج اتصالات Supabase كسراً صغيراً مقارنة بالاتصال المباشر بـ PostgreSQL، عادة 5-15ms. هذا مهملة في الممارسة.
تحذير واحد: استعلامات حقول Payload المأهولة بالسكان (دقة العلاقة العميقة) تم وضع علامة عليها بأنها أبطأ من استعلامات قاعدة البيانات الخام -- تقريباً 15 مرة أبطأ من استدعاءات Mongoose/Drizzle المباشرة وفقاً لمسألة GitHub #11325. بالنسبة للصفحات الثقيلة في القراءة، أوصي باستخدام ISR في Next.js أو تخزين مؤقت للنتائج المأهولة بدلاً من ضرب قاعدة البيانات في كل طلب.
عندما لا تكون هذه المجموعة هي الخيار الصحيح
كنت أفعل لك جميلاً إذا لم أذكر السيناريوهات التي تكون فيها Payload + Supabase مبالغة أو ببساطة خاطئة.
- فريقك لا يكتب TypeScript. Payload موجه للكود. إذا كان فريق المحتوى يدير كل شيء ولا تملك مطورين يحافظون على CMS، فإن واجهة Strapi الرسومية أفضل بكثير. أو انظر إلى Sanity أو Contentful.
- تحتاج إلى نظام إضافات ضخم اليوم. نظام Payload للإضافات ينمو لكنه أصغر من Strapi's 100+ توسيع. إذا كنت بحاجة إلى تكامل محدد موجود كإضافة Strapi لكن ليس بـ Payload، فاحسب وقت البناء.
- تقوم بإنشاء مدونة بسيطة أو موقع تسويقي. Strapi يعمل بشكل جيد لهذا. كذلك Astro مع CMS بدون رأس. لا تفرط في الهندسة.
- تحتاج إلى أداء أول Edge. إذا كان الكمون العالمي أقل من 50 ملي ثانية متطلباً صعباً، فانظر إلى SonicJS على Cloudflare Workers. Payload يعمل على Node.js -- إنه سريع، لكنه ليس أول edge.
هل تريد الحديث من خلال ما إذا كان هذا الترحيل منطقياً لمشروعك المحدد؟ تواصل معنا -- سنعطيك تقييماً صريحاً، وليس درساً بيعياً.
الأسئلة الشائعة
هل Payload CMS مجاني حقاً؟ نعم. Payload مرخص تحت MIT مجاني لاستضافة ذاتية بدون قيود ميزات. هناك خدمة استضافة Payload Cloud اختيارية للفرق التي لا تريد إدارة البنية الأساسية، لكن جميع ميزات CMS -- المعاينة المباشرة والتحكم في الوصول والتوطين والإصدار -- متاحة في الإصدار مفتوح المصدر. قارن ذلك مع Strapi، الذي يبوب المعاينة المباشرة وسجل المحتوى خلف خطة Growth بـ 45 دولاراً شهرياً.
هل يمكنني استخدام Supabase كـ CMS بنفسي؟ من الناحية التقنية، يمكنك بناء واجهة إدارة محتوى على Supabase باستخدام أجهزة الخادم الموليدة التلقائياً والأمان على مستوى الصف. لكنك ستعيد بناء ما يعطيك Payload خارج الصندوق: لوحة إدارة، تحرير نص غني، إدارة الوسائط، إصدار المحتوى، والتحكم في الوصول. Supabase منصة خلفية، وليس CMS. استخدمه في ما هو جيد -- استضافة قاعدة البيانات والمصادقة والتخزين -- واترك Payload يتعامل مع طبقة المحتوى.
كم يستغرق الترحيل من Strapi إلى Payload؟ بالنسبة لمشروع نموذجي يحتوي على 10-20 نوع محتوى وبضع آلاف إدخالات، توقع 2-4 أسابيع من وقت المطور. إعادة إنشاء المخطط هي الجزء الأكبر -- ترجمة أنواع محتوى Strapi إلى Payload TypeScript configs. عادة ما تكون هجرة البيانات يومًا أو يومين مع نص جيد. تحديثات الواجهة الأمامية تعتمد على مدى ارتباط الكود الخاص بك بتنسيق استجابة Strapi API. الفرق التي استخدمت طبقة الوصول إلى البيانات أو التجريد ستواجه وقتاً أسهل.
هل Payload يعمل مع قواعد البيانات بخلاف PostgreSQL؟ Payload يدعم MongoDB و PostgreSQL من خلال محولات قاعدة بيانات رسمية. بالنسبة لمجموعة Supabase الموصوفة في هذه المقالة، ستستخدم محول PostgreSQL. إذا كنت تأتي من خلفية MongoDB، فإن محول Payload's MongoDB في الواقع أكثر نضجاً منذ كان MongoDB هو قاعدة البيانات الأصلية لـ Payload. كلاهما جاهز للإنتاج في 2025.
ماذا عن Directus كبديل لـ Strapi؟ Directus خيار قوي، خاصة إذا كان لديك قاعدة بيانات SQL موجودة تريد فضحها من خلال واجهة CMS. ينشئ تلقائياً لوحة إدارة وAPI من مخطط قاعدة البيانات، وهو أمر ذكي. العيب الرئيسي مقارنة بـ Payload هو الافتقار إلى تكامل Next.js العميق -- يعمل Directus كخدمة منفصلة، تماماً مثل Strapi. إذا لم يكن فريقك على مجموعة Next.js/Vercel، فإن Directus يستحق الاعتبار الجاد.
هل يمكنني نشر Payload + Supabase على Vercel؟ بالتأكيد -- هذا هو في الواقع الهدف المثالي للنشر. نظراً لأن Payload يعمل داخل تطبيق Next.js، فإن النشر على Vercel بسيط مثل الدفع إلى GitHub repo الخاص بك. يعمل Supabase كخدمة مُدارة، لذلك لا يوجد شيء لنشره على هذا الجانب. البنية الأساسية الكاملة الخاصة بك تصبح: Vercel للحوسبة و CDN و Supabase لقاعدة البيانات والمصادقة. خدمتان، خط أنابيب نشر واحد.
هل واجهة المستخدم الإدارية Payload قابلة للتخصيص؟ جداً. تم إنشاء واجهة المستخدم الإدارية مع React وتدعم مكونات مخصصة وطرق عرض مخصصة وحقول مخصصة. يمكنك إضافة عناصر واجهة لوحة المعلومات وإنشاء عناصر ملاحة مخصصة والكتابة فوق أي عنصر واجهة مستخدم افتراضي. منذ Payload 3.x، يستخدم تخصيص الإدارة React Server Components، مما يعني أن كود الإدارة المخصص الخاص بك يمكن أن يجلب البيانات من جانب الخادم بدون استدعاءات API. هذا عالم مختلف عن نظام توسيع لوحة Strapi الإدارية، الذي يتطلب الهروب والتصحيح.
كم تكلف هذا المجموعة للتشغيل في الإنتاج؟ بالنسبة للمشروع الصغير إلى المتوسط: Vercel Pro في 20 دولاراً شهرياً + Supabase Pro في 25 دولاراً شهرياً = 45 دولاراً شهرياً إجمالاً. يمنحك هذا الحوسبة بدون خادم و PostgreSQL مدارة بسعة تخزين 8GB و 250MB من تخزين الملفات و 50,000 مستخدم نشط شهري للمصادقة والنسخ الاحتياطية التلقائية. يتسع من هناك حسب الحاجة. قارن ذلك باستضافة Strapi على VPS (20-50 دولاراً شهرياً) بالإضافة إلى إدارة قاعدة البيانات الخاصة بك، أو خطة Strapi Cloud Growth في 45 دولاراً شهرياً مع مقاعد محدودة. مجموعة Payload + Supabase منافسة من حيث التكلفة وأسهل بكثير للتشغيل.