上記のタイトルで登壇してきました。サーバーサイドの話をしようと思ったけどGraphQLの解決している話をしようと思ったらクライアントの事もかなりはいってしまったので記事のタイトルは変えました。記事の最後に資料を書くにあたって参考になった資料のリンクを置いてます。“APIをコンシューマにとって理解しやすく使いやすいものにするには、コンシューマの視点に立って設計しなければならない。非同期リクエスト-レスポンスパターンで実装し直すあまり利用されないが膨大な量のデータがDBに入っているS3やGlacierに再配置するGraphQLを前段に置くことでクライアントに一切影響なく、サーバーサイドの構成を変更することが出来る。逆説的に後から変更が自由に容易に行える事で、実装時に恒久的な選択にプレッシャーを感じることなく現在のコンテキストに合う技術を自信を持って選択出来る。サーバーサイドの人も技術的負債を作りたくないというプレッシャーはあるので、変更しやすくしておくことで適切なタイミングで返済していける土壌を作っておく事が心理的安全性につながります。利用可能なデータが発見しやすい・利用しやすいクライアントに提供しているデータが一元化されるユーザーにとって見せるか見せるべきではないかの監査を1箇所で行う事で監査可しやすいRESTishなAPIでは全てのエンドポイントで同一レベルの監査が必要だったGraphQLが持ち込むパラダイムシフト一言でいうなら、APIから特定のユースケース・コンテキストを排除することでクライアント・サーバーサイド双方の柔軟性を向上させたAPIのが特定のユースケース・コンテキストを持たない事でクライアントは利用出来る情報を最大限利用して柔軟なUIを構築し、ユーザーに最大の価値を届ける事が出来るサーバーサイドはバックエンド都合でドメインロジックを構築出来る逆に言うとGraphQLを使うとRESTはコンテキストフルなAPI(提供する前にレスポンス表現を固定する必要がある)で、それがクライアントのUI表現をいかに固定化させてきたか、バックエンドのアーキテクチャを固定化させてきたかに気づくことになると思います。ServerlessGraphQLの導入するタイミングGraphQLが向いてるケース変化・進化し続けるアプリケーション。HTTPの制約を受ける巨大なデータ転送には向いてないオブジェクト型の構造データが向いている非構造型データ、テーブル型のデータは向いてないおわりに冒頭であげた今年1年書いてきた記事をさらにまとめた仕上がりで1年のGraphQLの調査の成果を発表しました。機会があれば別の視点からGraphQLをお話したいと思います。2021年8月号にて、GraphQLの特徴や解決している問題、そしてGraphQLの基本動作原理(クエリ言語、型システム、実行エンジン)について29ページに渡って特集を寄稿しました。GraphQL/Nuxt.js/Vue.js/Next.js/React.js/TypeScript/Nest.js/Rails/Laravel/Azure合同会社春秋テックブログPublication合同会社春秋のテックブログです!バッジを贈って著者を応援しようバッジを受け取った著者にはZennから現金やAmazonギフトカードが還元されます。Proよくある質問LinksX(Twitter)GitHubメディアキットLegal利用規約プライバシーポリシ。