GraphQL
APIで使用するための問合せ言語の仕様そのものを指す
特定のフレームワーク、ライブラリを指すわけではない
2015/7に仕様が公開された
こんせぷと
実装
clientとserverに使用するLibraryは同じものを使う必要はない
そもそも片方にしか用意されていないものもある
両方用意されているものは同じものを使ったほうが楽なのかな #??
Debugするやつ
実装によって個別に用意されているやつもある
>#WIP
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が置かれる感じになるのか
たしかに
返り値のエイリアス
普通に書くとこんな感じの時、
graphqlquery liftsAndTrails {
liftCount(status: OPEN)
allLifts {
liftName: name
status
}
}返り値は、
liftCount と allLifts というkeyを持ったJSONになるがこれはschemaの定義と同じ
これをkeyを書くことで取得時に好きなように変えられる
graphqlquery liftsAndTrails {
open: liftCount(status: OPEN)
chairlifts: allLifts {
liftName: name
status
}
}keyは、
open と chairlifts になるqueryの結果をfilteringする
Selection setの中のkeyに対して指定する
graphqlquery closedLifts {
allLifts(status: CLOSED) {
name
status
}
}短所
クライアントで必要な分以上にデータを取得している状態
関連
とは #??
GraphQL Server側でやっていた自動生成SQLの非効率さの改善とか？
GraphQLでレスポンスを返してくれるHeadlessCM
CDN for graphQL
どういうサービスに向いているのか
チームの規模がクソデカの時に向いている
LSUDsと呼ぶらしい
large set of unknown developers
対はSSKDs
small set of known developers)
フロントエンドが複数のデータソースにアクセスしている
フロントエンドで複数のプラットフォームのアプリケーションが存在する
サーバーサイドがMicroservicesで実装されている
既存のアプリケーションを変更なしにモダンなフロントエンドを実装したい
フロントエンドでGraphQLを利用して実装したい
Rust実装で、wasmにcompileされる
採用者の声
github
なぜ採用したか
議論
nextjs
GraphQLのドキュメンタリー
tsの型生成