مقدمة إلى Hasura GraphQL Engine لواجهات برمجة التطبيقات الديناميكية باستخدام PostgreSQL

بشكل عام ، على مدار السنوات الماضية ، تعرضت واجهات برمجة تطبيقات REST للنقد باعتبارها غير مرنة أثناء التعامل مع المتطلبات التقنية المتغيرة بسرعة. بالعودة إلى الماضي ، يعتقد الكثيرون أنه تم إنشاء GraphQL للتعامل مع هذه الحاجة إلى مزيد من المرونة والكفاءة في تطوير واجهة برمجة التطبيقات. وبالتالي ، التخفيف من أوجه القصور في واجهات برمجة تطبيقات REST. نتيجة لانتقال Facebook بعيدًا عن تطبيقات HTML5 إلى إعدادات أكثر قوة وأصلية ، زادت شعبية GraphQL واعتمادها على مدار السنوات الخمس الماضية لسبب وجيه. في هذه المدونة ، سوف نتعمق في ظاهرة GraphQL ، PostgreSQL ولاحقًا نقدم مقدمة شاملة لمحرك Hasura GraphQL. في المقتطف ، العلاقة بين محرك Hasura GraphQL و PostgreSQL والنظام البيئي.

GraphQL: تمرد على Facebook

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

العمارة REST

عادةً ما تكون واجهات برمجة التطبيقات عبارة عن قواعد أو إجراءات أو بروتوكولات تحدد كيفية تفاعل مكونات البرامج. نقل الحالة التمثيلية (REST) ​​هو في الأساس بنية تصميم API يتم الاستفادة منها عادةً في تنفيذ خدمات الويب حيث يُعتبر كل شيء "موردًا". لسوء الحظ ، كانت منهجية RESTful تقتصر باستمرار على التعامل مع الموارد الفردية. ومن ثم ، إذا كانت هناك حاجة إلى البيانات وتأتي من مصدرين أو أكثر ، على سبيل المثال ، المنشورات والمستخدمين ، فستكون هناك حاجة لرحلات متعددة الجولات إلى الخادم لجمع كل ما هو مطلوب. بالإضافة إلى ذلك ، واجهت REST مشكلات في الجلب "over" و "under". لم يكن كل هذا مثاليًا ، خاصة مع ظهور المزيد من التطبيقات التي تعتمد على البيانات والتي تتعامل مع مجموعات البيانات الكبيرة التي تجمع بين الموارد ذات الصلة. وهو ما يمكن أن يفسر المأزق الذي يواجهه فيسبوك.

وبالتالي ، فإن الحاجة إلى بنية API من شأنها أن تتخذ نهجًا أكثر مرونة وتقدمًا.

خلق البديل

بدلاً من ذلك ، لا تفكر GraphQL في البيانات من حيث عناوين URL للموارد أو المفاتيح الثانوية أو الجداول ولكن من حيث الرسم البياني للكائنات والنماذج التي تستخدم NSObjects أو JSON. على وجه التحديد ، لا تحتاج GraphQL إلى نقاط نهاية مخصصة لكل حالة استخدام حيث يمكن تمثيل الإمكانات وحالات الاستخدام المختلفة في "رسم بياني" واحد. باستخدام لغة استعلام GraphQL ، يمكنك وصف الشكل الذي يجب أن تبدو عليه الاستجابة بالضبط ، وبالتالي لا حاجة إلى رحلات ذهاب وإياب إضافية للخادم. باعتبارها لغة استعلام لطبقة التطبيق ، تم تصميمها لتفسير سلسلة من خادم / عميل وإرجاع تلك البيانات بتنسيق مستقر ومفهوم وقابل للتنبؤ. إنها ببساطة أداة لدمج البيانات بشكل أفضل.

البساطة والاستقرار والكفاءة.

