前回までのあらすじ
「CRUD API 自動生成」でググったらHasuraについての記事を見つけた。
不思議なもので、それまではHasuraについての記事を読んでもほとんど理解できなかったのに、「サーバー側のAPIを自動生成してくれそうなツール」という先入観を持てたおかげで、Hasuraを理解することは驚くほど簡単だった。
この記事に辿り着いたような奇特な諸兄姉には釈迦に説法だとは思うが、Hasuraの簡単な説明をすると、
DBのスキーマからGraphQLサーバーを良い感じに自動で構築してくれるツール
である。
更にここにHasura Cloudというサービスを加えると、
ブラウザでポチポチとDBのテーブル作るだけで、GraphQLサーバーも自動で出来上がるサービス
となる。
ここで言う「GraphQLサーバーが出来上がる」というのは、APIも何もかも揃った状態のGraphQLサーバーがWebに公開されている状態のことである。
なにそれすごい。
Hasura Cloudというのは簡単に言えばGraphQL用サーバーを提供してくれるHasura公式のサービスだ。
ありがたいことに無料プランもある（データ転送1GB/月、リクエスト60回/分まで）。
Hasura Cloudに登録してポチポチしたあとは、開発者がすることはフロントのHTML/JavaScriptを作って、適当なレンタルサーバーに置くことだけだ。
サーバーとDBはHasura Cloudが作ってくれるのだから。
正確に言うとDBだけは自前でPostgreSQLサーバーを立てる必要がある。ただ、Hasura CloudのコンソールからHeroku Postgresを立てることができるので、それを利用すると手軽である。
なお、Herokuは最近全ての無料プランを廃止してしまったので、今回のDBには無料プランのあるElephantSQLというサービスを採用した。
ただし、当時は知らなかったので仕方ないが、bit.ioやCockroachDB serverlessといった魅力的なDBaaSも登場しているので、今から作るならそちらを使った方が良いだろう。
Hasuraに出会って軽い衝撃を受けたが、それでも最初はその実力を疑っていた。
確かにDBのスキーマからサーバーを自動で、コードを書かずに構築してくれるのはすごい。
だが、それゆえに細かいこと（カスタムロジック）をやろうとすると余計な手間がかかるのは明白だった。
実際、Hasura Cloudでカスタムロジックを実行しようとすると、Actionsと呼ばれる機能を使う必要がある。
Actionsを使うとCRUD時にHTTP経由で自由なロジックを実行できるが、利用にはAWS Lambdaなどの外部サービスが必要になる。
正直これは手間だし、メンテも大変そうだ。
だが、Hasuraに触れていくうちに、在庫管理システムなら実装次第で組めそうだと感じた。
それはHasuraというよりもGraphQLの恩恵によるものだった。
そもそも、なんでカスタムロジックのような細かいコードが必要だと信じていたかというと、REST APIをずっと使ってきた経験則からだった。
REST APIはRDBのCRUDと相性が良いとは言えない。だからサーバー側でその間を取り持つようなコードをAPIごとに書かなければいけなかった。
しかしGraphQLはREST APIよりいくらかRDBと相性が良い。
そのため、Hasuraの優秀な自動生成ロジックのおかげもあり、簡単なアプリケーションならカスタムロジックを書かなくてもなんとかなることがあるのである。
結果的に在庫管理システムはカスタムロジックなしでなんとかなってしまった。
（いくらか諦めた機能はあるが）
Hasura Cloudに初めて登録したときに話を戻して。
Hasura Cloudというサービスを知って、試しに「在庫管理システム用のDB」という想定でポチポチしてみた。（新しいサービスに触れるときは、なんでもいいから具体的な使用方法を想定しながら進めるのが良いと個人的に思っている）
ポチポチしていると、いつの間にかGraphQLサーバーも出来上がっていた。
さすがにサーバー側の設定作業も何かしら必要なんだろうなと思っていたら、特にそんな必要はなく、試しにGraphQLのAPIを外から叩いてみたらデータが取得できたのでビビってしまった。
実はDBのスキーマを設定している際に「これTrackしてね」という控えめなメッセージが出ていてそれに従っていたが、どうやらあれが唯一必要な設定のようだった。（HasuraのRelationshipsというやつ）
とはいえ私が特別にやったことといえばそれくらいで、DBのテーブルを作っただけで、あとは全部Hasuraがやってくれたのだ。あとやることはフロントを作ることだけである。
正直最後まで作るつもりはなかったが、ここまで来たらもったいない精神でフロントも作らざるを得なくなってしまった。
ここまで書いて力尽きてしまったので、フロントについては簡単な説明で。
GraphQLのクライアントにはApollo Clientを採用した。
キャッシュ周りが丁寧に作られていて、そのままでも便利でありながら、柔軟に設定も変えられて好印象だった。
その他の技術周りはTypeScriptとReact、ReactRouter、ReactFinalForm、MaterialUI、Emotionという「個人的モダン環境」に加え、テーブルを表示したかったのでTanStack Table（旧React Table）を採用した。
TanStack Tableはテーブルやデータグリッドを作るのに必要な機能をヘッドレスで提供してくれるライブラリである。ヘッドレスなのでデザインはこちらで作る必要があるが、その分自由なスタイリングが可能になる。
テーブルでありがちな機能（並び替えとかバーチャル行とか）は網羅されつつ、カスタマイズの幅も広く中々の好印象。
ただ自由な使い方が出来る分、書き方はちょっと冗長な感じも（一応v8に上がって若干シンプルになった）。
バージョンアップが頻繁にあるためか、ドキュメントはちょっと不親切。
総括すると、慣れるまで時間はかかるが、慣れてしまえばこっちのもんタイプのライブラリである。
デザインは恥ずかしいくらいMaterial UIもろだしである。
デザインセンス（とデザインにやる気をかける情熱）が欲しい。
フロントは静的ファイルしかないので、レンタルサーバーに置いて公開中。
認証方法はHasura側でも色々できるが、使うのが私一人だけというのと、機密情報が入るわけではないので、楽をしてBASIC認証をかけるくらいにしている。
そんなこんなで在庫管理システムが出来上がり、作ってから２カ月くらい経った今も元気に稼働中で、エンジニアの私が健気に在庫管理してるというわけである。
おしまい。