توافق PostgREST: ما يغطيه والبدائل

PostgREST هو خادم ويب مستقل يقوم بتحويل قاعدة بيانات PostgreSQL موجودة إلى REST API، مباشرة من مخططها. لا توجد طبقة تطبيق للكتابة: تصبح الجداول وطرق العرض والوظائف مسارات، وتصبح أذونات SQL - الأدوار وسياسات RLS - طبقة التفويض.

بشكل ملموس، يغطي PostgREST خمس إمكانيات تظهر في جميع التقييمات تقريبًا:

• التصفية الأفقية — حوالي ثلاثين عامل تشغيل (eq, gt, like, ilike, in, is, cs, ov, fts...) مباشرة في سلسلة الاستعلام.
• التصفية العمودية والتضمين — ?select= تعرض الأعمدة وتضمين العلاقات عبر المفتاح الخارجي، على سبيل المثال customer:customers(email).
• RPC — يستدعي POST /rpc/{fonction} مباشرة وظيفة SQL، والتي تصبح نقطة نهاية.
• RLS مدفوعة بـ JWT - يقوم PostgREST بتبديل دور Postgres النشط وفقًا للرمز المميز المستلم (SET LOCAL ROLE)، بحيث يتم تطبيق سياساتك كما هي، بدون منطق تفويض مكرر من جانب التطبيق.
• واجهة OpenAPI ذاتية الإنشاء — يتم استخلاص المواصفات من المخطط المكشوف، بدون ملف للمحافظة عليه يدويًا.

curl "https://<gateway>/v1/db/<project_id>/orders \
  ?select=id,total,customer:customers(email) \
  &status=eq.paid \
  &order=created_at.desc" \
  -H "apikey: <votre-cle-api>"

يقوم طلب HTTP واحد بتصفية الطلبات المدفوعة، وتضمين البريد الإلكتروني للعميل عبر مفتاح خارجي، والفرز حسب التاريخ - دون الحاجة إلى كتابة مسار واحد يدويًا.

يتبع RPC نفس المنطق: تصبح وظيفة SQL المكتوبة بالفعل في قاعدة البيانات الخاصة بك نقطة نهاية POST، مع تمرير وسيطاتها في JSON.

curl -X POST "https://<gateway>/v1/db/<project_id>/rpc/monthly_revenue" \
  -H "apikey: <votre-cle-api>" \
  -H "Content-Type: application/json" \
  -d '{"year": 2026, "month": 8}'

هذا المبدأ — مخطط Postgres هو المصدر الوحيد للحقيقة لواجهة برمجة التطبيقات — هو ما يجعل PostgREST قابلاً للتنبؤ به: كل تغيير في السلوك يمر عبر ترحيل SQL، وليس عبر طبقة تطبيق منفصلة يمكن اشتقاقها من المخطط الفعلي. المشروع مفتوح المصدر، وتم تطويره على GitHub، بشكل مستقل عن أي مزود BaaS معين.

يقوم PostgREST بحل طبقة CRUD. ولا يحل بقية الواجهة الخلفية للتطبيق. تحدث أربعة عيوب بشكل منهجي بين الفرق التي تعتمده بمفردها.

• المصادقة — لا يوجد إصدار JWT أو إدارة متكاملة للمستخدم. يجب عليك إنشائه في SQL أو تفويضه إلى خدمة خارجية.
• تخزين الملفات - لا شيء. يبقى أن يتم توصيل حاوية S3 أو ما يعادلها بشكل منفصل.
• الوقت الفعلي — يستجيب PostgREST لطلبات HTTP لمرة واحدة، ولا يدفع أي أحداث.
• مجمع الاتصال — يتصل PostgREST نفسه بـ Postgres، لكنه لا يدمج أي مجمعات متقدمة. على نطاق واسع، تصبح إدارتها قرارًا تشغيليًا في حد ذاتها: يتعارض المجمع في وضع المعاملة الكلاسيكية مع آلية إعادة تحميل مخطط PostgREST (انظر أدناه كيف تحل Aurabase هذا الحل الوسط).

تستحق النتيجة العملية أن يتم ذكرها بوضوح: بدون المصادقة، تصبح سياسات RLS الخاصة بك هي الحدود الأمنية الوحيدة بين العميل المجهول وبياناتك. السياسة المكتوبة بشكل سيئ على الدور anon لا يتم تجاوزها بواسطة طبقة تطبيق إضافية - لا يوجد شيء.

