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 ● ユーザー情報 ● ファイル共有招待トリガー用 ● ファイル権限 ● ワークスペース情報 ● ファイル情報 ● ファイル毎のノード情報 ● ファイル毎のコメント情報

ファイル権限ルール１ ● file_authorities ○ ファイル権限 ● files ○ ファイル情報 ● nodes ○ ノード情報 ● comments ○ コメント情報 - file_authorities - $file_id (ファイル毎に) - users (ユーザー毎に) - $uid (データがあればreadは可) - write (write権限フラグ) - owner (所有者フラグ)

ファイル権限ルール２ ● files、nodes、commentsは同じ閲覧・権限ルール ○ データアクセスの都合で階層分けているが、実態は１つのファイル単位 ○ 他人コメントは削除不可など細かなルールはマジムリなので 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権限フラグ)

ファイル権限ルール２の拡張 ● files、nodes、commentsは同じ閲覧・権限ルール ○ データアクセスの都合で階層分けているが、実態は１つのファイル単位 ○ 他人コメントは削除不可など細かなルールはマジムリなので 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を起動

No content

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 秋パン)でボルダリング