الحقيقة هي أنه لا تتطلب جميع المشاريع GraphQL على الرغم من مخططها المحدد جيدًا ، لذلك نحن نعلم بالتأكيد أننا لن نبالغ في الجلب. رغم ذلك ، إذا كان لدينا منتج مؤسسي يعتمد على بيانات من مصادر متعددة ، على سبيل المثال MySQL و Postgres وواجهات برمجة تطبيقات أخرى ، فإن GraphQL هي الخيار الأفضل. تفتخر GraphQL بالبساطة خاصةً فيما يتعلق باسترجاع البيانات حيث يتم جمع البيانات تحت نقطة نهاية مشتركة أو استدعاء. بشكل أساسي ، نظرًا لأن العملاء يحصلون على ما يحتاجون إليه بالضبط ، فإن هذا يقلل بشكل فعال من حجم كل طلب يقدمه العميل مما يؤدي إلى تطبيقات عالية الأداء. نظرًا لأن GraphQL توحد البيانات التي قد تتطلب نقاط نهاية متعددة بخلاف ذلك ، فإنها تسهل عمليات الاسترداد المتكررة المعقدة ، وبالتالي كفاءة استعلام أفضل. وبالتالي ، فإن بساطته تأتي بمزيد من الاستقرار الخلفي والتخطيط والبناء والتنفيذ والتشغيل المستمر بمرور الوقت.

مزايا GraphQL

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

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

من الناحية الفنية ، فإن GraphQL عبارة عن غلاف يمكن تعريفه بمعنى أنه ليس عليك استبدال نظام REST بالكامل. يعني هذا أساسًا أن GraphQL متوافقة مع الأنظمة التي تتوافق معها واجهات برمجة التطبيقات التي تركز على REST. بالإضافة إلى ذلك ، تسمح GraphQL بالتطوير السلس والمستقل للواجهة الأمامية والخلفية. هذا لأنه بمجرد تحديد المخطط جيدًا ، تكون الفرق التي تعمل على الواجهة الأمامية والخلفية على دراية بالهيكل المحدد للبيانات. ينظر العديد من المهندسين المتكاملين إلى كل هذه الفوائد على أنها مفيدة. أخيرًا ، تتمتع GraphQL بقدرة مذهلة على التأمل الشامل والتوثيق الذاتي.

حالات استخدام GraphQL في تطوير واجهة برمجة التطبيقات

يعتبر GraphQL قويًا للغاية ، ويستخدمه مطورو مكدس كامل يسعون إلى قراءة مستقرة مع سرعة وفهرسة سريعين. على وجه التحديد ، تعد GraphQL مفيدة في تطوير واجهة برمجة التطبيقات التي تتطلب إنتاجية عالية للبيانات. في واقع الأمر ، فإنه يقلل من كمية البيانات المطلوبة للنقل عبر الشبكة. هذا مفيد للغاية لمستخدمي الهواتف المحمولة والأجهزة منخفضة الطاقة والشبكات غير المتقنة. وهذا من بين الأسباب الأولية وراء تصميم Facebook لـ GraphQL. خلافًا للاعتقاد ، لا يمكن تطبيق GraphQL في قواعد البيانات المعقدة فقط ، بل يمكنها إنشاء قواعد بيانات بسيطة نسبيًا بكفاءة أكبر.

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

ما هي PostgreSQL؟

كنظام مجاني لإدارة قواعد البيانات الارتباطية يعتمد على المجتمع ، فإن PostgreSQL ليست مملوكة لأي شركة بمفردها. تعتبر Postgres أقوى وأقوى أنظمة RDBMS متوفرة داخليًا ، وقد تمت كتابتها بلغة C ، وتدعم عددًا من لغات البرمجة ، مثل C / C ++ ، و JavaScript ، و Java ، و Python ، و R ، و Go ، و Lisp ، وما إلى ذلك. مطورون متكاملون ، PostgreSQL أكثر ثراءً بالمميزات من أختها MySQL ، وتكتسب شعبية بسبب ميزاتها وقابليتها للتطوير والأداء. تحظى PostgreSQL بشعبية كبيرة في المشاريع حيث تدور المتطلبات حول الإجراءات المعقدة والتصاميم المعقدة والتكامل المفصل وسلامة البيانات.

مزايا Postgres لمطوري Full-Stack

