Our learnings from adopting GraphQL
https://gyazo.com/a16f82d9689cf446cd6c51be7babd307
メモ
マーケティングのフロントエンドシステムでGraphQLを使ってるらしい
ネットワーク帯域とREST API乱用による無駄なcallが問題だった
GraphQLを挟んでみた
Falcorも検討したがエコシステムやユースケースとのマッチングからGraphQLにした Pros
ネットワーク帯域が減った
8倍のパフォーマンスに
REST APIとGraphQL serverが同DC内にあるため早い
payload sizeが10MBが200KBに
latencyは若干劣ることもあるがpayloadのサイズを考えると十分お得
type definition
Schemaから各言語向けのclientを自動生成してる
テーブル定義から生成してる
DI/DX
どのデータをどのREST APIから取るか、どの順番でコールするかを考えるコストが減った
Cons
同じリクエストを送るresolverがあることに気づいた
キャッシュレイヤーを作って重複を減らした
https://gyazo.com/c4ffc67c82ebc24802430122cc9d630a
デバッグが面倒
クライアント側ではどのサーバが何でコケたのかわからない
デバッグフラグがあるときはGraphQLサーバで起きた全リクエストのデバッグデータをレスポンスに含めるようにした
面白いsota1235.icon
Passing around objects is what OOP is all about, but unfortunately, GraphQL throws a wrench into this paradigm. When we fetch partial objects, this data cannot be used in methods and components that require the full object.
わからない
感想
Pros/Cons納得感ある
Proxy server的なoverheadあると想像してたけど同DC内だとあまり影響がないのは学び
Backendできちんと設計していかないとボトルネックが移るだけになる
この例だとresolver向けのキャッシュの話とか