00:00:00ماذا لو كانت قاعدة بيانات Postgres الخاصة بك هي واجهة برمجة التطبيقات (API) ولم تضطر لكتابة أي كود خلفي على الإطلاق؟
00:00:05في كل مرة تقوم فيها ببناء API، تكتب نفس الكود الخلفي مراراً وتكراراً. المسارات، والمتحكمات، والتحقق، والمصادقة، كل هذا فقط للتحدث مع
00:00:14قاعدة بياناتك. ثم تغير عموداً واحداً وينكسر كل شيء. لا كود خلفي مخصص. لا متحكمات. لا طبقة ORM.
00:00:21هذا ما تفعله Postgres. إنها المحرك وراء Supabase. تتعامل مع حركة مرور ضخمة وفي غضون دقائق قليلة
00:00:29سأريك كيف يتم ذلك.
00:00:31الآن، إذا كنت تبني واجهات برمجة تطبيقات، فإن هذا الحل يعالج أكثر النقاط المزعجة في النظام بالكامل.
00:00:40تكرار المنطق. أنت تحدد البيانات في قاعدة البيانات.
00:00:44ثم تحدد قواعد الوصول وكود الواجهة الخلفية والتحقق في مكان آخر.
00:00:49ثم نفعل الشيء نفسه لمعالجة الاستجابة في مكان آخر. نفس النظام، طبقات متعددة، وفرص متعددة لتعطل الأشياء.
00:00:56تقوم Postgres باختصار كل هذا. لديها أكثر من 26,000 نجمة على GitHub وتستخدمها Supabase على نطاق إنتاجي.
00:01:03إنها تحول مخططك (schema) إلى REST API جاهز للإنتاج في دقائق فقط. لا يوجد ORM، ولا متحكمات.
00:01:10الأمان موجود داخل قاعدة البيانات، مما يعني تكراراً أقل، وصيانة أقل، ووقتاً أقل بكثير في ربط كل تلك الأشياء المملة معاً.
00:01:19دعني أريك. إذا كنت تستمتع بأدوات البرمجة التي تسرع سير عملك، فتأكد من الاشتراك.
00:01:24لدينا فيديوهات جديدة تصدر طوال الوقت.
00:01:26حسناً. الآن لنقم ببناء هذا الشيء فعلياً. إليكم الإعداد: ثلاث حاويات (containers).
00:01:32هذا كل شيء. Postgres، وPostgREST، وSwagger UI لبعض التوثيق.
00:01:38إليك ملف Docker Compose. لا يوجد شيء معقد هنا. مجرد ثلاث خدمات قمت بربطها معاً.
00:01:45سأقوم بتشغيله باستخدام أمر Docker Compose المعتاد. سيبدأ العمل وانتهيت.
00:01:51لا يوجد تثبيت تبعيات. لا يوجد إعداد لخادم. الآن، لنلقِ نظرة على قاعدة البيانات.
00:01:55سأقوم بتشغيل أمر docker هذا هنا وهذا كل شيء. جدول مهام (todos) بسيط للغاية. معرف، عنوان، حالة الإكمال، وقت الإنشاء، كل الأشياء الأساسية.
00:02:04هذا حقاً كل ما يحدث هنا. ولكن هذا هو الجزء الذي يصبح فيه الأمر مفيداً.
00:02:09أمن مستوى الصف (Row Level Security). نحدد من يمكنه الوصول إلى ماذا مباشرة عبر SQL داخل قاعدة البيانات.
00:02:17لا يوجد منطق مصادقة في الواجهة الخلفية موجود في مكان آخر في نظامنا. إليك السياسة.
00:02:22لدي وصول كامل للمجهول (anon) باستخدام true مع check true. لذا في الوقت الحالي، كل شيء مسموح به. الآن شاهد هذا.
00:02:29سأقوم بطلب get todos باستخدام أمر curl هذا، وهذا كل شيء. JSON كامل مباشرة من Postgres.
00:02:35بدون كود API. والآن بناءً على ذلك، دعني أقوم بتصفيتها الآن. إنها تعمل على الفور.
00:02:41إذا قمت بفرزها، بوم، ها هي ذي. الآن لننشئ صفاً آخر، نرسل طلب post مع جسم JSON وانتهينا.
00:02:50وهي موجودة بالفعل في قاعدة البيانات. لا توجد طبقة ORM تحاول المزامنة هنا.
00:02:56وهنا الجزء الذي يذهل الناس حقاً. وثائق Open API، وواجهة Swagger UI المنشأة تلقائياً. إنها هنا فحسب.
00:03:04أفتحها ونحصل على API تفاعلي كامل. يمكنك استكشاف كل شيء، واختبار المسارات، ورؤية المخططات.
00:03:11لذا من الصفر، أصبح لديك الآن عمليات CRUD كاملة، تصفية، فرز، وتقسيم صفحات. لديك مصادقة أساسية عبر RLS ووثائق في أقل من دقيقة.
00:03:21لماذا يستخدم الناس هذا أصلاً؟ حسناً، إذا لم يكن ذلك كافياً، فلأن العمل التقليدي على الواجهة الخلفية له ضريبة.
00:03:26ومعظم تلك الضريبة ليست عملاً على المنتج نفسه. ما نقوم به فعلياً هو كل أعمال الصيانة هذه، أليس كذلك؟
00:03:33إذا فكرت في النظام المعتاد، ربما يكون Express، Prisma، متحكمات، خدمات، والتحقق في مكان واحد.
00:03:40ثم لدينا المصادقة في مكان آخر. ومنطق قاعدة بياناتك في مكان آخر تماماً.
00:03:45الآن قارن ذلك بـ Postgres. مخططك يحدد الـ API. وأمانك هو RLS.
00:03:52علاقاتك موجودة بالفعل في قاعدة البيانات. لذا بدلاً من بناء طبقة ترجمة حول بياناتك، نحن فقط نعرض البيانات بشكل صحيح.
00:04:02هذا مختلف تماماً. الآن قارن ذلك بواجهة خلفية مخصصة. عليك كتابة كل شيء بنفسك.
00:04:07هذا يمنحك المرونة، بالتأكيد. ولكنه يمنحك أيضاً الكثير من الكود لصيانته.
00:04:13تبقى Postgres أبسط. REST بالإضافة إلى Postgres. الأمان في قاعدة البيانات. وليس مبعثراً عبر البرمجيات الوسيطة أو معالجات المسارات.
00:04:23تظل صيانتك منخفضة لأن الـ API الخاص بك يتبع مخططك. لهذا السبب يحبها الناس.
00:04:28الآن، ل نكون منصفين، هذا هو المكان الذي يقع فيه الناس في المشاكل، لأنه بمجرد أن يبدو الشيء نظيفاً هكذا، يبدأ الناس في التصرف وكأنه يحل كل شيء.
00:04:34هذا لا يحل كل شيء، صحيح؟ لا تزال هناك أشياء يجب الانتباه إليها.
00:04:38ستكون هناك مقايضات ويجب أن تعرف ما الذي يجب مراقبته قبل أن تلمس هذا حتى.
00:04:43ما يحبه الناس هنا هو، حسناً، واضح تماماً. سرعة البناء. يمكنك الانتقال من فكرة إلى API يعمل بسرعة كبيرة.
00:04:51وهو يتوسع بشكل جيد حقاً أيضاً. علاوة على ذلك، Supabase تثبت ذلك.
00:04:55إنهم يستخدمون هذا. لكن السلبيات هنا هي أشياء مثل الاستخدام الكثيف لأمن مستوى الصف سيزيد الحمل على قاعدة البيانات.
00:05:02لذا عليك التفكير بعناية في كيفية تصميم ذلك. المنطق المعقد قد يدفعك نحو الكثير من وظائف SQL أو العروض (views).
00:05:10وبعض الناس يحبون ذلك وبعضهم سيكرهه. فهل يجب عليك استخدام هذا أو حتى تجربته؟
00:05:15نعم، للمشاريع المناسبة. إذا كنت تبني نماذج أولية، أو منتجات حد أدنى (MVPs) أو أي شيء يتمحور حول Postgres، فبالتأكيد، لمَ لا تجربه؟
00:05:23ستتحرك بشكل أسرع. ستكتب كوداً أقل وستحصل على إعدادات أمان افتراضية أقوى من خلال دفع القواعد لأسفل إلى قاعدة البيانات.
00:05:32الآن، إذا كان تطبيقك يحتوي على منطق معقد حقاً، فقد تظل ترغب في طبقة واجهة خلفية رفيعة في الأعلى، شيء صغير، طبقة BFF للحالات الخاصة.
00:05:40ولكن حتى ذلك الحين، يمكن لـ Postgres القيام بمعظم العمل الشاق في الخلفية. لذا الخلاصة الكبرى هي: Postgres تتيح لك الشحن أسرع، والتأمين بشكل أفضل، والصيانة أقل.
00:05:50تصبح قاعدة بياناتك هي المصدر الحقيقي للبيانات، وينبثق الـ API الخاص بك منها بدلاً من أن يصبح نظاماً منفصلاً.
00:05:58إذا كنت تستمتع بأدوات البرمجة والنصائح مثل هذه، فتأكد من الاشتراك في قناة Better Stack. سنراكم في فيديو آخر.