بشكل عام ، تمنح ميزات مثل البحث عن النص الكامل وأعمدة JSON والنسخ المنطقي Postgres اليد العليا على MySQL. هذا هو الأمثل لمتطلبات الأداء لقواعد البيانات التجارية النموذجية مع السماح بدمج العديد من أنظمة قواعد البيانات في نظام واحد لتقليل النفقات العامة والتكلفة. علاوة على ذلك ، فإن ميزاته الأحدث لـ Key-Value-Storage (أنواع أعمدة JSON / JSONB) تجعله بديلاً مناسبًا لقواعد بيانات NoSQL. بالإضافة إلى ذلك ، فهي تدعم التجميع أو بنية السيد والعبد ، مما يجعلها مناسبة تمامًا للبيئات الشبيهة بالسحابة. بالإضافة إلى ذلك ، يسمح امتداد غلاف البيانات الأجنبية الشهير بالاستعلام عن المصادر الخارجية مباشرةً من داخل PostgreSQL عند الضرورة. على وجه التحديد ، هو الأنسب للأنظمة التي تتطلب تنفيذ الاستعلامات المعقدة وتخزين البيانات وتحليل البيانات الديناميكي.

في واقع الأمر ، تدعم PostgreSQL بشكل أفضل ميزات معينة لا تدعمها MySQL. على سبيل المثال ، تحقق من القيود وأنواع البيانات الثرية (مثل المصفوفات والخرائط و JSON) والدعم الجغرافي المكاني الأكثر ثراءً (PostGIS) والدعم الأكثر ثراءً للنص الكامل. بالإضافة إلى ذلك ، فهو يدعم إنشاء الفهرس غير المحظور والفهارس الجزئية وتعبيرات الجدول الشائعة والمزيد من وظائف التحليلات الديناميكية. على الرغم من ذلك ، تقدم PostgreSQL دعمًا أصليًا لـ SLL للاتصالات لتشفير اتصالات العميل / الخادم ، بالإضافة إلى تحسين داخلي يُسمى SE-PostgreSQL والذي يوفر عناصر تحكم وصول إضافية تستند إلى سياسة SELinux.

مع العديد من الميزات الغنية للمنتجات على مستوى المؤسسات ، تعد PostgreSQL مناسبة للأنظمة الكبيرة حيث تتطلب البيانات المصادقة وسرعات القراءة / الكتابة ضرورية لنجاح المشروع. علاوة على ذلك ، فإنه يدعم أيضًا معززات الأداء المتعددة التي تتوفر عادةً في حلول الملكية. وتشمل هذه: التزامن بدون أقفال القراءة ، وخادم SQL ، ودعم البيانات الجغرافية المكانية على سبيل المثال لا الحصر.

الميزة الرئيسية الأخرى لعمارة Postgres هي قابليتها الفريدة للتوسع. يسمح للمستخدمين بإضافة ميزات مثل أنواع البيانات وطرق الوصول إلى الفهرس ولغات برمجة الخادم وأغلفة البيانات الأجنبية (FDW) والإضافات القابلة للتحميل دون تغيير رمز النظام الأساسي. فهي تستفيد من بنية المعالجات الحديثة متعددة النواة ، مما يسمح لأدائها بالنمو بشكل خطي تقريبًا مع زيادة عدد النوى. هذا مهم بشكل عام ، تمنح الميزات مثل البحث عن النص الكامل ، وأعمدة JSON ، والنسخ المنطقي ، Postgres اليد العليا على MySQL. هذا هو الأمثل لمتطلبات الأداء لقواعد البيانات التجارية النموذجية مع السماح بدمج العديد من أنظمة قواعد البيانات في نظام واحد لتقليل النفقات العامة والتكلفة. علاوة على ذلك ، فإن ميزاته الأحدث لـ Key-Value-Storage (أنواع أعمدة JSON / JSONB) تجعله بديلاً مناسبًا لقواعد بيانات NoSQL. بالإضافة إلى ذلك ، فهي تدعم التجميع أو بنية السيد والعبد ، مما يجعلها مناسبة تمامًا للبيئات الشبيهة بالسحابة. بالإضافة إلى ذلك ، يسمح امتداد غلاف البيانات الأجنبية الشهير بالاستعلام عن المصادر الخارجية مباشرةً من داخل PostgreSQL عند الضرورة. على وجه التحديد ، هو الأنسب للأنظمة التي تتطلب تنفيذ الاستعلامات المعقدة وتخزين البيانات وتحليل البيانات الديناميكي.

