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
RealtimeDBルールでの頑張り
Search
miyanokomiya
May 21, 2019
Technology
1
350
RealtimeDBルールでの頑張り
Firebase + Vue.js Meetup@渋谷
https://re-build.connpass.com/event/131004/
miyanokomiya
May 21, 2019
Tweet
Share
More Decks by miyanokomiya
See All by miyanokomiya
The state patternの実践 個人開発で培ったpractice集
miyanokomiya
0
160
Other Decks in Technology
See All in Technology
生成AI時代のデータ基盤
shibuiwilliam
6
3.8k
開発者を支える Internal Developer Portal のイマとコレカラ / To-day and To-morrow of Internal Developer Portals: Supporting Developers
aoto
PRO
1
410
Bye-Bye Query Spaghetti: Write Queries You'll Actually Understand Using Pipelined SQL Syntax
tobiaslampertlotum
0
150
なぜスクラムはこうなったのか?歴史が教えてくれたこと/Shall we explore the roots of Scrum
sanogemaru
5
1.5k
なぜSaaSがMCPサーバーをサービス提供するのか?
sansantech
PRO
8
2.6k
Autonomous Database - Dedicated 技術詳細 / adb-d_technical_detail_jp
oracle4engineer
PRO
4
10k
データアナリストからアナリティクスエンジニアになった話
hiyokko_data
2
430
AWSを利用する上で知っておきたい名前解決のはなし(10分版)
nagisa53
9
2.6k
DDD集約とサービスコンテキスト境界との関係性
pandayumi
2
270
5分でカオスエンジニアリングを分かった気になろう
pandayumi
0
170
AWSで推進するデータマネジメント
kawanago
1
1.2k
おやつは300円まで!の最適化を模索してみた
techtekt
PRO
0
290
Featured
See All Featured
Navigating Team Friction
lara
189
15k
Producing Creativity
orderedlist
PRO
347
40k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
36
2.5k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Git: the NoSQL Database
bkeepers
PRO
431
66k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Statistics for Hackers
jakevdp
799
220k
BBQ
matthewcrist
89
9.8k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
520
A designer walks into a library…
pauljervisheath
207
24k
Transcript
RealtimeDBルールでの頑張り 自作オンラインマインドマップサービスの実装例
自己紹介 小宮山智也 メドピア株式会社 フロントエンドエンジニア ボルダリング
近況 https://hopeful-visvesvaraya-3dafb6.netlify.com/ https://qiita.com/miyanokomiya/items/4b0bf8561adc5f7a0754
話すこと概要 • FirebaseとVueで作ったマインドマップサービス紹介 • 作り込んだRealtimeDB権限ルール紹介 • Firestoreとの比較 • 質問などあれば ここを見ながらだと理解が捗るかもしれないです
https://gitlab.com/miyanokomiya/mind-xx-acpr/blob/master/database.rules.json
機能と権限
マインドマップ機能 • ルートから左右にノードを生やせる ◦ DnDでノードを移動 ◦ WebSocketでリアルタイム編集 • ノードにコメントできる •
普通に使えるマインドマップ(多分) フリースペースはこちら(質問書いてくれたら最後に拾えるかも) https://mind-xx-acpr.firebaseapp.com/map/-LfJzihYKQJLt9hHuNFQ
database.rules.jsonのルート要素 • users • file_invitations • file_authorities • work_spaces •
files • nodes • comments • ユーザー情報 • ファイル共有招待トリガー用 • ファイル権限 • ワークスペース情報 • ファイル情報 • ファイル毎のノード情報 • ファイル毎のコメント情報
ファイル権限ルール1 • file_authorities ◦ ファイル権限 • files ◦ ファイル情報 •
nodes ◦ ノード情報 • comments ◦ コメント情報 - file_authorities - $file_id (ファイル毎に) - users (ユーザー毎に) - $uid (データがあればreadは可) - write (write権限フラグ) - owner (所有者フラグ)
ファイル権限ルール2 • files、nodes、commentsは同じ閲覧・権限ルール ◦ データアクセスの都合で階層分けているが、実態は1つのファイル単位 ◦ 他人コメントは削除不可など細かなルールはマジムリなので UIだけで妥協している • read
◦ root.child('file_authorities/' + $file_id + '/users/' + auth.uid).exists() • write ◦ root.child('file_authorities/' + $file_id + '/users/' + auth.uid + '/write').val() === true
ワークスペース • ファイル管理 ◦ 作成、編集、削除、複製 ▪ ファイル権限 • ファイル一覧表示 ◦
自分の一覧 ◦ 共有中一覧 ◦ 自分&共有中の一覧
ワークスペースデータ構造 • work_spaces - $uid (自分のワークスペースのみアクセス可 ) - files (自分が所有者のファイル
) - $file_id - invited_files (共有中のファイル) - $file_id • 都度selectではなく、予め一覧のデータ構造を作っている ◦ id一覧を取得してフロントエンドで個別にファイルと権限情報を get ◦ where条件などは妥協・・
ファイル共有と招待
ファイル共有 • 他のユーザーとファイルを共有 ◦ 閲覧のみ可 ◦ 編集も可 • サービス内ユーザーのみ ◦
サービス自体への招待機能はない ◦ メール機能とか使えばできるかも?
ファイルへの招待フロー • まずはRealtimeDBに招待用データを登録 • file_invitations - $file_id (ファイルへの招待権限はファイルと同じ ) -
$tmp_id (ただの識別子) - email (招待するユーザーのメアド ) - write (write権限フラグ) • 登録をトリガーとしてCloud Functionsで権限とワークスペースを整える
ファイル権限ルール再掲 • file_authorities - $file_id (ファイル毎に) - users (ユーザー毎に) -
$uid (データがあればreadは可) - write (write権限フラグ) - owner (所有者フラグ) 共有したユーザーの権限もこの構造で 表現可能(owner: falseとなる)
なぜCloud Functions • file_authoritiesは新規作成のみ可、変更不可としている ◦ readかwriteルールしか付けられない ◦ 共有中のユーザーも招待可能にしたい => write:
true => ownerを乗っ取れてしまう ◦ Cloud Functionsならコードに書いた変更しかできない ▪ トップダウン式なRealtimeDBルールでは意図せぬ変更への対応は限界がある • 招待されたユーザーのワークスペースにファイルを追加したい ◦ 他人のワークスペース編集を許可するわけにはいかない ◦ Cloud Functionsなら裏側でルールを突き破ることが可能
Beyond Borders • work_spaces - $uid (本人のみアクセス可 ) - files
(自分が所有者のファイル ) - $file_id - invited_files (共有中のファイル) - $file_id - file_authorities - $file_id (ownerのみwrite可) - users - $uid - write - owner Could Functionsでルールを無視して書き込む
公開ファイル
公開ファイル • 認証不要でアクセス可能 ◦ 閲覧のみ可 ◦ 編集も可 ◦ https://mind-xx-acpr.firebaseapp.com/map/-L1kyhrBlrHGorkL4ws_ Cloud
Functions不要で、ファイル編集 権限があれば変更可能としている • file_authorities - $file_id (ファイル毎に) - public (データがあればreadは可) - write (write権限フラグ)
ファイル権限ルール2の拡張 • files、nodes、commentsは同じ閲覧・権限ルール ◦ データアクセスの都合で階層分けているが、実態は1つのファイル単位 ◦ 他人コメントは削除不可など細かなルールはマジムリなので UIだけで妥協している • read
◦ root.child('file_authorities/' + $file_id + '/users/' + auth.uid).exists() ◦ or root.child('file_authorities/' + $file_id + '/public').exists() • write ◦ root.child('file_authorities/' + $file_id + '/users/' + auth.uid + '/write').val() === true ◦ or root.child('file_authorities/' + $file_id + '/public/write').val() === true
ファイル削除
ファイル削除 • ここまでの作り込みによってファイル権限はとても複雑 ◦ 行きはよいよい帰りは怖い ◦ 意図せぬ編集を防いだまま削除だけは許すなんて Firebaseの天才でないとムリ Cloud Functionsで消してしまえ!!
ワークスペースデータ構造再掲 • work_spaces - $uid (自分のワークスペースのみアクセス可 ) - files (自分が所有者のファイル
) - $file_id - invited_files (共有中のファイル) - $file_id ここの$file_id削除をトリガーとして ファイル削除のCloud Functionsを起動
None
RealtimeDBまとめ
RealtimeDBルールの所感 • jsonでルールを書くのでとにかく冗長 ◦ トップダウンのルール適用&データ取得なのでネストを浅くする => ルールをコピペの嵐 • readとwriteしかないのは辛い ◦
せめてupdateとdeleteは分けたい • 困ったらCloud Functionsでなんとかする ◦ Cloud Functionsなしでルールを組み上げきったのなら、それは芸術作品 • よっぽどの理由がなければ今後はFirestoreを検討しよう! ◦ ルールに関数を使える! ◦ read、create、update、deleteの設定ができる! ◦ でも最終的には困ったらCloud Functions!
とはいえRealtimeDBのメリット • FirestoreはDocumentのread数課金 ◦ 今回のようなマインドマップツールだと、ノードが Documentになるのでreadが嵩む ◦ 権限判定時もreadが加算されるので、ルールが複雑になるにつれて readが嵩む ◦
個別Documentのデータ量が少ないなら RealtimeDBの課金体系は有利(※要検証) • とにかくシンプル ◦ 全てがトップダウンで jsonな構造なので覚えるべき概念がほとんどない ◦ FirestoreはDocumentやCollectionなどある程度の学習コストが必要 • Firestoreはまだベータ
そうはいっても流れはFirestore • RealtimeDBとFirestoreの選択で判断に迷う箇所は課金体系くらい • 学習コストはあるが、それに見合う高機能が用意されている • ベータとはいえ、機能は十分にあるし常に進化している ◦ 本リリースになったタイミングである程度のマイグレーションコストは払う覚悟は必要 ◦
Cloud Functionsもそれほどの規模ではなかったがマイグレーションが必要だった ▪ 本リリースに気付かず一時期放置してたら動かなくなっていた・・
ご静聴ありがとうございました • 何か質問などあれば • メドピア、フロントエンド募集してます • 水曜夜は新宿ロッキー(or 秋パン)でボルダリング