معالجة منطق الأعمال المعقد باستخدام PostgREST بدون خادم خلفي (Backend)

لقد تجاوز PostgreSQL الآن كونه مجرد مخزن بيانات بسيط. ليس من قبيل الصدفة أن يحتل المرتبة الأولى في استطلاع Stack Overflow لعام 2025، متفوقاً على MySQL بفارق 15 نقطة مئوية. عند وضع PostgREST فوق قاعدة البيانات القوية هذه، لن تحتاج إلى كتابة واجهات برمجة تطبيقات CRUD مملة باستخدام Node.js أو Python. ومع ذلك، يتردد الكثيرون عندما يتعلق الأمر بدمج المدفوعات أو إعدادات الأذونات المعقدة، متسائلين: "هل يمكن حقاً القيام بذلك بدون خادم؟". الإجابة المختصرة هي نعم، وبطريقة أنيقة للغاية.

حل تأخير الاستجابة الناتج عن التكامل مع واجهات برمجة التطبيقات الخارجية

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

تتجلى قوة هذا الأسلوب عند الربط مع واجهات دفع مثل Toss Payments. تكتفي المعاملة (Transaction) الرئيسية بحفظ البيانات وتنتهي فوراً، بينما تتم معالجة استدعاء واجهة برمجة التطبيقات الفعلي في طابور خلفي (Background Queue). بهذه الطريقة، يمكنك الحفاظ على سرعة استجابة واجهة برمجة التطبيقات في أقل من 200ms بغض النظر عن حالة الخادم الخارجي. عندما ترى إنتاجية النظام تزداد بأكثر من 3 أضعاف، ستتساءل لماذا عانيت كل ذلك الوقت مع خوادم API.

نقل منطق التحقق من الصحة إلى قيود قاعدة البيانات (DB Constraints)

غالباً ما يتم حل المنطق المعقد مثل التحقق من المخزون ومعالجة الطلبات باستخدام جمل if-else في كود الخلفية. ولكن هذه هي بداية تلوث البيانات. بدلاً من ذلك، جرب استخدام pg_jsonschema. هذه التوسعة المكتوبة بلغة Rust تنهي مطابقة أنماط JSON لـ 100,000 سجل في غضون 48ms فقط.

الطريقة واضحة: ضع قيود CHECK على الجداول أو أنشئ مشغلات (Triggers) من نوع BEFORE INSERT. إذا لم تتحقق الشروط، قم بإلقاء خطأ باستخدام RAISE EXCEPTION. في هذه الحالة، إذا حددت SQLSTATE كـ PT402 ، فإن PostgREST سيتولى إرسال رمز 402 Payment Required إلى العميل تلقائياً. وفر الخمس ساعات التي كنت تضيعها في كتابة كود التحقق في الخلفية واستثمرها في نمذجة بيانات أكثر أهمية.

تقليل تكاليف البنية التحتية من خلال تحليل الاستعلامات (Profiling)

في PostgREST، تتحول معاملات URL الخاصة بالعميل مباشرة إلى استعلامات. هذا مريح ولكنه خطير. فالتصفية (Filtering) بناءً على أعمدة غير مفهرسة تفتح أبواب جحيم الأداء فوراً. هنا تصبح pg_stat_statements ضرورية، لأنها تظهر لك في الوقت الفعلي أي الاستعلامات تستهلك الموارد.

في الواقع، مجرد فحص خطة التنفيذ باستخدام أمر EXPLAIN (ANALYZE, BUFFERS) وتحويل المسح المتسلسل (Sequential Scan) إلى مسح بالفهرس (Index Scan) يحسن الأداء بأكثر من 3 أضعاف. وتقليل تكاليف السحابة بنسبة 30% هو مكافأة إضافية. إذا كانت هناك حاجة لحسابات معقدة، فإن وضع فهارس على الأعمدة المولدة افتراضياً (Virtual Generated Columns) في PostgreSQL 18 يعد خياراً ممتازاً أيضاً.

التحكم الديناميكي في الوصول بناءً على مستوى المستخدم

توقف عن تكديس البرمجيات الوسيطة (Middleware) في الخلفية من أجل الأمان. يستفيد PostgREST بنسبة 100% من أمان مستوى الصف (RLS) في PostgreSQL. يتم قراءة معلومات المستخدم الموجودة في JWT باستخدام دالة current_setting للتحكم في الأذونات على مستوى SQL.

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

إدارة المخطط (Schema) لتقليل أخطاء النشر

في بنية PostgREST، تغيير المخطط يعني تحديث واجهة برمجة التطبيقات. القيام بذلك يدوياً سيؤدي حتماً إلى وقوع حوادث. يجب استخدام أدوات مثل dbmate لإدارة جميع التغييرات كملفات .sql.

عند إعداد خطوط الأنابيب (Pipelines) في GitHub Actions، سيتم عكس التغييرات تلقائياً على خادم المعاينة (Staging) في كل مرة يتم فيها دفع الكود. بمجرد انتهاء الترحيل (Migration)، أرسل إشارة SIGUSR1 إلى PostgREST أو نفذ NOTIFY pgrst, 'reload schema'. سيتم تحديث واجهة برمجة التطبيقات إلى أحدث حالة دون أي توقف (Downtime). هذه هي الطريقة الأكثر موثوقية حتى للمطور المنفرد للحصول على استقرار تشغيلي بمستوى المؤسسات الكبرى.