GraphQLに不利な点はありますか？[閉まっている]

GraphQLに関するすべての記事で、その素晴らしさがわかりますが、欠点や欠点はありますか？ありがとうございました。

短所：

• あなたは学ぶ必要が GraphQLを設定する方法。エコシステムはまだ急速に進化しているので、あなたは追いつく必要があります。
• > -あなたはあなただけの文字列を送信することができていませんが、より快適にしたいとキャッシュ場合は、クライアントライブラリを使用します、クライアントからのクエリを送信する必要があり、余分なコードをあなたのクライアントで
• 結果を得る前に、スキーマを事前に定義する必要があります=> 追加の作業
• あなたのサーバーにgraphqlエンドポイントが必要です=> まだ知らない新しいライブラリ
• Graphqlクエリは、RESTエンドポイントに単純に移動するよりもバイト数が多い
• サーバーは、クエリを解析してパラメーターを検証するために、より多くの処理を実行する必要があります

しかし、それらはこれらによって対抗される以上のものです。

• GraphQLはそれほど難しくありません
• 追加のコードはほんの数KBです
• スキーマを定義することで、その後のバグ修正と煩わしいアップグレードに耐えることができます。
• GraphQLに切り替える人はたくさんいるので、優れたツールを備えた豊かなエコシステムが開発されています
• 本番環境で永続クエリを使用する場合（GraphQLクエリを単にIDとパラメーターで置き換える）、実際にはRESTを使用する場合よりも少ないバイト数を送信します
• 着信クエリの余分な処理はごくわずかです
• APIとバックエンドの明確な分離を提供することで、バックエンドの改善でのより高速な反復が可能になります

私はGraphQLの使用を検討しているすべての人にいくつかの重要な懸念を発見しました。これまでの主なポイントは次のとおりです。

クエリで無期限の深さ：あなたは木を持っていると深さを知らずに枝を返すようにしたい場合はGraphQLは、無期限の深さで照会することはできませんので、あなたには、いくつかのページネーションを行う必要があるでしょう。

特定の応答構造：GraphQLでは、応答はクエリの形状と一致するため、非常に特定の構造で応答する必要がある場合は、変換レイヤーを追加して応答を再形成する必要があります。

ネットワークレベルでのキャッシュ：GraphQLがHTTP（単一のエンドポイントでのPOST）を介して一般的に使用されるため、ネットワークレベルでのキャッシュは困難になります。これを解決する方法は、持続クエリを使用することです。

ファイルアップロードの処理：GraphQL仕様にはファイルアップロードについては何もありません。また、ミューテーションは引数のファイルを受け入れません。これを解決するには、他の種類のAPI（RESTなど）を使用してファイルをアップロードし、アップロードしたファイルのURLをGraphQLミューテーションに渡すか、実行コンテキストにファイルを挿入して、リゾルバー関数内にファイルを配置します。

予測できない実行：GraphQLの性質は、必要なフィールドを組み合わせてクエリを実行できることですが、この柔軟性は無料ではありません。パフォーマンスやN + 1クエリのように、知っておくとよい問題がいくつかあります。

超シンプルAPI：本当にシンプルなAPIを公開するサービスがある場合、GraphQLは複雑さを追加するだけなので、シンプルなREST APIの方が優れている場合があります。

この最大の問題は、graphQLで発生します。つまり、リレーショナルデータベースで使用している場合は、結合です。

1. いくつかのフィールドを許可または禁止できるという事実は、結合を重要なものにします（単純ではありません）。これは余分なクエリにつながります。

2. また、graphqlのネストされたクエリは循環クエリにつながり、サーバーをクラッシュさせる可能性があります。特別な注意が必要です。

3. レート制限通話のは困難だって、今、ユーザーが1回の呼び出しで複数のクエリを発射することができなりました。

ヒント：javascript / nodeの場合、Facebookのデータローダーを使用してクエリの数を減らします