في مشروع محرك Aurabase Postgres - المحرك الافتراضي - تقوم البوابة بتوجيه كل طلب CRUD مباشرة إلى مثيل PostgREST v12.2.8 المخصص لهذا المشروع، نسختين متماثلتين، في موقع مشترك مع مجموعة Postgres الخاصة بالمستأجر. هذا ليس توافقًا تقريبيًا: إنه ثنائي PostgREST نفسه، مع نفس المشغلين، ونفس التضمين، ونفس RPC، ونفس RLS الذي يحركه JWT.

في مشروع محرك MongoDB، القصة مختلفة. ليس لدى MongoDB ما يعادل PostgREST: يتم توجيه هذه الطلبات إلى خدمة Aurabase داخلية، والتي تعيد تنفيذ مجموعة فرعية من نفس الاصطلاحات - أسماء مشغلين متطابقة، وبناء جملة ?select= مع التضمين، ورؤوس Prefer وContent-Range - ولكن على محرك مستند، وليس محركًا علائقيًا. هذه الطبقة لها حدودها الخاصة: يتم رفض التضمين المطلوب في التمثيل الذي يتم إرجاعه بواسطة طفرة بشكل صريح بدلاً من تجاهله بصمت، ولا يوجد مسار RPC مكافئ لوظائف SQL.

تتناقض التفاصيل الفنية مع الحدس: تظل كل نسخة PostgREST مخصصة متصلة مباشرة بـ Postgres الأساسي، دون المرور عبر مجمع PgBouncer المنشور لهذا المستأجر. السبب المفترض: قد يؤدي وضع تجميع المعاملات إلى تعطيل إعادة تحميل مخطط PostgREST، الذي يعتمد على LISTEN/NOTIFY - اتصال مستمر، غير متوافق مع التجمع الذي يعيد تدوير الاتصال لكل معاملة.

تفصيل آخر مفيد في الإنتاج: يمكن إيقاف المشروع غير النشط مؤقتًا لتوفير الموارد. يؤدي الطلب الأول في مشروع نائم إلى تنبيهه ويتلقى 503 مع تأخير إعادة المحاولة، وهو الوقت المناسب لمثيل PostgREST المخصص للعودة - وهو حل وسط مفترض بين التكلفة وزمن الوصول البارد، وليس حادثًا مخفيًا.

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

يقارن الجدول أدناه ما يغطيه كل خيار محليًا وما يتركه لك بشكل صريح - دون الحكم على القيمة على البنية التي اختارها كل مشروع.

هناك نقطة غالبًا ما يتم الاستهانة بها عند اختيار "الاستضافة الذاتية": يظل PostgREST نفسه خفيفًا للتشغيل، ولكن عملية الإنتاج (تحديث الإصدار، والتوفر العالي، والارتباط مع المجمع، والمراقبة) تظل مسؤوليتك بالكامل - إن هذه العملية، وليس البرنامج، هي التي تمتصها الأنظمة الأساسية المُدارة.

للحصول على مقارنة تفصيلية بين أساليب GraphQL - pg_graphql وHasura وPostGraphile - راجع مقالتنا المخصصة لواجهة برمجة تطبيقات GraphQL على Postgres.

أربع حالات تظهر في أغلب الأحيان. يعتمد الاختيار الصحيح بشكل أساسي على ما ترغب في تجميعه وصيانته بنفسك.

• أنت فقط تريد واجهة برمجة تطبيقات REST بدلاً من مخطط Postgres الحالي، ولا شيء آخر. يعد PostgREST المستضاف ذاتيًا كافيًا: فهو يفعل بالضبط ما يفعله، ولا يلزم تثبيت أي شيء آخر.
• أنت بحاجة إلى مصادقة إضافية وتخزين ووقت حقيقي، وأنت جاهز لتجميع العديد من الخدمات. يلبي Supabase أو PostgREST المصحوب بمكدس التطبيقات الخاص بك هذه الحاجة.
• أنت تفضل GraphQL على REST. يغطي Hasura أو PostGraphile هذه الأرضية - وهو خيار معماري مختلف، وليس بديلاً مباشرًا لـ PostgREST.
• أنت تريد واجهة Postgres خلفية كاملة دون تجميع عدة خدمات منفصلة معًا. هذه هي الزاوية التي مستندات الموحدة لبنية الصدأ: PostgREST الحقيقي لطبقة CRUD، محاطة أصلاً بوظائف المصادقة والتخزين والوقت الفعلي والحافة.