未知の道に突入せず、まずは半分知ってるくらいの状態になる

Perl製アプリケーションからGraphQLを喋ってみたい、ということがあって昨年末に2週間くらいでプロトタイピングしていた。
CPANにGraphQLというライブラリが公開されていて、社内の利用実績もあるので、これをいきなり使ってみても良かったのだけど、自分はGraphQLについては、耳では知っていて、GitHubのAPIを呼び出したことがある、くらいで、実際に実装したことはなかった。
このような状態で突き進むと、問題に遭遇したときに2パターンの怪しさが出てきて、切り分けていくことになる。未知のものが多すぎて、プロジェクトXの、トンネルを掘るだけで難しいのに現地の言葉はわからない、みたいな回をイメージしてください。

• GraphQL自体への理解が間違っているパターン
  • スキーマ、クエリの書き方が悪い、概念を勘違いしている、など
• PerlでのGraphQLライブラリの使い方が間違っているパターン
  • アプリケーション側の実装が悪い、ライブラリの仕様を勘違いしている、など

前者に関してはPerlと関係なく対処できる問題なので、まず前者に十分な理解をしてから後者を始めよう、と、いきなりPerlでやってみるんじゃなくて、ちょっと遠回り外回りして、半分知ってるくらいの状態になってからPerlで練習することにした。プロジェクトXでいうと、まずは最強トンネル掘りマシンを買ってくるか、まずは現地の言葉を学ぶか、という話。

本を読む

遠回りでもなんでもないけど、初めてのGraphQLを読んだ。最終的には公式情報にあたることになるのだけど、議論のとっかかりとしては、公式サイトのこのページ、という案内よりは、本の何ページ、みたいに参照できるほうが扱いやすいし、電子書籍がある本はチームメンバーにも紹介しやすい。
O'Reillyのサブスクでも読めるようになったのでサブスク入りましょうってチームメンバーにもおすすめしている。ACM経由で入会するとACMの雑誌も毎月送られてくるのでぱらぱら眺めている。
O'Reillyのサブスクでは本はPDFがダウンロードできたりはせず、ブラウザでスクロールすることになる。ページという単位から開放されて章単位でスクロールするだけなので速く読めて気に入っている。

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

Node.jsで練習する

いきなりPerlで練習せずに、まずはNode.js用のApollo Serverでサーバーサイドの実装の練習してみることにした。
初めてのGraphQLで紹介されていたので真似して書けば動きそうだったことと、ドキュメントが充実していて、困ってる人がいたらリポジトリのissueとかブログとかで困りごとが紹介されているので、対処しやすそうと思ったため。
www.apollographql.com

あとから使いたくなりそうな、適当なスキーマを定義して実装を進めた。

• あとでPerlから喋りたくなるようなスキーマ(たとえば、マンガビューワを作っていたら、作品があって、話があって…みたいな)を定義してみて
• Resolverからは、既存のJSON APIを叩いたりRSSをスクレイピングしたり、情報をかき集めて返す
  • 要件によっては、Backends for Frontendsとして、新たにNode.jsのGraphQLサーバーを立てて終わり、という方針も考えられる

これをやったら、こういうときのクエリはこう書くんだな、とか分かって便利だった。
それに加えて、Perlで練習するときに使えそうな成果物がいくつか手に入った。

• スキーマは言語を問わず使える
  • このときはCustom Directiveの存在を知らなかったので、@cacheControlとか書いておらず、そのまま再利用できた
• GraphQLの呼び出し手順の知識
  • IDEから呼び出すとか、ドキュメントはここに表示される、とか

クライアントサイドのメンバーと話す

自分はサーバーサイドの実装のプロトタイピングをしていて、それを呼び出すクライアントサイドのメンバーも同時期にクライアント側のプロトタイピングをしていた。
同じ本を読んでも読み飛ばす箇所が違っていて、自分はサーバーサイドの実装に関心があって、クライアントサイドは軽く流していたけど、クライアントサイドのメンバーはクライアントサイドでのキャッシュの仕組みとかに関心があるので、関心分野をうまく分担できて素早くキャッチアップできていた。
時間があったら全部一人でやると完璧な理解を得られるとは思う。

ここまできたらPerlで練習してみる

わからないことはPerl用のライブラリの知識だけになったので、PerlのコードベースにGraphQLのライブラリを追加して実際の練習を始めた。
スキーマは言語を問わず使えるので、Apollo Serverに読ませて動いていたスキーマをPerlから読んでみて、同じ結果を配信することを目標に進めていた。
PerlあるあるでUTF-8周りのエンコーディングをミスってスキーマが文字化けしてしまうことがあった。そのような場合に、ファイルがおかしいかアプリケーションの実装がおかしいかと考えると、Apollo Serverでは扱えてたのでファイルの中身は問題なく、ファイルの読み方が問題だ、とすぐに切り分けられる。

サーバーサイドは二人でやっていたのだけど、プロトタイピングだから、とResolverをフラットな1ファイルに書いてみたら、同時に触るとめちゃくちゃコンフリクトして、このファイル構成ではチーム開発に向いてないので、もし本採用するときには、ここは手抜きせずにファイルを分けたほうがよい、ということが分かったりした。動くかどうかの確認だけでなくて、チームで手分けして開発できることの確認もできたのでよかった。

半分知ってる状態になる

最初からきっちりPerlで調べながら進められていれば、Node.jsでやってみる必要なかったじゃん、とも思えそうだけど、分かっていることを増やして、わからないことを明らかにする、という点では有用だったと思う。
未知の問題とぶつかって進まなくなったときには、この情報がわかってれば半分くらい分かった状態になれる、ということを探してみると良いかもしれません。コンパイラを作ると気にいきなりセルフホストで作るよりは、まずは別言語で書いたほうが楽、みたいな話かもしれない。