PostgREST مقابل Hasura مقابل واجهة برمجة التطبيقات المخصصة

يخفي السؤال "PostgREST أو Hasura أو واجهة برمجة التطبيقات المخصصة" سؤالًا أكثر فائدة: من يكتب منطق عملك، وبأي أداة، ومن يستخدم هذا الرمز في الإنتاج؟ تستجيب البنى الثلاثة بشكل مختلف، وهذا الاختلاف يشكل كل شيء آخر – الأمان، وسرعة التنفيذ، والدين الفني على المدى الطويل.

لا يوجد أي من الأعمدة الثلاثة أفضل بشكل صارم: فكل منها ينقل العمل إلى مكان آخر. يقوم PostgREST بنقله إلى SQL، وHasura إلى التكوين وخطافات الويب، وواجهة برمجة التطبيقات المخصصة إلى كود التطبيق الكلاسيكي.

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

ليس لدى PostgREST أي فكرة عن منطق العمل التعسفي. يجب التعبير عن كل قاعدة في SQL: وظيفة RPC، ومشغل، وقيد، وسياسة RLS. يعد هذا قيدًا مقبولاً، وليس سهوًا - يظل المخطط هو المصدر الوحيد للحقيقة، مما يزيل أي انحراف بين طبقة التطبيق والقاعدة التي تخدمها.

بشكل ملموس، من المستحيل الاتصال بخدمة دفع تابعة لجهة خارجية، أو إرسال رسالة تأكيد بالبريد الإلكتروني، أو حساب النتيجة في JavaScript من طلب PostgREST المباشر. يجب أن يكون هذا المنطق إما موجودًا في SQL (وظيفة pl/pgsql)، أو يتم تشغيله خارجًا - مشغل ينشر حدث NOTIFY، يتم الاستماع إليه بواسطة خدمة خارجية لم تعد PostgREST.

مقالتنا عن طبقات GraphQL على Postgres توضح تفاصيل مكان تشغيل محرك Hasura وكيف تختلف أذوناته عن Postgres RLS. الزاوية هنا هي زاوية منطق الأعمال: كيفية توصيل تعليمات برمجية مخصصة بقاعدة بيانات تديرها Hasura، وأين.

يكشف الإجراء Hasura عن طفرة أو استعلام GraphQL مخصص، مدعومًا بخطاف ويب HTTP تكتبه باللغة التي تختارها. تقوم Hasura بالتحقق من صحة المدخلات وفقًا للمخطط المعلن، واستدعاء خطاف الويب الخاص بك، ثم إرجاع استجابتها إلى العميل. إنها البوابة إلى أي منطق يتجاوز CRUD: الاتصال بمزود الدفع، والحسابات المعقدة، والتنسيق متعدد الخطوات.

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

يمكن لـ Hasura أيضًا عرض استعلام GraphQL مكتوب بالفعل كمسار REST نموذجي، مع مسار مسمى ومعلمات - نقاط النهاية RESTifiedالخاصة به، في مصطلحات الوثائق الخاصة به. مفيد إذا كان فريق الواجهة الأمامية لديك يفضل استخدام REST، دون التخلي عن محرك أذونات GraphQL الأساسي.

تذكير بالسياق، تم تطويره في مقالتنا المخصصة: أعادت Hasura تركيز اتصالاتها على PromptQL، وهي طبقة مصممة لعملاء الذكاء الاصطناعي، منذ يونيو 2025 - دون إزالة محرك GraphQL الخاص بها، والذي لا يزال يتم تقديمه على أنه "تم اختباره في المعركة" على موقعها الرسمي على الويب.

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

// تتم كتابة عوامل التصفية والفرز وتضمين العلاقات يدويًا،
// لهذا المسار وحده — كرر ذلك لكل مورد من موارد واجهة برمجة التطبيقات
router.get('/orders', async (req, res) => {
  const { status } = req.query
  const result = await db.query(
    `SELECT o.id, o.total, c.email AS customer_email
     FROM orders o JOIN customers c ON c.id = o.customer_id
     WHERE o.status = $1 ORDER BY o.created_at DESC`,
    [status]
  );
  res.json(result.rows)
});

ما يقدمه هذا النموذج، مقابل العمل اليدوي: التحكم الكامل في الأخطاء ورموز HTTP التي تم إرجاعها، وقابلية الاختبار الكلاسيكية (المعالجات، وليس التكوين التعريفي)، وعدم وجود DSL جديد للتعلم لفريق يتقن لغته بالفعل.

