Meetup #8 GraphQL Tokyo 2019 Summer のまとめにもならない参加メモ
はじめて GraphQL関係の勉強会「Meetup #8 GraphQL Tokyo 2019 Summer」に参加してきたました。
セッションはオープンスペースという形式で参加者から募集したトピックと投票によって決定します。初めてだったんですが、事前にスライドの準備などはなく、ライブで進んでいくのが新鮮で面白かったですねー。
全部で4セッション（2セッション X 前半後半）で、私は「マイクロサービスのサービス間通信で GraphQL を使うのは他の手法と比べてどうかの議論」と「SDL first or code-first ? https://www.prisma.io/blog/the-problems-of-schema-first-graphql-development-x1mn4cb0tyl3」に参加しました。
以下、勉強会が終わったあとに、思い出すままに書いているざっくりしたメモの走り書きです。正直ついていくだけでめちゃくちゃハードだったので、まとまってもいないです。
マイクロサービスのサービス間通信で GraphQL を使うのは他の手法と比べてどうかの議論
@mtsmfm さんの社内での展開も含めた課題感からの議論
現在社内ではgRPCでマイクロサービスを構成している → Why?
・今まではRESTで実装されていたが、API Spec的な仕様の共有方法も無く、つらみが多くなっていた
・gRPCというよりも、ProtocolBufferがほしかった。 → これによって、クライアントサイド・サーバーサイドの実装がスキーマから生成できて、楽になるんじゃない？ みたいなところを狙っていた
・でも、gRPCは仕様的にちょっとネックポイントがある → メインがProtocolBufferによるSpecの共有観点ならばGraphAPIもありなんじゃない？ というのが今回の話の流れ
なぜgRPCはネック？
HTTP2 → 社内のインフラがHTTP1前提で構成されていたのでgRPCを採択するにあたって、かなり手を加えなければいけない
gRPCリッチすぎ →「Unary」「Server streaming」「Client streaming」「Bidirectional streaming」とあるけど、プロトコルの要件的にそこまで高機能を求めていない。
ProtocolBufferの型ゆるくない？ → 特にオプション周りがゆるすぎ感
他のスキーマファーストもどうなのよ？
OpenAPI（Swagger）
JSON Schema
などなど。（RAMLもか）（あまり話にはのぼらなかった）
ProtocolBufferが大事なら、ProtocolBuffer＋HTTP1という手もいいんじゃないの？
（なんかツールの名前を話していた気がするが思い出せない）
（でもそれなら、OpenAPI（Swagger）・RAML・JSON Schemaという手もあるよね？）
rejoinerというアプローチもあるよね
gRPCを束ねて、GraphQLのサービスを提供する仕組み
https://github.com/google/rejoiner
（API Management系のサービスでもよくあるパターンか。SOAP→RESTへのプロトコル変換 バックエンドのAPIリクエストを束ねるタイプのもの的な）
でも GraphQL の仕様的にマイクロサービスに向かなくない？（結論的な）
GraphQLの思想的にネストされたリソースや複数リソースを効率的に取得する、UIベースのクライアントサイドで処理しやすいような取得を求められるケースが多い。
そもそもRPC的なアプローチが多いと考えると、GraphQLでマイクロサービスを実装した場合、全部Mutationを使うことになりそうじゃない？ とか。（私的意見）
マイクロサービスの文脈だと、もっと固定的（？なんて表現したらいいんだろう）な処理が多くなりそうだから、GraphQLの特性を活かしきれないのではないか？
SDL first or code-first ? https://www.prisma.io/blog/the-problems-of-schema-first-graphql-development-x1mn4cb0tyl3 スキーマファーストかコードファーストか
Prismaの中の人がスキーマファーストに問題があるよーみたいな話をしているけれど、それって実際どうなのよ？ というのを議論したい
そもそも、PrismaはPrisma1でスキーマファーストいいよ！ って言っていた立場じゃないの？ そこからリゾルバの生成とDBのスキーマ生成もやってなかったっけ？
ただし、ライブラリ・ GraphQL as a Service の人たちのBlogなので、ポジショントーク的なところも意識しながら読む必要あり。
上記Blogでは、以下のスキーマファースト問題点がピックアップされていたので、それをベースに話をしました。
Problem 1: Inconsistencies between schema definition and resolvers
Problem 2: Modularization of GraphQL schemas
・GraphQLは公式の仕様として、ファイルのモジュール化をサポートしていないよね？ という話
・でも、Prismaが拡張仕様としてgraphql-importを出して、他のライブラリなどもそれに追従しているのが流れ
・大量のスキーマを一ファイルで管理するのは得策ではない。だから、スキーマファーストは厳しいよね？ という話だが→果たして本当にそうなのか？ ファイルを分けて、あとでマージするのを内部で行ってもいいんじゃない？ とか。
・確かにコードファーストでクラスファイルライクにモジュール分割できれば楽だけど、コードファーストのスキーマ表現力にはまだ各言語ごとの実装に不足がある？とか
・コードファーストにしてしまうと、GraphQLのスキーマから各言語ごとのスキャンフォールディングした実装を生成するのが困難になっちゃうよね、とか
・スキーマファーストでカスタムLinterを定義して、そのカスタムLinterも共有できるようにしたいよね（なるほど）
Problem 3: Redundancy in schema definitions (code reuse)
Problem 4: IDE support & developer experience
・そもそもスキーマファイルってIDEで実装する際はプレーンなテキストファイルとしか認識されないよね？ →で もVS CodeとかでシンタックスハイライトやLinterが出てるんだから、小さな問題じゃない？
