hello GraphQL

ここ を参考にやってみた。
howtographql のサイトは先日見た GraphQL meetup で紹介されていた。

前提

GraphQL はデータベースとうまくやりとりするための技術ではない。
API のためのクエリ言語。そのため、API とやりとりするあらゆる場面で効果的に利用することができる。

少しいじってみた所感

今回見てみた見てみたリポジトリは gqlgen と mysql のサンプルだったが、データ取得のinfra 層は柔軟に変えられるというのがわかった。
つまり、接続先がDBだろうがAPIだろうが定義したモデルにしっかりバインドしてあげればクエリに応じてよしなに返してくれる。
なのでクエリがほしいフィールドは一つでも、サーバ側はモデルに定義されたデータに値を入れるというのをライブラリに渡す前までは行っている。
ライブラリは指定されたクエリに応じてデータのフィルタリング処理を行ってくれるっぽい。
これは、mutation も同様で永続化したいパラメータ + 返り値にほしい値を指定しておけばよい。 同接クライアント多いかつ、結構でかいデータやりとりすること多いとメモリはもったいないのかもしれない。
まぁこの辺は全然札束でスケールする範囲かと思うけど。

いい点

GraphQL を BFF に置くのはありかも。以下思ったこと。

• 後段の API サーバはリソースをきれいに返しておけばよい。

  • aggregation を GraphQL にやらせる想定

• クエリが実質 document になると思うので api の管理は楽になるかも

  • バックエンドのリソースサーバをgrpcにすれば更に管理楽になるかな
  • REST だとswagger は必須そう
• エンドポイントが一つだし、クライアントが好きにデータとれるから api がクライアントのバージョンによってデータの出し分け気にしなくて済むのはよい。

気になる点

• 配信用の長期間キャッシュしてもよいデータの扱い。ETag のようないい感じのキャッシュ機構をクライアント側でよしなにやってくれるのか。

• mutation やるなら認可をどう扱っていくのか

  • ちょっと想像つかないのでエンプラ領域だと mutation はやらず REST で書き込み系はやったほうがいいのかなー

まだ運用したことないから↑は想像でしかないのだけど。

展望

クエリくらいから小さく始めてみたいな。
あとは、バックエンド API をリソースを返すだけに特化させていきたい。

その他

今回いじったリポジトリ