GraphQLとは
- Facebookが策定・リファレンス実装してる
- WebAPIの設計及び規約＆問い合わせのためのクエリ言語
- つまりRESTの親戚
RESTとの違い
- RESTはあくまでリクエストのインターフェース定義
- 守ればRESTを知ってる人はだいたい分かる
- レスポンスの形式が定まっている
- RESTでいうメソッドは2種類
- Query
- Mutation
- フロントとサーバサイドでかち合わない（欲しいものはフロントで足せばOK）
- いらないフィールドは取得しないのでネットワーク帯域を圧迫しない
- 複数のリソースが必要な場合でも1リクエストで複数のクエリを処理できる
- リソースのネスト
- 定義だけしちゃうとかなり楽に処理してくれる
実装を見てみる
- サーバ：リソース定義
- サーバ：リゾルバ実装
- クライアント：bodyにクエリをぶち込んでリクエスト
- 欲しい項目をクライアント側で絞れる
- fragmentでまとめられる(id,name,email)
サポート状況
- 大体の言語でサポートされてる
- nodejs,ruby,java,python,php,go…
- nodejsが本家なので活発
- バックエンドを好きな言語で実装したAppサーバにすると良い感じ？
- サーバ間はgRPCなんか使ったりするとモダン？
データ定義
- あらかじめスキーマを定義する
- リソースモデリングの粒度、データ構造は？
- データとしての項目とロジック・UIに必要な項目
- DDD
- トップレベルのオブジェクトのみを返せる、他の情報もIDで引っ張れる
- ORM、リレーショナルデータベースの使い所がない
- NoSQLの出番
- 高度な検索が必要ならRDBと併用すると良い
設計について
- 書き込み系処理はとても複雑
- DDDでコンテキストや依存関係を分けてもなお大変
- 読み込み系は条件絞ってデータ返すだけ
- コマンドクエリの責務分離とドメイン駆動設計を組み合わせて考えると良い
- CQRS
技術選択時の判断基準
- 最初は良いけど、規模が大きくなってくると化物
- その時点で何を求められているか
- スタートアップなら実装スピード
- バージョン2で実行パフォーマンス＆堅牢性＆シンプルな実装を求められている場合
- GraphQLにもだめな部分はあるのよ
業務で使って失敗した話
- 調査時
- RESTと開発コストはあんまり変わらない
- レスポンスの形を決められるってすごくね
- 触ってみた結果
- スキーマを書いてリゾルバを実装してコミットの流れで作業したらフロントと食い違う
- クエリフィールドを全て記述した結果コードの行数がめちゃくちゃ増えた
- とあるユーザのコメントにいいねしている人のアカウント名が欲しい！
- user{comments{like{user{name}}}}
- ベタで実装すると死
- クエリとミューテーションがややこしい
- どうするべきだったか
- スキーマの合意を最初にやる
- Fragmentをうまく使おう
- トップレベルのオブジェクトさえ返せば後は良い感じにしてくれる
- readとwriteでディレクトリごとバッサリ切った
- ついでにRxJSを採用してwrite系をすっきりさせた
- 1つの処理から分岐できる
- レスポンスを返す、メールを送る、などなど
まとめ
- ファイルのやりとりはRESTAPIにしたほうがいい
- Dateの型定義がないので自分で作る（死を）
- 規模の大きくて継続的な開発をする案件に向いてる
- 追加開発に強い、けどディレクトリ設計とかちゃんとしないとあとでキツくなる
