دعونا نوسع مشاكل GraphQL ميزة نواة GraphQL ليست ما يسمى بنظام الأنواع، بل يمكن تنفيذ قيود النوع القوية بشكل جيد في أنظمة RESTful. باستخدام نظام Zod orpc الذي يمكنه توليد كود متعدد الأطراف، يمكن لحل FastAPI + Pydantic في نظام بايثون تحقيق تأثيرات مماثلة الميزة الأساسية ل GraphQL هي أنه يسمح للعملاء بطلب البيانات بمرونة وفقا لاحتياجاتهم. وهذا أيضا أحد الميزات الرئيسية التي تنفذها طبقة BFF التقليدية. ومع ذلك، الفرق عن طبقة BFF التقليدية هو أن تنفيذ GraphQL عادة ما يكون مرتبطا بقوة بالشركة، ولا توجد بنية تحتية منفصلة للتعامل مع مشاكل مماثلة. في هذه الحالة، ستواجه المرونة الكثير من المشاكل في نظام GraphQL (أو ستواجه خطط BFF مماثلة بعد الدخول في العمل). في أبسط صورها، ستؤدي المرونة إلى سطح هجوم أكبر. في أبسط صورها، يمكن للمستخدم الخبيث بناء استعلام معقد بما يكفي لاستهلاك الكثير من موارد الخادم من خلال تحليل AST البسيط. بالطبع، قد يقول الكثيرون: "آه، لماذا لا تحد من تعقيد الاستعلام؟" دعني أسألك، هل من الضروري حل ASTs أم حل ASTs عند حساب تعقيد الاستعلام؟ بالطبع، قد يقول البعض، لماذا لا نقيد نمط الاستعلام؟ دعني أسألك، هل تحتاج أنماطك أيضا إلى حل أسئلة AST؟ وأنت تحد من أكبر ميزة ل GraphQL، ما الفرق بينك وبين واجهات برمجة التطبيقات التقليدية ل RESTful؟ علاوة على ذلك، إذا لم يتم حل تحليل AST في GraphQL من قبل العمل، مع نموذج Node ذو النمط الأحادي، تفاقم تأخر حلقة الأحداث بشكل مباشر، وسترتف تجربة المستخدم N مستويات العديد من الأمور التي يحتاج GraphQL نفسها إلى حلها من خلال بنية تحتية منفصلة لحل المشكلة، مثل حدود المعدل على مستوى الاستعلام، ومنطق المصادقة الخاص، وغيرها بصراحة، يمكن أن يكون GraphQL خيارا جيدا لمنصات البيانات أو الخدمات الداخلية. ومع ذلك، بالنسبة لخدمات toC ذات الحجم العالي، ستجلب GraphQL تعقيدا وعدم يقين أكبر من واجهات برمجة التطبيقات التقليدية ل RESTful، والتي ستتطلب تطويرا أكبر للبنية التحتية.