Meetup #6 GraphQL Tokyo Summer がFiNCにて開催されました
技術開発本部の qsona (twitter: @qsona) です。
GraphQLに関してのユーザコミュニティである GraphQL Tokyo のMeetup #6が行われ、FiNCがスポンサーとして会場・食事・飲み物の提供を行いました。
GraphQL TokyoのMeetupはオープンスペース方式で、各セッションでGraphQLに関するテーマを1つ取り上げて少人数で議論していきます。どのセッションも議論に花が咲き、とても盛り上がりました！
共同主催者の joe_re さん, Yosuke Kurami さん, mtsmfm さん, taiki-t さん, 素晴らしい会をありがとうございました。ユーザコミュニティの運営は継続的な熱意が必要で大変だと思います。GraphQLの日本への普及に大きな役割を果たしていて、頭が下がる思いです。私個人としては2回目の参加でしたが、2回とも新しい学びがとても多かったです。
参加者の皆様も、熱い議論をありがとうございました！
会場の様子
調理は弊社の管理栄養士 mizuki.umeda が担当してくれました。最近はエンジニアにキャリアチェンジしていて、当日は少しリリースが忙しそうな中、協力していただきとても助かりました。
料理の写真を取り忘れたのですが、主催のみなさまがtwitterに上げてくださっていました。心遣いを感じて有り難い限りです 🙏
最後に集合写真を撮らせていただきました！
セッションの内容
セッションは3並列で開催されていて、一部しか参加できなかったのですが (特にAppSyncの話は聞きたかったが他の良いセッションとかぶってしまい残念！)、聴くことができた内容を紹介します。
graphql-rubyのAnalyzer API
Yusuke Mito さんによるセッションで、 graphql-rubyの Analyzer API を利用してvalidationなどを挟む事例でした。いくつか具体の例を挙げられています。
Analyzer APIを使ってconnectionフィールドのfirstまたはlast argumentを必須パラメータにする
Make Operation Name required by Analyzer API
個人的には、これまでASTを使ってなにか処理するユースケースがパッと思い浮かぶわけではなかったので、実例をいくつか見せてもらえたのは良かったです。このレベルを上手く扱えると実装の幅が広がるなと感じました。パフォーマンス要件などちょっと込み入ったことをやろうとすると必要になると思うので、覚えておきたいと思います。
Yusuke Mito さんは先日 graphql-ruby コードリーディング というブログを書かれており、こちらも深い内容です。(個人的にはgraphql-rubyのコードを読みに行ってきちんと理解できないまま挫折しているので、再度チャレンジしたいです)
GraphQLのテストについて
筆者 qsona が行ったセッションです。APIをテストする際、通常(RESTなど)であればAPIが返す値(JSONなど)全体をチェックすることができますが、GraphQLの場合はクエリによってネスト度合いが変わり、どこまでも深くネストさせてテストするのは現実的ではないため、どうするか？という課題感について話しました。
これに対し、同一階層のフィールドと1段階深いネストのidフィールドだけチェックすることや、各resolverの事前条件として正しいobjectが渡ってきていることをassertionで担保するアイディアなど、有用な意見をいただきました。
また、こちらからは Consumer-Driven Contract という考え方と、 Pact を利用して実践するという考えを話しました。どんなクエリに対してもテストを書くことを諦め、クライアントが実際に使うクエリに対して正しく動くことをテストしよう、という考えです。(これを話す前の議論ですでに参加者の方から Pact という単語が出て、驚いたとともに、同じ考えに至る方がいたことに嬉しく思いました。)
これについていくつか意見も頂きましたが、特に、GraphQL自体がSchemaを担保しているのでやや役割が重なる部分があるという指摘があり、実践的にかなりその通りだなと思っています。ややオーバースペックになりがちかもしれません。
スポンサーセッション
FiNCがBFF (Backends for Frontends) としてGraphQLを採用した事例について話しました。かなり前に一度 Node学園にて話した内容、なかなかうまく現場で定着しなかったこと、新しいBFFのアーキテクチャを進めていること ( 本ブログ記事 もご参照ください ) を話しました。スポンサーセッションも小さなカンファレンス形式として、フィードバックを色々頂きました。
BFFとしてのGraphQLにはかなり期待する向きがあることを感じました。実際に、組織の構造など場合によっては非常に有効になりそうですし、上手く選択がはまって成功する事例も出てくれば嬉しいと思います。このテーマについては懇親会等も含めて色々な意見を頂き、改めて振り返りながら考えることができました。
Prisma について
共同主催者の一人 joe_re さんによるセッションで、 Prisma について実際のコード例を交えながら解説していただきました。
ここで私が下手な説明を書くよりも、読者の方には公式サイトを見ていただいたほうが良いかと思うのですが、簡単に言うと、GraphQLのサーバのバックエンドとしてGraphQLクエリを利用できるデータストアがあり、利用側はO/R Mapperが使えるという感じに理解しています。さらにそのバックエンドには現在MySQLとPostgreSQLが利用でき、今後選択肢が増える予定とのことです。
データストアに対してGraphQLクエリを投げられるというのは面白くて、GraphQLでのAPIサーバを実装するときにデータストアとのミスマッチがなくなるので、開発がしやすくなるように思います。RailsのActiveRecordのように非常に賢くリレーションを定義できるものがなくても良くなるので、例えばNode.jsのような非同期処理が得意な言語などでGraphQLサーバを作りやすくなるのではないでしょうか。試してみたい技術です。
最後に
FiNCではこういったユーザコミュニティを支援していく活動を今後も積極的に行っていきます。GraphQLという技術は今後FiNCでも重要になると考えており、今回スポンサーを申し出させていただいた次第です。
勉強会などを開催される方、会場貸しやスポンサーなどでご協力できることがありますので、ぜひ気軽にご相談ください。
さて、FiNCはもちろん、GraphQLに興味があるエンジニアを募集しています。ぜひ、 Wantedly 等で気軽にお声がけ下さい！
