Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Hasuraってナンダ!?
Search
ikuma-t
February 10, 2023
Programming
1
530
Hasuraってナンダ!?
Biz系のメンバー/Hasuraを使ったことのないメンバーへ向けた、Hasura社内勉強会の資料です。
ikuma-t
February 10, 2023
Tweet
Share
More Decks by ikuma-t
See All by ikuma-t
Make Impossible States Impossibleを 意識してReactのPropsを設計しよう
ikumatadokoro
0
800
いまさらのStorybook
ikumatadokoro
0
660
これで最後にしたい! Astroと立ち向かう 6度目の個人ブログ再開発
ikumatadokoro
5
1.5k
Panda CSS と Ark UI ではじめる個人開発
ikumatadokoro
4
2.2k
見た目から始める生産性向上
ikumatadokoro
11
5.8k
ぼくが 美容師さんに伝えたかった バンドの話
ikumatadokoro
0
260
Railsアプリをコスパよく読むための環境整備
ikumatadokoro
2
1.1k
HTTPを手で書いて学ぶ ファイルアップロードの仕組み
ikumatadokoro
80
31k
たどころくん1号を支える技術
ikumatadokoro
1
290
Other Decks in Programming
See All in Programming
NEWT Backend Evolution
xpromx
1
170
CLI ツールを Go ライブラリ として再実装する理由 / Why reimplement a CLI tool as a Go library
ktr_0731
3
950
AIコーディングエージェント全社導入とセキュリティ対策
hikaruegashira
15
9.3k
[DevinMeetupTokyo2025] コード書かせないDevinの使い方
takumiyoshikawa
2
250
React は次の10年を生き残れるか:3つのトレンドから考える
oukayuka
41
16k
대규모 트래픽을 처리하는 프론트 개발자의 전략
maryang
0
110
Gemini CLIの"強み"を知る! Gemini CLIとClaude Codeを比較してみた!
kotahisafuru
3
920
DatadogのArchived LogsをSnowflakeで高速に検索する方法(Archive Searchでオワコンにならないことを祈って) / How to search Datadog Archived Logs quickly with Snowflake (hoping Datadog Archive Search doesn’t make this obsolete)
civitaspo
0
110
Git Sync を超える!OSS で実現する CDK Pull 型デプロイ / Deploying CDK with PipeCD in Pull-style
tkikuc
4
520
No Install CMS戦略 〜 5年先を見据えたフロントエンド開発を考える / no_install_cms
rdlabo
0
430
Bedrock AgentCore ObservabilityによるAIエージェントの運用
licux
8
560
Understanding Kotlin Multiplatform
l2hyunwoo
0
250
Featured
See All Featured
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.6k
Bash Introduction
62gerente
614
210k
Statistics for Hackers
jakevdp
799
220k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
Automating Front-end Workflow
addyosmani
1370
200k
4 Signs Your Business is Dying
shpigford
184
22k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
283
13k
Being A Developer After 40
akosma
90
590k
Navigating Team Friction
lara
188
15k
Rails Girls Zürich Keynote
gr2m
95
14k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
Transcript
社内勉強会 Hasuraってナンダ!? 〜なんとなくを脱却するためのHasura勉強会〜 2023/02/10 14:30~15:00 @ google meet
よくある光景 よくある光景 そうっすね、 Hasuraはフロントエンド とデータベースの中継役 みたいなやつなので、関係あります この機能ってHasura関係 あるんだっけ? PM エンジニア
よくある光景
空想上の生き物みたいなHasura 毎回同じようなやり取りしている... ここを共通認識にして コミュニケーションコストを下げたい
この勉強会のゴール Hasuraが何をしているのか理解する! 作業にHasuraが影響するのか 判断できるようになる!
目次 A8 Hasuraの役0 &8 Hasuraのニガテなこ! 8 Hasura ConsoleとDB管 48 サービスとしてのHasur"
É8 まとめ
1 Hasuraの役割
このChapterのゴール アプリケーションにおいて Hasuraがどういう役割を 担っているのか理解しよう!
そもそもWebアプリってどうやって作るんだっけ? サーバサイド(バックエンド) ・複雑な処理や外部に見せたくない処理を実行する ために必要 ・サービス運営側の管轄になる データベース ・ユーザーのデータを保存するために必要 ・SQLしかしゃべれないので、アクセス時には翻訳が
必要 画面(フロントエンド) ・ユーザーが操作するために必要 ・ユーザー側で動くので危ない処理や重たい処理には 向いていない API SQL いろいろあるけど、だいたいこんな感じ APIはお仕事を依頼するための窓口 SQLはデータを取得するための言語
実際にこの構成で作ってみると...? サーバサイド(バックエンド) ・複雑な処理や外部に見せたくない処理を実行する ために必要 ・サービス運営側の管轄になる データベース ・ユーザーのデータを保存するために必要 ・SQLしかしゃべれないので、アクセス時には翻訳が
必要 画面(フロントエンド) ・ユーザーが操作するために必要 ・ユーザー側で動くので危ない処理や重たい処理には 向いていない API SQL 1 データベースのテーブルを 追加・変更する (だいたい) バックエンドの人 はあっ!
実際にこの構成で作ってみると...? サーバサイド(バックエンド) ・複雑な処理や外部に見せたくない処理を実行する ために必要 ・サービス運営側の管轄になる データベース ・ユーザーのデータを保存するために必要 ・SQLしかしゃべれないので、アクセス時には翻訳が
必要 画面(フロントエンド) ・ユーザーが操作するために必要 ・ユーザー側で動くので危ない処理や重たい処理には 向いていない API SQL 1 データベースのテーブルを 追加・変更する 2 ロジックとデータベースへの 接続処理を書く できたわ バックエンドの人 フロントエンドの人 (だいたい) バックエンドの人 OK はあっ!
実際にこの構成で作ってみると...? サーバサイド(バックエンド) ・複雑な処理や外部に見せたくない処理を実行する ために必要 ・サービス運営側の管轄になる データベース ・ユーザーのデータを保存するために必要 ・SQLしかしゃべれないので、アクセス時には翻訳が
必要 画面(フロントエンド) ・ユーザーが操作するために必要 ・ユーザー側で動くので危ない処理や重たい処理には 向いていない API SQL 1 データベースのテーブルを 追加・変更する 2 ロジックとデータベースへの 接続処理を書く 3 APIとしてフロントエンドに 公開する できたわ バックエンドの人 フロントエンドの人 (だいたい) バックエンドの人 OK
実際にこの構成で作ってみると...? サーバサイド(バックエンド) ・複雑な処理や外部に見せたくない処理を実行する ために必要 ・サービス運営側の管轄になる データベース ・ユーザーのデータを保存するために必要 ・SQLしかしゃべれないので、アクセス時には翻訳が
必要 画面(フロントエンド) ・ユーザーが操作するために必要 ・ユーザー側で動くので危ない処理や重たい処理には 向いていない API SQL 1 データベースのテーブルを 追加・変更する 2 ロジックとデータベースへの 接続処理を書く 3 APIとしてフロントエンドに 公開する 4 APIを利用してデータを取得 ・更新する画面を実装 できたわ バックエンドの人 フロントエンドの人 (だいたい) バックエンドの人 OK は あ っ !
実際にこの構成で作ってみると...? サーバサイド(バックエンド) ・複雑な処理や外部に見せたくない処理を実行する ために必要 ・サービス運営側の管轄になる データベース ・ユーザーのデータを保存するために必要 ・SQLしかしゃべれないので、アクセス時には翻訳が
必要 画面(フロントエンド) ・ユーザーが操作するために必要 ・ユーザー側で動くので危ない処理や重たい処理には 向いていない API SQL 1 データベースのテーブルを 追加・変更する 2 ロジックとデータベースへの 接続処理を書く 3 APIとしてフロントエンドに 公開する 4 APIを利用してデータを取得 ・更新する画面を実装 できたわ バックエンドの人 フロントエンドの人 (だいたい) バックエンドの人 OK は あ っ ! テーブル変更のた び に 毎回 これやる必要が あ る APIができる ま で 、 フロントエンドは 待ち が 発生 する
最近はフロントエンドはPC・モバイルとかいろいろあったりするので、 待ちが発生すると、それら全部の開発に影響出るね yb テーブルの変更のたびに、APIを実装する必要があるV Sb APIが実装できるまで、フロントエンドに待ちが発生する。 APIをバックエンド側で実装する場合の課題
やっと登場 この課題を解消するのが 『Hasura』
Hasuraで作ってみると...? Hasura ・フロントエンドとデータベースの仲介役 ・データベースの情報から自動でAPIを生成する ・真ん中のアイコンはなぜか「Lambda」 データベース ・ユーザーのデータを保存するために必要 ・SQLしかしゃべれないので、アクセス時には翻訳が 必要
画面(フロントエンド) ・ユーザーが操作するために必要 ・ユーザー側で動くので危ない処理や重たい処理には 向いていない API SQL 1 データベースのテーブルを 追加・変更する バックエンドの人 フロントエンドの人 (だいたい) バックエンドの人 はあっ!
Hasuraで作ってみると...? Hasura ・フロントエンドとデータベースの仲介役 ・データベースの情報から自動でAPIを生成する ・真ん中のアイコンはなぜか「Lambda」 データベース ・ユーザーのデータを保存するために必要 ・SQLしかしゃべれないので、アクセス時には翻訳が 必要
画面(フロントエンド) ・ユーザーが操作するために必要 ・ユーザー側で動くので危ない処理や重たい処理には 向いていない API SQL 1 データベースのテーブルを 追加・変更する 2 ロジックとデータベースへの 接続処理を書く 3 APIとしてフロントエンドに 公開する バックエンドの人 フロントエンドの人 (だいたい) バックエンドの人 はあっ! Hasuraが自動でやってくれる!
Hasuraで作ってみると...? Hasura ・フロントエンドとデータベースの仲介役 ・データベースの情報から自動でAPIを生成する ・真ん中のアイコンはなぜか「Lambda」 データベース ・ユーザーのデータを保存するために必要 ・SQLしかしゃべれないので、アクセス時には翻訳が 必要
画面(フロントエンド) ・ユーザーが操作するために必要 ・ユーザー側で動くので危ない処理や重たい処理には 向いていない API SQL 1 データベースのテーブルを 追加・変更する 2 ロジックとデータベースへの 接続処理を書く 3 APIとしてフロントエンドに 公開する 4 APIを利用してデータを取得 ・更新する画面を実装 バックエンドの人 フロントエンドの人 (だいたい) バックエンドの人 はあっ! Hasuraが自動でやってくれる!
Hasuraを使うと... データベースからAPIを自動生成するので アプリがめちゃ速く作れる!
HasuraはGraphQL形式のAPIを提供する Hasura ・フロントエンドとデータベースの仲介役 ・データベースの情報から自動でAPIを生成する ・真ん中のアイコンはなぜか「Lambda」 データベース ・ユーザーのデータを保存するために必要 ・SQLしかしゃべれないので、アクセス時には翻訳が 必要
画面(フロントエンド) ・ユーザーが操作するために必要 ・ユーザー側で動くので危ない処理や重たい処理には 向いていない GraphQL SQL お願いします〜! かしこま! 変換 問い合わせ
GraphQLとSQL GraphQL SQL 参照( EAD) R 更新( PDATE) U 削除(
ELETE) D 登録( REATE) C Mutation INSERT SELECT UPDATE DELETE Mutation Mutation Query ・GraphQLはHasura独自の仕組みではなく、一般的なAPIの様式の1つ ・HasuraはGraphQLでリクエストを受け付けて、リクエストに合わせた形式のSQLに 変換してDBへアクセスしてくれている
2 Hasuraのニガテなこと
よくある光景 ...退職? 全部やっといたるわ! Hasura バックエンド バトンタッチ?
このChapterのゴール バックエンドはどこへ行った? Hasuraがニガテなことを理解して、 説明できるようになろう!
Hasuraのニガテなこと Hasuraは複雑なロジックに 対応できない
単純なケース Hasura ・フロントエンドとデータベースの仲介役 ・データベースの情報から自動でAPIを生成する ・真ん中のアイコンはなぜか「Lambda」 データベース ・ユーザーのデータを保存するために必要 ・SQLしかしゃべれないので、アクセス時には翻訳が 必要
画面(フロントエンド) ・ユーザーが操作するために必要 ・ユーザー側で動くので危ない処理や重たい処理には 向いていない バックエンドの人 フロントエンドの人 はあっ! データ このデータ使って、 ユーザー情報登録頼む! テーブル OK! ...
複雑なケース Hasura ・フロントエンドとデータベースの仲介役 ・データベースの情報から自動でAPIを生成する ・真ん中のアイコンはなぜか「Lambda」 データベース ・ユーザーのデータを保存するために必要 ・SQLしかしゃべれないので、アクセス時には翻訳が 必要
画面(フロントエンド) ・ユーザーが操作するために必要 ・ユーザー側で動くので危ない処理や重たい処理には 向いていない バックエンドの人 フロントエンドの人 はあっ! データ このデータ使って、 ユーザー情報登録頼む! もし名前が空欄だったらエラーで、 あとフラグが立ってたら、追加で 別のテーブルへも登録して!! テーブル む〜り〜 ... ...!
詰んだ...?
...!
バックエンド エンジニア 注:画面以外にもたくさんやることがあるので、 バックエンドエンジニアが暇していることはないです。 進行上の都合でこういう演技をしてもらっています。 またせたなッ!
Hasura Actionsとは 複雑な処理を「Hasura Actions」 として定義しておくことで、 別の人に処理を移譲できる仕組み
これが だ! Hasura Actions Hasura ・フロントエンドとデータベースの仲介役 ・データベースの情報から自動でAPIを生成 する データベース
・ユーザーのデータを保存するために必要 ・SQLしかしゃべれないので、アクセス時 には翻訳が必要 画面(フロントエンド) ・ユーザーが操作するために必要 ・ユーザー側で動くので危ない処理や 重たい処理には向いていない バックエンドの人 フロントエンドの人 はあっ! データ このデータ使って、 ユーザー情報登録頼む! もし名前が空欄だったらエラーで、 あとフラグが立ってたら、追加で 別のテーブルへも登録して!! サーバサイド(バックエンド) ・複雑な処理や外部に見せたくない処理を 行するために必要 ・サービス運営側の管轄になる まかせた!! (Hasura Actions) 登録処理等々
Hasuraが対応できる操作 Hasura GraphQL GraphQL SQL 参照( EAD) R 更新( PDATE)
U 削除( ELETE) D 複雑な処理 登録( REATE) C Mutation GraphQL Mutation GraphQL Mutation INSERT SELECT UPDATE DELETE - Hasura Actions Query
3 Hasura ConsoleとDB管理
このChapterのゴール Hasuraで行うことができるDB操作と その仕組みを理解しよう!
Hasura Console Console コア部分 API生成とかの処理を行う データ管理やGraphQL操作のための画面を提供する ・GraphiQL (GraphQLの試し打ち) ・テーブルの追加・変更 ・データ修正
・SQL実行 ・Hasura Actions定義
Hasura ConsoleによるDB定義変更(1) デモあり Hasura Consoleでぽちぽちやると、 データベースの定義を変更できる。
Hasura ConsoleによるDB定義変更(2) Hasura ConsoleからのDB定義変更も、 最終的にはただのSQL Hasura コア部分 DB定義変更 Hasura Console
データベース DB定義変更のSQL実行
Hasura ConsoleによるDB定義変更(2) 自分の開発環境 他の開発者のDB 適用されない 本番環境のDB 適用されない Hasura Consoleで修正できるのは 接続先のDBのみ
他の環境のDBにも 同じ修正を適用するには?
メタデータとマイグレーションファイル Hasura コア部分 DB定義変更 Hasura Console データベース DB定義変更のSQL実行 メタデータ マイグレーション
変更後のDBの状態 を表したもの 変更差分のSQL を記載したもの メタデータ マイグレーション 変更後のDBの状態 を表したもの 変更差分のSQL を記載したもの 出力 Hasura Consoleで操作をすると、 ・DBの現在の状態: メタデータファイル ・変更差分: マイグレーションファイルとして出力する。 これを適用することで、他の環境のDBも同じ状況にすることができる。
注意 なので、Hasura Console以外から DB定義を変更する場合は、メタデータの 整合性を壊さないように注意
4 サービスとしてのHasura
このChapterのゴール Hasuraはサービス そのサービス体系を理解しよう!
Hasuraはサンフランシスコのスタートアップ 引用元:https://hasura.io/about/ 引用元:https://hasura.io/about/
Hasuraのサービス体系 引用元:https://hasura.io/pricing/ Hasura Cloud Self-hosted Hasura社が持っているサーバ上で、 Hasuraを動かす。プランが上がると、 セキュリティとかパフォーマンスとか の面倒を見てくれる。 自分たちが管理してるサーバ上で
Hasuraを動かす。 自分たちで管理する必要はあるけど、 機能的にはほとんど同じ。
5 まとめ
メタデータ マイグレーション 変更後のDBの状態 を表したもの 変更差分のSQL を記載したもの データベース ・ユーザーのデータを保存するために必要 ・SQLしかしゃべれないので、アクセス時
には翻訳が必要 画面(フロントエンド) ・ユーザーが操作するために必要 ・ユーザー側で動くので危ない処理や 重たい処理には向いていない バックエンドの人 サーバサイド(バックエンド) ・複雑な処理や外部に見せたくない処理を 行するために必要 ・サービス運営側の管轄になる 登録処理等々 Hasura コア部分 DB定義変更 Hasura Console 定義変更時に出力 SQL Hasura Actions (複雑な処理) GraphQL 他環境のDB 反映 Hasura社が提供するサービス Hasura World
ありがとうございました