GraphQLとRDBMSのいいとこ取りをしたHasura

Takeshi Amano
4 min readJul 28, 2018

--

ここ最近web業界でアンテナを立ててる人ならGraphQLを聞いたことはあると思います。

REST APIとGraphQLの違い

これまでJavascriptで書かれたwebアプリやネイティブアプリがバックエンドのデータベースと通信するにはRESTという言う仕組みを使って通信してきました。

RESTの場合バックエンドエンジニアが実装したendpoint経由で裏で走っているデータベースと通信することになります。

なのでアプリを作っている際にはデータベースと何をするにもバックエンドエンジニアにendpointを作ってもらう必要があり、これが工数を余計に増やしてしまいます。

GraphQLはデータベース側にスキーマを定義するとそこに対して直接データを取りにいけるようになるため、バックエンドエンジニアにendpointを作ってもらう必要が無くなるという触れ込みです。

またGraphQLのメリットとして、欲しいデータだけを指定したり、テーブルをjoinしたものを欲しいデータとして指定すればまとめて返ってくるというものもあります。

出典: https://dzone.com/articles/graphql-benefits-in-a-rest-api-but-how

他にもGraphQLのメリットとしてキャッシングとかあるのですが、それは今回の記事では扱いません。

まだまだ新しいGraphQL

なんとなくGraphQLのメリットは理解してもらえたと思うのですが、GraphQLで実装するのはなかなかめんどくさいのです。

これまで出てきたGraphCool / PrismaやAppSyncなどのGraphQLの扱えるサービスはあったのですが、MySQLやPostgresなどのRDBMSに慣れている人(天野もそうです)からするとこんな事もできないの?というのが多くありました。

  1. 集合関数がない
    SQLの世界ならお馴染みのCOUNT()やGROUP BYですがGraphQLにはありません。なのでresolverというクエリする際に使う関数の中で再実装する必要があります。
    ランダムに結果を返すMySQLのRAND()も無いです。
  2. 副問い合わせもできない
    SQLバリバリ書く人ならSELECT文の中にもうひとつSELECT入れたりなどの副問い合わせ書く事もあるかもしれませんが、そういう事もGraphQLではできません。

確かにGraphQLはRESTに無いものを提供していますが、SQLでやるほど事細かにデータを指定して取ることはできないんです。そりゃ70年代からやってるRDBMSに勝てる訳はないんですが…

GraphQLとRDBMSのいいとこ取りをしたHasura

そんなこんなでGraphQLのソリューションを探していたんですが、HasuraというPostgresをバックエンドにしたサービスを見つけました。

https://hasura.io/

データベースにはPosgresを使うことで、RDBMSの良さを活かしながらGraphQLを使うことができるようになっています。

HasuraのコンソールからテーブルなどをPostgresのスキーマ内に作るだけでGraphQLでアプリからデータを取得できるようになります。

先ほどできないと言っていた集合関数や副問い合わせもviewをPostgresのスキーマ内に作ることでGraphQLから呼べるようになります。

これまでのGraphQLの実装はNoSQLを使っているものも多かったのでNoSQLのデータ構造に合わせる必要がありましたが、HasuraではRelationalにスキーマを組めばいいのでその辺も楽。

Postgresのスキーマがすでにある場合は簡単なインポート作業をするだけでHasura経由でGraphQLが使えるようになるとの事。

やっとGraphQLを使ってまともなアプリ作れるような気がしてきました。

これからHasuraを使ってアプリを爆速で作れるようになるでしょうね。今後の展開が楽しみです。

--

--

Takeshi Amano

広島出身、アムステルダム在住。レガシーシステムをPWA化したり、Jamstackで遊んだりしてます。最近はProduct Managementの勉強してます。