تعتبر GraphQL مشكلة كبيرة: لماذا لا تعتبر معيار الصناعة للاستعلام عن قاعدة البيانات؟

أصبحت GraphQL سريعًا لغة استعلام عن الانتقال للشركات للتفاعل مع بياناتها. على الرغم من أن إدارة البيانات هي واحدة من أهم اهتمامات الكثير من الشركات ، إلا أن الكثير من الناس لا يفهمون حقًا ما تفعله GraphQL أو سبب شعبيتها.

في المتوسط ​​، يولد العالم حوالي 2.5 كوينتيليون بايت من البيانات في اليوم. تحتاج الشركات إلى طريقة لجمع تلك البيانات واستخدامها بفعالية. يتم إنشاء الكثير من البيانات في التطبيقات (على سبيل المثال ، تطبيق هاتف ذكي لخدمة العملاء يتيح للعملاء إخبارك بما إذا كانوا راضين أو ما إذا كانوا يواجهون أي مشكلات ويحتاجون إلى مساعدة في استكشاف الأخطاء وإصلاحها). تحتاج التطبيقات إلى طريقة لإيصال المعلومات إلى الواجهة الخلفية ؛ وهي أدوات إدارة وتخزين البيانات. ثم يمكن تحليل البيانات لاكتشاف المشاكل وتطوير الحلول. وبالطبع ، فهو ثنائي الاتجاه. لا ترسل التطبيقات البيانات إلى الخلفيات فحسب ، بل تحتاج التطبيقات إلى بيانات من الخلفية. على سبيل المثال ، التوصيات ، حالة التسليم ، أرصدة الحسابات. وهذا هو الغرض من GraphQL: الحصول على البيانات من الواجهة الخلفية وإليها. إنها واجهة برمجة تطبيقات أكثر حداثة تربط التطبيقات بالخلفية.

على الرغم من أن العديد من قادة التكنولوجيا ربما سمعوا عن GraphQL ، إلا أنهم ربما سمعوا الكثير عن SQL (لغة الاستعلام الهيكلية). SQL هي أساسًا معيار الصناعة للاستعلام عن قواعد البيانات ، على الرغم من تزايد شعبية GraphQL.

ما أوجه المقارنة بين GraphQL و SQL ، وهل هناك طريقة للاستفادة من كليهما عند إجراء الاستعلامات؟

GraphQL مقابل SQL: النظرة الشاملة

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

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

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

GraphQL مقابل SQL أثناء العمل

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

تعرض لك GraphQL أيضًا هذه المعلومات في هيكل هرمي يجعل من السهل رؤية العلاقة بين أجزاء البيانات التي طلبتها. بمعنى آخر ، يمكنك أن ترى أن تاريخ تسليم الحزمة الخاصة بك مرتبط برقم التتبع الذي تلقيته.

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

لماذا لا تزال SQL تحظى بشعبية كبيرة؟

يسمح مخطط واجهة برمجة تطبيقات GraphQL فقط بمجموعة فرعية من العمليات ، اعتمادًا على المطورين الذين ينفذون واجهة برمجة التطبيقات هذه. بمعنى آخر ، تعتمد مدى مرونة استعلاماتك على مدى مرونة مطوري واجهة برمجة التطبيقات. على سبيل المثال ، تسمح لك واجهة برمجة التطبيقات (API) بالبحث عن العملاء عبر البريد الإلكتروني فقط. للبحث عن العملاء حسب المدينة ، سيحتاج التطبيق إلى جمع كل العملاء ، ثم ترشيحهم واحدًا تلو الآخر. تحدث عن معقد.

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

في المقابل ، تعد SQL أكثر تعبيرًا من البداية ، مما يعني أنه يسهل إخبار النظام بما تريد دون الكثير من التكوين الإضافي. يمكن للمرء أن يسأل بسهولة عن أي قاعدة بيانات “للعميل John Doe ، أعطني الطلبات التي يتجاوز مبلغها 100 دولار” ، باستخدام سطر واحد من التعليمات البرمجية. ستمنحك SQL ما تحتاجه ، بغض النظر عن بنية قاعدة البيانات.

الطريقة التي أحب أن أقولها هي كالتالي: تسمح GraphQL بالاستعلامات المرنة ضمن إطار العمل الذي حدده المطور الذي أنشأ واجهة برمجة التطبيقات. يسمح SQL بالاستعلام العالمي عن أي نموذج قاعدة بيانات. لذلك إذا كنت تستعلم بشكل أساسي عن قواعد البيانات ، فستقوم SQL بالمهمة بشكل جيد.

هل هناك طريقة لرأب الصدع؟

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

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

على الرغم من شعبيتها كلغة استعلام API ، فإن GraphQL لن تزيل لغة SQL باعتبارها اللغة الأساسية للوصول إلى قاعدة البيانات.

أنانت جينجران هو الرئيس التنفيذي والشريك المؤسس لـ ستيبزين.