GraphQL ile ilgili sorunları daha da genişletelim GraphQL çekirdeğinin avantajı, sözde tip sistemi değildir; aslında, güçlü tip kısıtlamaları RESTful sistemlerde iyi uygulanabilir. Zod'un çok terminalli kod üretebilen orpc şemasından tam anlamıyla yararlanarak, Python ekosistemindeki FastAPI + Pydantic çözümü benzer etkiler elde edebilir GraphQL'nin temel avantajı, müşterilerin ihtiyaçlarına göre esnek şekilde veri talep etmelerine olanak sağlamasıdır. Bu aynı zamanda geleneksel BFF katmanının uyguladığı ana özelliklerden biridir. Ancak geleneksel BFF katmanından fark, GraphQL uygulamasının genellikle iş dünyasına sıkı sıkıya bağlı olması ve benzer sorunlarla ilgilenecek ayrı bir altyapının olmamasıdır. Bu durumda, esneklik GraphQL sisteminde (veya benzer BFF planları) birçok sorun getirecektir (veya işe girdikten sonra benzer BFF planlarıyla karşılaşacak). En basit halinde, esneklik daha büyük bir saldırı yüzeyine yol açar. En basit halinde, kötü niyetli bir kullanıcı, basit AST ayrıştırma yoluyla sunucu kaynaklarınızın çoğunu tüketecek kadar karmaşık bir sorgu oluşturabilir. Elbette, birçok kişi "Ah, neden Sorgu'nun karmaşıklığını sınırlamıyorsun?" diyebilir. O halde size soracağım, Sorgu karmaşıklığını hesaplarken AST veya AST'leri çözmek gerekli mi? Tabii ki, bazı insanlar 'Sorgu desenini neden sınırlamasın?' diyebilir. O zaman size sormak istiyorum, kalıplarınız da AST'leri çözmeli mi? Ve GraphQL'nin en büyük avantajını sınırlıyorsunuz, sizin geleneksel RESTful API'lerle aranızdaki fark nedir? Ayrıca, GraphQL'nin AST ayrıştırması iş dünyasından çözülmezse, Node'un tek iş parçacıklı modeliyle olay döngüsü gecikmeniz doğrudan büyür ve kullanıcı deneyimi N seviye yükselir GraphQL'nin kendisinin yapması gereken birçok şey, işi çözmek için ayrı bir altyapı tarafından çözülmek zorunda; örneğin sorgu düzeyinde hız sınırları, özel kimlik doğrulama mantığı vb Açıkçası, GraphQL veri platformları veya dahili hizmetler için iyi bir tercih olabilir. Ancak, yüksek hacimli toC hizmetleri için GraphQL, geleneksel RESTful API'lere göre daha fazla karmaşıklık ve belirsizlik getirecek ve bu API'ler daha fazla altyapı geliştirme gerektirecek.