みたいな「どのオブジェクトを取得し、このフィールドが必要である」という情報を「定数」として、Android、iOS、Javascript、サーバーサイドで共通化できる、ということです。して、各プロジェクトで共通化でき、サーバーサイドのスナップショットテストでクエリの互換性を担保したり、、、みたいなこともできます。ようにリソースが多かったり、サーバーサイド開発者がクライアント側を書いたりは(あまり)していません。キャッシュ効率について「CDNでもキャッシュできる」とは述べたのですが、フィードのパーソナライゼーションなどが必要になるので、採用していません。個人的に考えるGraphQLの大きな問題クエリのパースが複雑なため、ライブラリ依存になる、という点です。ライブラリには次のように書いてあります。ライブラリが対応してないものには対応できない」という潜在的な問題を含んでいることになります。すれば良い、ということでもあるのですが。インクリメンタルに表示する、みたいなのが難しいんじゃないかなーと思ったりもします。何かを制限するものではありません。ように使うことも一応可能です。ような使い方ぐらいしかしないからオーバーエンジニアリングだ」というときなんじゃないでしょうか。広まるとうれしいです。年後には「何だったのか」って総括されてそうですけど。エンドポイント増やすのとは何が違うのだろうかニュースアプリとかの場合を想定して、例えば、アプリの立ち上げ時に「トップのフィード」「ユーザー設定」を同時に読み込みたいとします。これはGraphQLでは次のように表現できます(※実際には引数や変数を宣言しますが、クエリ自体は定数です)。ない場合、これを「定数」として縛ろうとすると、次のようなエンドポイントを生やす感じになってしまうかなと思います。なくなってしまいます。「やっぱり立ち上げ時は、ユーザー設定読み込むのやめよう!」となったとき、API側を変更する必要が出てきてしまいます。場合、リソースを宣言してさえおけば、フロント側だけでリクエスト方法を固定できます。なるプロジェクト(JAMstack)を作るベストプラクティス月別アーカイブはてなブログをはじめよう!yamitzkyさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。