Hasura とは何者か メリット・デメリット

Transcript

1. Hasura とは何者か メリット・デメリット 2020/08/27 GraphQL Tokyo Meetup #10 shinnoki (@konoki_nannoki)
2. 自己紹介 shinnoki (@konoki_nannoki) - WASD Inc. CTO - デジちゃいむ https://digichime.com/ というサービスを開発しています - Hasura / React / React Native - なりゆきで Hasura を本番投入したので 日本に布教しないと詰むマン
3. Hasura 概要 - 正式名称は Hasura GraphQL Engine - だけど今回は Hasura って呼びます - 2019/12 に v1.0.0、現在 v1.3.1 - PostgreSQL から GraphQL API が生えてくるやつ - MySQL 対応も開発中らしい - GraphQL リクエストを 1 つの SQL に変換して DB に投げる - バックエンドと DB 間の N+1 問題は原理的に発生しないのでパフォーマンスが良い - SQL としてのパフォーマンスまではわからない - JWT ベースの認証認可 - Websocket を使った GraphQL Subscription - 中身はイベントベースではなく Live Query
4. GraphQL 界隈における Hasura
5. vs Prisma (間違っていたらすみません ） - GraphQL 自動生成系のくくりでよく比較される - 実際に Prisma v1 はサーバーを立てる必要があり割と似ていた - Prisma v2 は ORM ライブラリっぽい感じ - Prisma は裏方だが Hasura はリクエストを直接受ける前提 Frontend Database Server Prisma Frontend Hasura PostgreSQL graphql-yoga / Apollo Server/ GraphQL Nexus など MySQL / PostgreSQL
6. Schema First vs Code First Schema First - Apollo Server, gqlgen など - メリット - スキーマに従ってフロントエンド、バックエンド を並行して実装できる - スキーマを設計してしまえば、バックエンドも codegen の恩恵を得られる - デメリット - 自分たちで GraphQL スキーマを設計するに は知識が求められる - スキーマ設計を誤ると後から実装しづらいこと に気づく Code First - graphql-ruby, TypeGraphQL, Nexus など - メリット - ライブラリに従っていれば知識がなくてもある 程度ベストプラクティスに沿ったスキーマにな る - デメリット - フロントエンドはバックエンドの実装を待つ形 になる
7. GraphQL 界隈での Prisma, Hasura の立ち位置 - Prisma は Model First (勝手に命名) - Schema First の発展型 - Model を定義すると CRUD を自動生成してくれるので設計の負担が少ない - AWS Amplify CLI とかも同じ感じ - Hasura は Database First (勝手に命名) - Code First の発展型 - あくまで定義するのは PostgreSQL のテーブル - 開発スタイルは Code First と同じだが DB と密結合で App 層が極限まで薄い - graphql-codegen と組み合わせると DB の定義をフロントまで引っ張ってこれる！！ - ここまで徹底しているのは唯一無二？ - どちらも Schema First や Code First の弱点を補っている
8. mBaaS 界隈における Hasura
9. 現代 Web 開発に求められるもの - 新規開発においてブラウザ/ネイティブアプリ両対応と リアルタイム通信は初期要件になくても必ず話に出てくる - なるだろうなと思ったら実際そうなった - なんとか回避するか、頑張って実装するかの二択 - Firebase や AWS Amplify などの mBaaS を使うと比較的楽にこの要望を叶えられる - つらみも多い - Hasura も mBaaS (の DB) っぽい使い方ができる - 複数クライアント対応しやすい GraphQL API - GraphQL Subscription によるリアルタイム通信 チャット つけられる？ Webと アプリ両方 できるよね
10. cf) 3factor App - Hasura 社が提唱しているアーキテクチャパターン https://3factor.app - Realtime GraphQL, Reliable eventing, Async serverless - The Twelve-Factor App とはレイヤーも違うしちょっとイキリすぎ
11. Firebase vs AWS Amplify vs Hasura Firebase AWS Amplify Hasura 動作環境 マネージド マネージド Docker コンテナ / マネージド (Hasura Cloud) 認証 Firebase Authentication Amazon Cognito 任意の JWT 認証 (Auth0, Firebase Authentication, AWS Cognitoなど) / Webhook 認証 データベース NoSQL (Cloud Firestore / Realtime Database) NoSQL (Amazon DynamoDB) RDB (PostgreSQL) クライアント gRPC (Firebase SDK) GraphQL (Amplify SDK / AppSync SDK) 任意のGraphQLクライアント
12. mBaaS 界隈での Hasura の立ち位置 - Docker で動かせる - docker-compose を使って気軽にローカル環境を立てられる - デプロイ先の選択肢が多い - データベースが PostgreSQL - RDB のノウハウをそのまま流用できる - スキーマがあるので設計に秩序を保ちやすい - Rails と Hasura で同じ DB を参照するとかもできる - Firestore や DynamoDB に比べてしまうとスケーラビリティは - 金で殴れば毎秒100万回の更新を100万ユーザーが受け取れるらしい https://github.com/hasura/graphql-engine/blob/master/architecture/live-queries.md
13. デモ（時間があれば）
14. 実際使ってみて
15. Hasura のデメリット - 実装の中身まで把握するには Haskell がわかる必要がある - ビジネスロジックが最初から複雑な場合メリットは少ない - パーミッションが複雑になるとしんどい - フィールド名が snake_case なのは受け入れる必要がある - 設定でフィールド名を上書きできるが設定の手間より受け入れたほうが楽 - 日本語の情報が少なすぎる！！
16. もし Hasura が流行ったら - Database First な開発 - Foreign Key 制約や Not Null 制約をはじめ PostgreSQL の機能をフルに使う必要があるので、 データベースを設計できるエンジニアが重宝される - 嫌われがちな SQL Function や Database Trigger が見直される世界線があるかも ...？
17. Follow Me shinnoki (@konoki_nannoki) - 最近ひたすら Hasura 成分多めです - 時間あるときは木曜朝にもくもく会やってます - 少しでも Hasura に興味が湧いたらぜひフォローください！ - みんなも Hasura 使って！！