سلبيات PostgreSQL

بشكل عام ، إذا كنت تتخيل معايير ANSI SQL ، ففكر في PostgreSQL ، على الرغم من أنك إذا كنت تفضل معايير ODBC ، فاختر MySQL. لسوء الحظ ، تقصر Postgres أحيانًا في الأداء مع بيئات الإنتاج الحية "دائمًا". عيب إضافي مع Postgres هو حقيقة أن النسخ المتماثل يتم تنفيذه على مستوى محرك التخزين. وهذا يجعله أكثر تكلفة من نسخ MySQL ، وهو أكثر نضجًا ويتم تنفيذه على "مستوى محرك الاستعلام".

مقدمة لمحرك Hasura GraphQL

نظرًا لأننا قمنا بتغطية تطوير واجهة برمجة تطبيقات GraphQL و PostgreSQL لفترة وجيزة ، يجب أن يكون لدينا سياق كافٍ لمقدمة عن محرك Hasura GraphQL. بشكل أساسي ، Hasura هو ببساطة محرك GraphQL لـ PostgreSQL RDBMS ، مما يوفر طريقة مبسطة للتمهيد وإدارة تطوير واجهة برمجة تطبيقات GraphQL. في الماضي ، يعتبر Hasura حاليًا الحل الوحيد المتاح بسهولة والذي يضيف على الفور GraphQL-as-a-Service إلى التطبيقات القائمة على PostgreSQL. بشكل أساسي ، تجاوز المهمة التي تستغرق وقتًا طويلاً في كتابة التعليمات البرمجية الخلفية التي تعالج GraphQL.

حسورة مبسط

لنأخذ دقيقة واحدة لتبسيط Hasura أكثر. في الأساس ، تعد واجهات برمجة التطبيقات واجهات تسمح لك بطلب المعلومات (استعلام) ، وبالتالي الرد عن طريق إرسال بيانات JSON أو XML. عادةً ما يتم استضافة قاعدة البيانات هذه وجلبها من الخادم. هنا يأتي دور Hasura لتبسيط الأمور. بعد فوات الأوان ، يعتبر محرك Hasura GraphQL خادمًا يتعامل مع استعلامات GraphQL الخاصة بك عبر قاعدة بيانات Postgres. هذا يقلل بشكل فعال الوقت الذي يستغرقه تطبيقك ليكون جاهزًا للإنتاج مما يسمح لك بإنشاء وعرض وتعديل جداول قاعدة البيانات الخاصة بك بسهولة ببضع نقرات. وبالتالي ، فإن هذا يسمح للمطورين ذوي المكدس الكامل ببناء تطبيقات GraphQL قابلة للتطوير على PostgreSQL في وقت أقصر. يوفر هذا للمطورين أسابيع من الترميز المسبق ويمكن أن يمنع أخطاء تسرب البيانات الإشكالية من الوصول إلى الإنتاج.

ما هي المشكلة التي يحلها Hasura في تطوير API؟

بشكل عام ، تبسط Hasura إدارة دورة حياة API أثناء استخدام الإنتاج على نطاق واسع خاصة لواجهات برمجة التطبيقات المعقدة. قبل كل شيء ، يجذب محرك GraphQL المطورين المتكاملين الذين يتراكمون في مشاريع تطوير واجهة برمجة تطبيقات المؤسسة باستخدام قواعد بيانات PostgreSQL الحالية. من الناحية المثالية ، نظرًا لأن GraphQL تسمح بدورات تطوير واجهة برمجة التطبيقات بسرعة البرق ، توفر Hasura طريقة مبسطة للمؤسسات للانتقال تدريجياً إلى GraphQL ، دون التأثير على التطبيقات أو قواعد البيانات أو المستخدمين الحاليين. إلى جانب أدائه الخفيف والعالي ، يأتي المحرك مزودًا بواجهة مستخدم إدارية ، مما يسمح لك باستكشاف واجهات برمجة تطبيقات GraphQL الخاصة بك وإدارة مخطط قاعدة البيانات والبيانات بشكل مرئي.

مزايا حسورة

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