それは年々改善されており、現在のところ、GraphQL のコミュニティーは成長しており、その結果、以前に他の回答で強調されていた多くの問題に対する解決策が多くあります。しかし、企業がすべてのリソースをGraphQLに投入することを依然として妨げているものを認めるために、いくつかの問題と解決策をリストし、その後に未解決のものをリストしたいと思います。

• ネットワークレベルでのキャッシュ -としてブルーノは、それが持続クエリだともちろん、あなたがクライアント上でキャッシュできると誰もがデータベースレベルあるいはRedisの上でキャッシュを使用することができ停止していないと述べました。しかしもちろん、GraphQLにはエンドポイントが1つしかなく、各クエリは異なります。このタイプのキャッシュを実行することは、RESTを使用するよりもはるかに複雑です。
• GraphQLのネストされたクエリは循環クエリにつながり、サーバーをクラッシュさせる可能性があります -さまざまなソリューションで問題が発生することはもうありません。それらのいくつかはここにリストされています
• ファイルのアップロードの処理 -すでにたくさんありますソリューションがあります

しかし、不利な点として数えることができるいくつかのケースがあります：

• 定型文の過剰（つまり、新しいクエリを作成する場合、スキーマ、リゾルバ、およびリゾルバを定義するために、データとフィールドを解決する方法をGraphQLに明示的に伝える必要があります。クライアント側では、関連するフィールドを含むクエリを作成しますこのデータ）
• エラー処理 -それはRESTとの比較により関連していると言う必要があります。これはアポロでも可能ですが、同時にRESTよりもはるかに複雑です
• 認証と承認 -先ほど言ったように、コミュニティは目覚ましいスピードで増加しており 、この目標に対する解決策はすでにいくつか あり ます。

要約すると、GraphQLは特定の目標のためのツールに過ぎず、すべての問題に対する特効薬ではなく、もちろんRESTの代替品ではありません。

単一のエンドポイントを持ち、すべてのデータを公開するのは本当に素晴らしいことです。GraphQLについて考慮すべき点を以下に示します。

1. ファイルのダウンロード/アップロードの実装は注意が必要です（文字列への変換は、大きなファイルには最適なオプションではない場合があります）
2. フロントエンドとバックエンドの両方に多くの定型コードとスキーマコード。
3. GraphQL仕様で提供されているページ付けに従ってください。
4. フィールドの順序付けのためにカスタムの順序付けと優先順位付けロジックを許可します。ユーザーデータと関連するグループおよびロールをフェッチする場合の例。ユーザーは、ユーザー名、グループ名、またはロール名に基づいてデータをマルチソートできます。
5. 認証と承認は、バックエンドフレームワークに依存します。
6. 各graphqlコマンドに対して単一のクエリを起動するためのバックエンド最適化とデータベースサポートがトリッキーになる可能性があることを確認してください。

また、その実装後に長所を検討する必要があります：

1. 新しいアイテムをサポートし、既存の動作を更新するための非常に柔軟性があります。

2. 一度実装すると、引数とカスタムの順序を使用して条件を簡単に追加できます

3. 多くのカスタムフィルターを使用し、作成する必要があるすべてのアクションを削除します。例として、ユーザーがID、名前などを引数として持ち、フィルタリングを実行できます。さらに、フィルターはユーザーのグループにも適用できます。

4. すべてのGraphQLクエリとミューテーションを含むファイルを作成することで、APIを簡単にテストできます。
5. ミューテーションは簡単で、コンセプトを理解すれば簡単に実装できます。
6. 複数の深さのデータをフェッチする強力な方法。
7. VoyagerとGraphiQL UIまたはPlaygroundのサポートにより、表示と使用が簡単になります。
8. 有効な記述方法でスキーマを定義する際の文書化の容易さ。

現時点では、graphqlはバックエンドアーキテクチャの一部である必要があると思います。ファイルのアップロードでは、まだ通常のAPIを使用しています