GraphQLの問題点について詳しく見ていきましょう GraphQLコアの利点は、いわゆる型システムではなく、強い型制約はRESTfulシステムでもうまく実装可能です。 Zodのorpcスキームを活用し、マルチターミナルコードを生成できるPythonエコシステムのFastAPI + Pydanticソリューションも同様の効果を達成できます GraphQLの核心的な利点は、クライアントが必要に応じて柔軟にデータを要求できることです。 これは従来のBFFレイヤーで実装されている主な機能の一つでもあります。 しかし、従来のBFFレイヤーとの違いは、GraphQLの実装は通常ビジネスに強く縛られており、同様の問題に対応するための別のインフラがない点です。 この場合、柔軟性はGraphQLシステム(またはビジネスに浸透した後に類似のBFFスキーム)で多くの問題をもたらします。 最も簡単に言えば、柔軟性は攻撃対象面の拡大につながります。 最も単純な例としては、悪意のあるユーザーが単純なAST解析でサーバーリソースを大量に消費するほど複雑なクエリを構築できます。 もちろん、多くの人は「クエリの複雑さを制限したらどうですか?」と言うかもしれません。 そこでお聞きしますが、クエリの複雑さを計算する際にASTを解く必要はありますか?それともASTを解く必要があるのでしょうか? もちろん、クエリのパターンを制限すればいいのではないかと言う人もいるでしょう。 ではお聞きしますが、あなたのパターンもASTを解く必要がありますか? そして、GraphQLの最大の利点を制限しているのですが、従来のRESTful APIとの違いは何ですか? さらに、GraphQLのAST解析がビジネス側で解決されなければ、Nodeのシングルスレッドモデルではイベントループの遅延が直接増加し、ユーザー体験はNレベルに上昇します GraphQL自体が行う多くのことは、クエリレベルのレート制限や特別な認証ロジックなど、ビジネスを解決するために別のインフラで解決する必要があります 率直に言って、GraphQLはデータプラットフォームや社内サービスに良い選択肢になり得ます。 しかし、大量のtoCサービスでは、GraphQLは従来のRESTful APIよりも複雑さと不確実性を生み、より多くのインフラ開発を要します。