GraphQLのAPI基盤としてHasuraを使う3つの理由
2021-06-25
#はじめに
今回は、Hasura GraphQL Engineについてご紹介します。
GraphQLのAPI基盤としてHasuraを使う3つの理由と題して、Hasura, GraphQLを簡単に紹介しつつ、なぜHasuraが私たちにとってベストチョイスなのか記載します。
#Hasura GraphQL Engineとは
Hasura is an open source service that gives you production-grade APIs on your data without having to build, operate & scale a GraphQL server.
出典: Hasura
簡単に訳すと、ビルドすることなく、GraphQLサーバーを運用・スケールする、プロダクショングレードのAPIを提供するオープンソースのサービスとのこと。
特徴については、後述します。
#GraphQLとは
GraphQL（グラフQL）はAPI向けに作られたクエリ言語およびランタイムである。
ウェブAPIの開発に、RESTやその他のWebサービスと比較して、効率的、堅牢、フレキシブルなアプローチを提供する。GraphQLでは、クライアントが必要なデータの構造を定義することができ、サーバーからは定義したのと同じ構造のデータが返される。したがって、必要以上に大きなデータが返されるのを防ぐことができクエリの効率が良い。
FacebookのGraphQLの記事では、なぜGraphQLが開発されたのか背景を知ることができます。
Facebookがスマートフォンアプリに最初に取り組んだのはHTMLベースで動作するWebViewベースであったがネイティブアプリに書き換えたことは、当時大きなニュースになったのをおぼえています。Facebookのモバイルアプリがより複雑になるにつれて、パフォーマンスが低下し、頻繁にクラッシュしました。これらの問題を解決するために、より効率的なデータフェッチが必要となり開発されたのがGraphQLだとわかります。
#関心事
GraphQLをプロダクションに適用してみて、スキーマ定義とサブスクリプションによる効率的なリアルタイム通信は、モダンアプリケーション開発に適合することを知って、私は、GraphQLのファンになりました。さらにHasuraは、GraphQLサーバーの構築を自動化してプロダクショングレードを提供してくれるので、私は、すぐにHasuraのファンになりました。
- スキーマ定義・明瞭なAPI
スキーマ定義によって、特にベネフィットを受けるのは、APIクライントだと思います。
QueryLanguageといわれているように、このコンセプトはRESTful APIのそれとは、異なります。
RESTfulAPIの定義はリンクを参照していただくとして、単純化するとRESTfulAPIはAPI設計における原則・規範ではあるけど、スキーマではありません。これを補完するためには、OpenAPIがあります。OpenAPIは、明瞭なAPI定義を実装するよう表現することができます。GraphQLは、API設計における原則からスキーマまでカバーしていると思います。重要なのは、API定義が明瞭であることなので、極論、OpenAPIでも良いじゃないかと言われればその通りです。
スキーマ定義があると、GraphQLに限らず、OpenAPIでもAPIサーバー・クライントのコードを自動生成することができます。経験上、OpenAPISpecからAPIサーバー・クライントのコードを自動生成している開発現場にジョインしたことがありません。なぜ自動生成しないのかを聞いたことがありますが、その答えは、OpenAPIからコードの自動生成はしばしばうまく動かないからだそうです。ただ個人的にコード自動生成には大いに賛成です。APIを実装しなくてもAPIを作ることができないかが関心事となりました。
- 自動化
近年のRPA, NoCodeの流れ、またIaC、Kubernetesも抽象的に共通しているのは自動化です。それらは、コンピュータが自動生成できるようスキーマが決まっていて、そのスキーマの通り宣言ファイルなどを読み込むことによって、コンピュータによって自動生成されたり、自動的に運用されます。
自動化は、ヒューマンエラーを低減し、生産性を高めることに役立ちますから、多くの組織で自動化が関心事です。
Hasura GraphQL Engineのアプローチは、DBスキーマを読み込んで、提供するデータのテーブルを指定するだけでGraphQLAPIスキーマ及びその実装まで自動的に提供されます。これが画期的なアプローチで、自動化のニーズを満たしてくれます。本当に早くて簡単なCRUD APIを作るのに5分とかかりません。興味があれば、ぜひ、Quick Startを試してください。
- プロダクショングレード
GitHubは彼らのAPIをGraphQLで提供を始めたのが、2017年のようです。GraphQLはすでに一級市民でした。GraphQLのサービスを探し始めたのは、2018年頃でした。当時は、Prisma, Graphcool, GraphCMSを試しました。いずれもニーズを満たしませんでした。
Prismaは、自分でHostingできます。
GraphQLのデータモデルを記述することで、自動的にDB上にテーブルが作成されCRUD操作ができます。この仕様は、私には合わなかったです。Prismaでは依存関係がDBスキーマがAPIに依存するとなります。データ中心で設計をしようとすると、最初にデータモデリングをしてからAPIを設計するので逆のAPIがDBスキーマに依存するとなる。
Graphcool, GraphCMSは、マネージドサービスです。DBに直接アクセスできるわけではなく、マネージドサービスであるという点でも柔軟性にかけます。カジュアルな用途では、適合するかもしれません。
上記の理由から、Prisma, Graphcool, GraphCMSは私のニーズを満たしませんでした。その後、Hasuraを発見しました。Hasuraは上記の問題を解決し、ベストチョイスとなりました。
#Hasuraを選ぶ理由
- 柔軟性
Hasuraは、Dockerイメージが公開されているので、自分でHostingすることもできますし、HasuraCloudというマネージドサービスを利用することも出来ます。
Auth機能をつかってFirebaseAuthやAuth0などのAuthenticationサービスと連携したり、Actions, Event Triggersをつかってビジネスロジックを実装することも出来ますので、拡張性も良いです。
DevOpsも考慮されており、MetadataやDB MigrationをCICDに組み込むこともできます。
- ノーコード
最低限必要なことは、DBスキーマが適用されたDBだけです。提供したいテーブルをGUIから指定するだけで利用することが出来ます。
もちろん、アクセスコントロールが必要なアプリケーションでは、更に権限設定などが必要になります。設定を行うだけなので、ノーコードです。これらの機能を個別に開発するより圧倒的に時間と労力を節約できます。具体的には、設計・開発・テストにかかるコストを削減できます。（統合テストやE2Eテストは必要ですが。）
- 将来性
GitHubのStar数は、投稿時点で23K以上獲得しているので、開発者からの支持は絶大です。
サポートしているDBの種類は、PostgreSQLが中心的ですが、SQL Serverなど、いくつかサポートされ始めました。
また、MySQLやElastic, MongoDBなどがComing Soonとなっており、今後の拡張が期待できます。
運営しているHasura, Inc.は、資金調達を実施済みで開発者のみならず、投資家からの期待も厚いです。選定する技術が適切にメンテナンスされることは重要です。
#まとめ
Hasuraが私達にとって、ベストチョイスである理由を紹介しました。
今回、特定のトピックに焦点をあてているので、Hasuraの魅力を全てお伝えできませんが、Hasuraを選ぶ理由について記載しました。
HasuraCon'21がつい先日開催されましたが、コミュニティーも成長しているので、今後の成長に期待したいと思います。
