もうAPIを自分で開発するのは古い？Hasuraの強烈な有効性について紹介する
今回伝えたいこと
- Hasuraの有効性を伝える
- 開発工数の削減効果
- 柔軟性の高さ
- セキュア
「開発工数の削減」という課題
昨今のエンジニアの不足や単価の上昇により、開発工数を十分に確保できない課題がある。どこの会社も開発工数を減らすために色々な策を講じているのではないか。
- 新技術の活用
- 慣れた技術の利用
- プロセスの見直し
- 徹底した自動化
- スコープの見直し
- 過剰品質をやめる
などなど。今回は一番上の「新技術の活用」によって開発工数を削減できる可能性があるのではないかということを提案する。
こんなアプリを作ることになったとする
仮にあなたがこんなアプリを作ることになったとする。
シンプルなオンラインホワイトボードツールで以下のような機能があることが必要
- 付箋に文字を書ける
- 付箋を動かせる
- 付箋の色がユーザ固有の色になる
- 付箋を消せる(自分の作った付箋だけ)
- 付箋の位置、内容などをリアルタイムに共有できる
- ボードを切り替えることができる
- Cognitoでログインできる
バックエンドで必要な開発は以下
以上の機能を開発するためにバックエンドは次のような開発が必要になる。
DB
- テーブル設計 (Board, Noteの２テーブル)
API
- ボードに紐づく付箋一覧の取得(websocketで最新の値を配信する)
- 付箋の追加 (CognitoのユーザIDと紐付けてCreate)
- 付箋のテキストやポジションの更新
- 付箋の削除(自分が作成したもの以外はエラーになるように)
インフラ
- Fargate/ECSへのデプロイ
- Cognito連携
だいたいどのくらいの工数で見積もりますか？
「バックエンドのみ + テストは不要」だとして、単純に実装して動くものを作ればいいというケースだったとしたら、どれくらいの期間であなたなら見積もるか？
① 1時間
② 1日
③ 1週間
④ 1ヶ月
Hasuraなら１時間でできる
実際に、筆者が上記のアプリのバックエンドを開発した際は1時間で完成している。
なぜこのような劇的な工数削減ができたかというとHasuraを使ったからだ。
４つの機能を紹介する。
① APIの自動生成
Hasuraはテーブル定義から自動でGraphQL APIを生成する。
柔軟な検索ができるクエリメソッドや、Create, Update, Deleteなども自動生成され、シンプルだが十分なCRUDができる。
② Cognito連携
HasuraはWebhookとJWTによる認証手段を提供している。
AWS Cognitoを使ってJWTによる認証を簡単に実装可能。他にもAuth0やfirebase authenticationなどとも当然連携可能。
③ アクセスコントロール
APIの実行者のRoleごとに実行できるメソッドを制御することができる。
JWT内のユーザIDやグループIDを参照してアクセスコントロールを記載可能で、例えば「CreatedByがユーザIDが一致する場合のみ、Delete可能」などの制限をかけることができる。
④ Subscription
SubscriptionはWebsocketベースのリアルタイムなクエリで、監視しているリソースが更新されると自動で最新の値を配信する。
インターフェイスはQueryと一緒なので非常に使いやすい。
これらの機能で開発工数を大幅削減
今回の開発で実際にやった作業はこれだけ
- DB作成
- Cognito連携
- アクセスコントロール設定
- Copilotを使ってECSへデプロイ
これらは慣れれば１時間程度の作業で完遂できる。よって単純なCRUDのAPIであれば大幅な開発工数削減が見込める。
Hasuraへの懸念
上記を読んで、以下のような懸念を抱いた人もいるのではないか。
① ビジネスロジックはどこに記述するのか？
② フロントエンドでGraphQLを使いたくない。RESTがいい。
③ バージョン管理などの開発環境はどうなる？
それぞれについて対応を記載していく。
① ビジネスロジックをどこに記述するか
Hasuraは「Actions」と「Remote Schema」という２つのオプションを提供している。
Actionsは上記の画像のように、Websocketで一旦別のHTTP endpointに処理をパススルーしてからクエリを実行する。カスタムロジックを処理するウェブサーバやLambdaを用意してカスタムロジックを記述することができる。
Remote Schemaは完全に別のGraphQLサーバを自分で作ってしまい、Hasuraとスキーマを結合してしまうというもの。Apolloなどでビジネスロジックを処理するGraphQLサーバを構築して不自然なくHasuraと結合することができる。
② フロントでGraphQLを使いたくない
Hasuraにはクエリを登録してREST API化させる機能あり
バックエンドはGraphQL、フロントはRESTで開発可能
③ 開発環境はどうなる？
Hasuraのメタデータ(アクセスコントロールなど）は全てDBに保存されるので、開発者は同じ開発環境のDBを見ていた方が良い。
HasuraはECSに配置し、ELBのIP制限をかけて開発者のみがコンソールにアクセスできるようにする。
メタデータはExportできるのでGithubで管理可能 / 本番環境への適用も可能。
結論: Hasuraは実践投入の検討価値あり
Hasuraはひとことで言うと「フロントから呼べるSQLクライアント」
実際、HasuraはGraphQLの木構造をモデル化しSQLに変換することを内部の実装で行っている。
要するにこれは今までのバックエンドをすっ飛ばしていることに等しい。
簡単なCRUDはHasuraに任せれば大幅な開発工数削減が可能であると考えられる。
Discussion