GraphQL
APIで使用するための問合せ言語の仕様そのものを指す
特定のフレームワーク、ライブラリを指すわけではない
2015/7に仕様が公開された
こんせぷと
実装
clientとserverに使用するLibraryは同じものを使う必要はない
そもそも片方にしか用意されていないものもある
両方用意されているものは同じものを使ったほうが楽なのかな #?? Debugするやつ
実装によって個別に用意されているやつもある
GPT-4.icon
Operation
subscription
reqもresも型安全である
Self-documenting(自己文書化)である
TypeScriptと相性が良い
要求した通りのresが返るためover fetchにならない
「このendpointはこの塊を返す」というのをclientは知らなくていい(覚えなくていい)
型安全
読むと良いらしい
読むと良いらしい
GitHubにShopifyという2大Public GraphQL APIに関わってきたMarc-André Giroux氏でさえGraphQLはPublic APIで使うべきではないと考えてるのか…… むしろそれらに関わってきたからこそ、なのかな
tutorialとか、実行のお試し
お試しできるやつ集
modelingする場合は、サーバー側にEntityが置かれる感じになるのか
たしかにmrsekut.icon
返り値のエイリアス
普通に書くとこんな感じの時、
code:graphql
query liftsAndTrails {
liftCount(status: OPEN)
allLifts {
liftName: name
status
}
}
返り値は、liftCountとallLiftsというkeyを持ったJSONになるが
これはschemaの定義と同じ
これをkeyを書くことで取得時に好きなように変えられる
code:graphql
query liftsAndTrails {
open: liftCount(status: OPEN)
chairlifts: allLifts {
liftName: name
status
}
}
keyは、openとchairliftsになる
queryの結果をfilteringする
code:graphql
query closedLifts {
allLifts(status: CLOSED) {
name
status
}
}
短所
クライアントで必要な分以上にデータを取得している状態
関連
GraphQLでレスポンスを返してくれるHeadlessCM
どういうサービスに向いているのか
チームの規模がクソデカの時に向いている
large set of unknown developers
small set of known developers)
フロントエンドが複数のデータソースにアクセスしている
フロントエンドで複数のプラットフォームのアプリケーションが存在する
サーバーサイドがMicroservicesで実装されている
既存のアプリケーションを変更なしにモダンなフロントエンドを実装したい
フロントエンドでGraphQLを利用して実装したい
Rust実装で、wasmにcompileされる
採用者の声
github
なぜ採用したか
議論
nextjs
https://www.youtube.com/watch?v=783ccP__No8
GraphQLのドキュメンタリー
tsの型生成