ثانيًا ، يجعل محرك Hasura GraphQL من السهل جلب البيانات المطلوبة باستعلام واحد. يقوم بذلك عن طريق السماح لك بإضافة طرق عرض كعلاقات إلى جداول أو طرق عرض أخرى. بالإضافة إلى ذلك ، فإنه يسمح لكتابة أدوات حل مخصصة مع دمج المخطط وتكامل الوظائف بدون خادم أو واجهات برمجة التطبيقات للخدمة المصغرة التي يتم تشغيلها في أحداث قاعدة البيانات. يمكن أن يكون هذا مفيدًا ويسهل بناء تطبيقات 3factor. في الواقع ، يعتبر Hasura محركًا خفيف الوزن للغاية. في الماضي ، تستهلك فقط ما يصل إلى 50 ميجابايت من ذاكرة الوصول العشوائي حتى أثناء تقديم أكثر من 1000 طلب / في الثانية. عائد رائع على الاستثمار!

على وجه التحديد ، تسهل Hasura أيضًا التفويض الدقيق على مستوى بيانات API والمصادقة بشكل جيد. يسمح بالاتصال بموفر المصادقة المفضل إما عبر خطاف الويب أو JWT أو Auth0 أو تطبيقات مخصصة. وبالتالي ، فإن تحديد الأدوار للمستخدمين ، وتحديد من يمكنه الوصول إلى البيانات المختلفة ، على سبيل المثال ، المسؤول ، والمستخدمون المجهولون ، وما إلى ذلك بشكل عام ، يعتمد نظام التحكم في الوصول الدقيق على بنية جدول قاعدة البيانات المشابهة لمخطط GraphQL. بالإضافة إلى ذلك ، يتم تحديد قواعد الأذونات المخصصة بشكل صارم بناءً على عمليات قاعدة البيانات وقيمها.

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

وقائع استخدام Hasura

مناسب للبيئات عالية الأداء ، يوفر محرك Hasura السرعة أثناء أتمتة تنفيذ GraphQL-Postgres في قواعد البيانات الحالية. وبالتالي ، فإن هذا يوفر للشركات التي تستخدم Postgres بالفعل طريقة أقل إجهادًا وتزايدًا للانتقال إلى GraphQL من خلال ربط الجداول الموجودة في "رسم بياني". تعتني Hasura بكفاءة بخياطة المخطط مما يسمح لك بتطبيق منطق الأعمال المخصص بسهولة. باستخدام مخططات GraphQL عن بُعد ، يمكن الاستفادة من Hasura كبوابة لمنطق عمل مخصص يتيح لك الكتابة إلى خوادم GraphQL بلغتك المفضلة ، ثم كشف البيانات لاحقًا إلى نقطة نهاية واحدة. علاوة على ذلك ، تمتلك Hasura صيغة رائعة للاستعلامات والطفرات مع استعلامات مباشرة مضمنة تسمى الاشتراكات في GraphQL.

قيود Hasura القليلة

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

استنتاج

في الختام ، مع نمو GraphQL ، ستعمل بشكل جوهري على تبسيط تطوير واجهة برمجة التطبيقات داخل المؤسسات للبناء على نطاق الويب. من خلال التبني السريع واسع النطاق لـ GraphQL عبر مجموعة متنوعة من الصناعات ، تمتلك Hasura القدرة على زيادة أتمتة إنشاء وإدارة واجهات برمجة التطبيقات باستخدام تقنيات الصناعة القياسية المختارة و GraphQL و Postgres. يبسط Hasura إنشاء الخلفيات الخلفية لـ GraphQL (إنشاء وقراءة وتحديث وحذف). والأهم من ذلك ، أن Hasura هو الخيار الأفضل والوحيد إلى حد بعيد إذا كنت تبدأ من نقطة الصفر باستخدام واجهة برمجة تطبيقات مركزية GraphQL و Postgres ، دون كتابة تعليمات برمجية للواجهة الخلفية. لأية استفسارات أو استشارات حول إمكانيات مؤسسة GraphQL و Hasura ، لا تتردد في التواصل معنا. هذا كل شيء من أجل مقدمتنا إلى Hasura GraphQL Engine.