Best（GraphQL）APIはあなたが書くものです

フロントエンド開発者として、GraphQLのエレガントなデータ露出に感謝しています。これはカスタマイズ可能なメニューのようなもので、UIコンポーネントに必要なデータを正確に要求できます。過度のAPI呼び出しや、オーダーメイドのAPIのバックエンド開発者への依存を避けてください。

ただし、誰かがそのデータメニューを作成します。それがあなたの社内GraphQL APIである場合、あなたはすべてを制御します。ただし、CMSのようにサードパーティのAPIである場合、コントロールは限られています。事前に定義されたメニューにこだわっています。追加または代替は許可されていません。

この制限は、Simen SkogsrudとKnutMelværとのShoptalkの議論で強調されました。 JSONデータストレージとCMSであるSanityは、GraphQLの代わりに独自のクエリ言語であるGROQを使用しています。当初、これは一歩後退のように思えます - 業界標準を使用する代わりに独自の言語を作成します。

しかし、SimenとKnutは、サードパーティAPIとして使用するとGraphQLの制限を指摘しました。提供されたオプションに制限されています。たとえば、著者向けの汎用GraphQL APIは、次のことのみを提供する場合があります。

 <code>{ allAuthors { author { name username avatar } } }</code>

著者自身ではなく、著者の数が必要な場合は、運が悪いです。すべての著者を取得し、クライアント側を数える必要があります。

GraphQLエンドポイントを提供するCMSは、厳格、限られたデータアクセス、またはそのアクセスを拡張および制御する方法という選択に直面しています。 Sanityは後者を選択し、JSONストア内のデータにアクセスするのに十分な強力なオープンソースのクエリ言語であるGROQを提供しました。

GROQを使用すると、著者数を取得するためにAPI変更は必要ありません。次のようなクエリを使用できます。

 <code>{ "totalAuthors": count(*[_type == "author"]) }</code>

（注：これは概念です。正確な構文は、クエリのJSONに依存します。）

Groqの利点：

• 無制限のクエリ：データにアクセスします。
• 簡素化されたアーキテクチャ：中間構成レイヤーはありません。

短所：

• 複雑な構文：より急な学習曲線。
• 限られた統合：マルチAPI接続、許可ベースのデータアクセスなどの機会の削減。

以上がBest（GraphQL）APIはあなたが書くものですの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。