Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
Hasura とは何者か メリット・デメリット
Yudai Shinnoki
August 28, 2020
Programming
10
2k
Hasura とは何者か メリット・デメリット
Yudai Shinnoki
August 28, 2020
Tweet
Share
More Decks by Yudai Shinnoki
See All by Yudai Shinnoki
AWS “““触って””” みた
shinnoki
0
61
体に馴染む開発環境 ~ghqはいいぞ~
shinnoki
0
940
組織戦略と GraphQL、Hasura
shinnoki
2
3.7k
TypeScript と React Hooks と GraphQL のステキな関係性
shinnoki
2
350
リリース前に知りたいネイティブのあれこれ
shinnoki
0
1k
外部委託の立場から半ば強引にLaravelを導入した話
shinnoki
0
530
Other Decks in Programming
See All in Programming
Swift Observation
shiz
3
270
SHOWROOMの分析目的を意識した伝え方・コミュニケーション
hatapu
0
240
Most Valuable Bug(?) ~インシデント未遂から得た学び~
tatsumiakahori
0
150
Amebaブログの会員画面システム刷新の道程
ryotasugawara
1
230
PHPDocにおける配列の型定義を少し知る
shimabox
1
130
Findy - エンジニア向け会社紹介 / Findy Letter for Engineers
findyinc
2
42k
Remix + Cloudflare Pages + D1 で ポケモン SV のレンタルチームを検索できるアプリを作ってみた
kuroppe1819
4
1.3k
Git Rebase
bkuhlmann
10
1.2k
はてなリモートインターンシップ2022 フロントエンドブートキャンプ 講義資料
hatena
0
120
PHPアプリケーションにおけるアーキテクチャメトリクスについて / Architecture Metrics in PHP Applications
isanasan
1
230
Prácticas de Seguridad en Kubernetes
pablokbs
0
120
OSC大阪 パスワード認証は人類には早すぎる ~ IDaaSを使ったソーシャルログインのすすめ ~
authyasan
7
1.3k
Featured
See All Featured
What the flash - Photography Introduction
edds
64
10k
VelocityConf: Rendering Performance Case Studies
addyosmani
317
22k
The MySQL Ecosystem @ GitHub 2015
samlambert
240
11k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
239
19k
Art, The Web, and Tiny UX
lynnandtonic
284
18k
YesSQL, Process and Tooling at Scale
rocio
159
12k
Why You Should Never Use an ORM
jnunemaker
PRO
49
7.9k
Raft: Consensus for Rubyists
vanstee
130
5.7k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
318
19k
Ruby is Unlike a Banana
tanoku
93
9.5k
Producing Creativity
orderedlist
PRO
335
38k
The Mythical Team-Month
searls
210
40k
Transcript
Hasura とは何者か メリット・デメリット 2020/08/27 GraphQL Tokyo Meetup #10 shinnoki (@konoki_nannoki)
自己紹介 shinnoki (@konoki_nannoki) - WASD Inc. CTO - デジちゃいむ https://digichime.com/
というサービスを開発しています - Hasura / React / React Native - なりゆきで Hasura を本番投入したので 日本に布教しないと詰むマン
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
GraphQL 界隈における Hasura
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
Schema First vs Code First Schema First - Apollo Server,
gqlgen など - メリット - スキーマに従ってフロントエンド、バックエンド を並行して実装できる - スキーマを設計してしまえば、バックエンドも codegen の恩恵を得られる - デメリット - 自分たちで GraphQL スキーマを設計するに は知識が求められる - スキーマ設計を誤ると後から実装しづらいこと に気づく Code First - graphql-ruby, TypeGraphQL, Nexus など - メリット - ライブラリに従っていれば知識がなくてもある 程度ベストプラクティスに沿ったスキーマにな る - デメリット - フロントエンドはバックエンドの実装を待つ形 になる
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 の弱点を補っている
mBaaS 界隈における Hasura
現代 Web 開発に求められるもの - 新規開発においてブラウザ/ネイティブアプリ両対応と リアルタイム通信は初期要件になくても必ず話に出てくる - なるだろうなと思ったら実際そうなった - なんとか回避するか、頑張って実装するかの二択
- Firebase や AWS Amplify などの mBaaS を使うと比較的楽にこの要望を叶えられる - つらみも多い - Hasura も mBaaS (の DB) っぽい使い方ができる - 複数クライアント対応しやすい GraphQL API - GraphQL Subscription によるリアルタイム通信 チャット つけられる? Webと アプリ両方 できるよね
cf) 3factor App - Hasura 社が提唱しているアーキテクチャパターン https://3factor.app - Realtime GraphQL,
Reliable eventing, Async serverless - The Twelve-Factor App とはレイヤーも違うしちょっとイキリすぎ
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クライアント
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
デモ(時間があれば)
実際使ってみて
Hasura のデメリット - 実装の中身まで把握するには Haskell がわかる必要がある - ビジネスロジックが最初から複雑な場合メリットは少ない - パーミッションが複雑になるとしんどい
- フィールド名が snake_case なのは受け入れる必要がある - 設定でフィールド名を上書きできるが設定の手間より受け入れたほうが楽 - 日本語の情報が少なすぎる!!
もし Hasura が流行ったら - Database First な開発 - Foreign Key
制約や Not Null 制約をはじめ PostgreSQL の機能をフルに使う必要があるので、 データベースを設計できるエンジニアが重宝される - 嫌われがちな SQL Function や Database Trigger が見直される世界線があるかも ...?
Follow Me shinnoki (@konoki_nannoki) - 最近ひたすら Hasura 成分多めです - 時間あるときは木曜朝にもくもく会やってます
- 少しでも Hasura に興味が湧いたらぜひフォローください! - みんなも Hasura 使って!!