ダイニーでプロダクトマネージャー兼ソフトウェアエンジニアを担当している長谷川(@hassey_11)です。

事業のラウンドも順調に進み会社の規模も拡大していく中で、開発チームとしても積極的に開発体制や環境について情報を公開していくべく、エンジニアリングブログに力を入れていきます！

第5回目となる今回は、「ダイニーといえば Hasura」「Hasura といえばダイニー」と言われている(?)、Hasura に関する記事です。

ダイニーの開発における Hasura の利用内容の紹介をしつつ、直近で行ったプロダクトごとに異なる GraphQL スキーマファイルを生成する方法について紹介します。

ダイニーでの Hasura を用いた開発

第2回の記事のとおり、ダイニーでは Hasura を用いたモノレポ環境で開発を行っています。

具体的には以下のようなことを Hasura を経由して行っています。(2021/5 現在)

1. クライアントアプリケーションからの RDB データ取得
・Read only という制約の元、ファイルのダウンロードなどの例外を除いたほぼ全てのデータ取得を Hasura への Query もしくは Subscription で行っています

2. クライアントアプリケーションから GraphQL バックエンドサーバへの接続 (Hasura Remote Schemas) およびクライアントが参照する GraphQL スキーマファイル生成
・RDB に変更を伴う Mutation などは、Hasura Remote schemas による stitching でバックエンドサーバーにプロキシしています
・また stitching を元にクライアント用の GraphQL スキーマ定義ファイルを生成しています

3. RDB のマイグレーション
・Hasura の Migrations 機能を用いて、GUI console から直接 RDB スキーマを閲覧・編集し、マイグレーションを行っています

開発チームの規模や事業フェーズの変化に伴い前提条件が変わるため、最適な Hasura の利用方法も変わってくると思うのですが、直近のダイニーの開発では以上のように Hasura を活用しています。

今回の記事では、2 のクライアント向け GraphQL スキーマ定義ファイルの生成に関してお話します。

プロダクトごとに異なる GraphQL スキーマ定義ファイルを生成する

Hasura には、権限ごとにアクセスできる RDB のテーブルおよびカラムを制御するロールベースのアクセス制御機構が備わっています。ダイニーではロールを各プロダクト（エンドユーザ向けモバイルオーダアプリ、店舗スタッフ向けハンディなど）のアカウントごとに分けることで、プロダクトごとにアクセス可能なテーブルおよびカラムを定義しています。

認証に JWT トークンを利用している場合は、トークン情報からも権限制御を行えます。

これらの設定が全て GUI で設定でき、コードベースで管理可能な点も Hasura の魅力の一つです。

また、さらに便利なことに Hasura からクライアントアプリケーション用に GraphQL のスキーマ定義ファイルを生成する際には、ロールを指定することでアクセス可能な領域のみを抽出した GraphQL スキーマを取得することが可能です。

GraphQL スキーマの取得には npm の get-graphql-schema パッケージを利用しており、例えば以下のようなコマンドによって、"customer" ロール向けの GraphQL スキーマの生成が行えます。

get-graphql-schema -h 'X-Hasura-Admin-Secret="シークレットキー"' -h 'X-Hasura-Role=customer' https://${hasuraUrl}/v1/graphql > ./hasura/schema-customer.gql

ダイニーではコードの変更があるたびに CI で GraphQL スキーマの変更を確認し、全プロダクトで graphql-codegen によるコード生成と型チェックを行っています。

これまではモノレポという特徴を活かして、単一のスキーマファイルを生成、シンボリックリンクで各プロダクトが同一ファイルを参照し GraphQL コード生成を行っていました。

しかし、プロダクトごとに実際にアクセス可能な Table 定義とスキーマファイルにズレがあることが原因で、型チェックは通るがステージング環境での実行に失敗する、という事象が発生していました。

そこで、この記事で紹介したようなロールごとのスキーマファイルの生成を行い、上記のような事象を抑え更に開発効率を高めることに成功しました。

そのほかにも、 例えば tables.yaml ( Hasura のテーブル定義・権限管理を記したファイル ) の変更差分が見づらいなどの細かい課題がありますが、Hasura config v3 にて設定ファイルの分割が可能になったり、Pull Request 上でのプレビューできる GitHub extension が公開されたりと、Hasura 自体の改善が日々進んでおり、そのような実運用に関わる問題に関しても積極的に修正を行ってくれているため、安心して開発・運用を進めていくことができています。

最後に

今回はダイニーでの Hasura を用いた開発について簡単に紹介しつつ、直近行った開発効率向上のために利用した Hasura の機能を紹介しました。

これ以外にも様々な課題やその対応を日々模索しているのですが、総じて Hasura は非常に使い勝手が良く満足しています。

月末に行われる Hasura Con について、弊社主催で振り返りイベントを行うので、是非ご参加ください！