ソフトウェア開発PBLでGraphQLを導入した話

はじめに

この記事はFUN Advent Calendar 2020の8日目の記事です

adventar.org

余談

公立はこだて未来大学では学部3年になると必修授業で「プロジェクト学習」と呼ばれるPBL（Problem Based Learning）の授業があります。 この授業では各プロジェクトに与えられたテーマや課題をさまざまなコースの学生同士でチームを組んで1年間取り組みます。 学生主体で動くプロジェクトがほとんどで、その日の活動内容からプロジェクトの年間スケジュール、課題に対してのアプローチ方法まで全て学生が決めます（もちろん担当教員からのフィードバックはもらいますが..）。 どんなに開発が好きな学生もゲームが大好きな学生も3年生になるとプロジェクト学習の活動に全力を注ぎます。 少なくとも私の所属していたプロジェクトは睡眠時間よりもプロジェクトを優先していたような気がします。

そんなプロジェクト学習で私は「ミライケータイプロジェクト」と呼ばれるモバイルアプリケーションを対象とした新規サービスの企画・開発を行うプロジェクトに所属しました。 プロジェクトではプロジェクトリーダー兼バックエンド/インフラ開発を担当していました。

今回はミライケータイプロジェクトのバックエンド/インフラ開発事情について話たいと思います。

GraphQLを導入した経緯

プロジェクトのアプリケーション開発でGraphQLを導入した経緯を話たいと思います。 バックエンドの開発を進めていく上で2つの制約？がありました。

1. 同時に3つの新規サービスを開発しなければならない
2. モバイル開発班の負担はなるべく減らしたい

ミライケータイでは3つの新規サービスを同時に開発しなければならず、なおかつ開発期間はたったの2ヶ月だったためユーザー認証などの共通する機能はサービス間で共有して使えるように設計して開発工程を減らす工夫をしなければなりませんでした。 そこでバックエンド開発班ではマイクロサービスアーキテクチャを採用して、開発を進めました。

しかし、マイクロサービスアーキテクチャを採用することでエンドポイントやURLが煩雑になるという問題が発生しました。

図1のようにモバイルアプリケーションは複数のマイクロサービスにアクセスしなければなりません。 バックエンド班が最終的に作成したマイクロサービスは全部9つでURLは20以上あります。

図1. 複数のエンドポイント・URLを管理しなければならない

さらに、マイクロサービスの増加に伴いモバイルアプリケーション側から送らなくてはいけないリクエスト数も増加します。 ミライケータイはモバイル開発メンバーが20近くいるなか開発経験者が5人にも満たないプロジェクトですので、実装面でなるべくモバイル開発メンバーに負担はかけたくありません。

図2. GraphQLの導入によりエンドポイントが一つになった

そこで、ミライケータイでは マイクロサービスアーキテクチャ + GraphQL の構成にしました。

実際に開発してみて

開発の流れ

GraphQLを導入するにあたって以下のライブラリを使用しました。

github.com

モバイルアプリケーションがGraphQLに投げるリクエスト（クエリ）の型定義をしたスキーマを用意すればよしなにGo言語のコードを自動生成してくれる優れものです。

1. マイクロサービスの仕様を決定
2. マイクロサービスの仕様をもとにGraphQLでAPIのスキーマを作成
3. 1で作成したスキーマからコード自動生成ツールであるgqlgenを使用してアプリケーションの雛形を作成
4. クエリの処理を記述
5. GraphiQLでAPIをテスト
6. apollo-cliを使って、モバイルアプリケーション用のクエリの型定義ファイルを自動生成
7. リクエスト（クエリ）を投げる処理はモバイルに任せる
8. 実機でテスト

GraphQLを導入してよかったこと

1. レスポンスのフォーマットを自由に決められる

GraphQLはクエリをいじるだけでレスポンスのフォーマットを変更できます。 例えば、以下のようなクエリだと、ログデータのid一覧を取得することができますが

{
  logs{
    logs{
      id
    }
  }
}

以下のように変更するだけで、ログデータのidだけでなくタイトルやエラー情報まで取得できるようになります。

{
  logs{
    logs{
      id
      title
    }
    errors{
      code
      discription
    }
  }
}

モバイルアプリケーションの画面に応じて必要な情報を必要なだけとってこれるのは便利かなと。

2. ブラウザで動作確認が可能

これはApolloと呼ばれるフレームワークの機能？だと思いますがWebブラウザでクエリの動作確認ができます。 クエリが正しいか否かの確認をバックエンド開発班とモバイル開発班で共通のプラットフォームでできるのでよかったです。

あと、クエリに関するドキュメントもブラウザからみることができるので使いやすいです。

終わりに

プロジェクトの開発期間や開発メンバーの実力的にGraphQLはオーバースペックかなぁと懸念したんですが、実際に開発してみると案外なんとかなりました。 クエリ自体の学習コストも高くなく、モバイル班がクエリ作成して勝手にWebブラウザでテストできていたのでよかったです。 今回はプロジェクトのソフトウェア開発で使用しましたが個人開発でもガシガシGraphQLを使っていきたいと思います。

9日目はたつお君です。お楽しみに。