ما هي التكلفة في المقابل: CRUD، وترقيم الصفحات والمرشحات للكتابة والصيانة يدويًا لكل مورد؛ المصادقة والترخيص للتنفيذ والتدقيق بنفسك، دون RLS الموروثة تلقائيًا؛ خطر استعلامات N+1 إذا قامت كل علاقة متداخلة بتشغيل استعلام Postgres الخاص بها دون انضباط؛ ووثائق واجهة برمجة التطبيقات (API) التي يجب صيانتها يدويًا، أو عبر مولد تابع لجهة خارجية للتكامل.

On raw performance, the question “Is Node.js slower than Rust” is a topic in its own right — our article on Rust vs Node.js latency covers it in detail, with methodology declared upstream on our benchmark methodology page. A custom API has the same performance profile as any HTTP service you already use, neither better nor worse by construction. To know precisely where PostgREST saturates and at what point a custom layer becomes necessary, see our article on the real limits of PostgREST in production.

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

في مشروع محرك Aurabase Postgres، تمت تغطية طبقة CRUD بالفعل بواسطة مثيل PostgREST الفعلي، وليس إعادة تنفيذ تقريبية. السؤال الذي يبقى مفتوحا أمام هذه المقارنة: أين نكتب ما يتجاوز CRUD؟

هناك طريقان، ولا ينفي أحدهما الآخر. الأول: عرض دالة SQL في RPC، لأي منطق يظل من المعقول التعبير عنه في SQL - حساب إجمالي، والتحقق المتبادل بين عدة جداول، والتحديثات المتتالية في معاملة واحدة.

curl -X POST "https://<gateway>/v1/db/<project_id>/rpc/apply_discount" \
  -H "apikey: <votre-cle-api>" \
  -H "Content-Type: application/json" \
  -d '{"order_id": 42, "code": "WELCOME10"}'

الطريقة الثانية: وظائف الحافة، لكل ما يتجاوز مجال SQL - استدعاء واجهة برمجة تطبيقات الدفع، وإرسال بريد إلكتروني، وحساب التضمين. هناك مساران يؤديان إلى هناك في Aurabase: محرر الاستوديو، الذي يقوم بتشغيل كود Deno (TypeScript) تمامًا كما هو الحال في Supabase، وaura functions deployCLI، الذي يهدف إلى إنشاء مسار منفصل للوظائف المكتوبة بلغة Rust والمجمعة في WASM - المفصلة في بنية Rust الموحدة . لا يتطلب أي من المسارين استضافة خادم Node منفصل، على عكس خيار "واجهة برمجة التطبيقات المخصصة" النقي في هذه المقالة، حيث يكون هذا الخادم مسؤوليتك بالكامل.

لا يمثل هذا التوزيع حلاً وسطًا هشًا بين النماذج الثلاثة التي تمت مقارنتها هنا: فهو حرفيًا PostgREST لـ CRUD، وهو لبنة قريبة من Hasura Actions لمنطق الحدث عبر RPC والمشغلات، وEdge Functions التي تتجنب تشغيل خادم تطبيق كامل - دون فرض خيار ثنائي بين "All PostgREST" و"All Custom".

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

• مخططك مستقر ومنطق عملك موجود في SQL. يكفي PostgREST المستضاف ذاتيًا، أو المدمج أصلاً (Aurabase، Supabase): لا شيء أكثر للاستضافة، ويظل المخطط هو المصدر الوحيد للحقيقة.
• إذا كنت ترغب في جمع عدة مصادر بيانات، أو أن خريطة الطريق الخاصة بك موجهة نحو عملاء الذكاء الاصطناعي الذين يستهلكون بياناتك. Hasura، بطبقة PromptQL، تناسب هذه التضاريس بشكل أفضل.
• يتمتع منتجك بمنطق عمل غني، والعديد من عمليات تكامل الجهات الخارجية، وفريق مجهز بالفعل بلغة تطبيق. تظل واجهة برمجة التطبيقات المخصصة هي الخيار الأكثر مباشرة، على حساب كتابتها وصيانتها بمرور الوقت.
• أنت تريد إنشاء CRUD ذاتيًا دون التخلي عن مساحة حقيقية لمنطق الأعمال (RPC، ووظائف الحافة)، دون تكديس خدمة تطبيق أخرى لاستغلالها. هذه هي الزاوية الموثقة في هذه المقارنة المطبقة على Aurabase، القسم السابق.