FJCT_ニフクラ mobile backend(mBaaS)お役立ちブログ

スマホアプリ開発にニフクラ mobile backend(mBaaS)。アプリ開発に役立つ情報をおとどけ!

公開データと非公開データの分け方

f:id:mbaasdevrel:20190704182117p:plain

mBaaSでは、行ごとのACLのみ設定できます。あるカラムを全体公開しない、あるカラムは更新対象外にするといったことはできません。しかしユーザ情報の一部を公開したい、でも全部取得されてしまうといったニーズはあるかと思います。

そこで今回はデータストアのTipsとして、公開/非公開データや参照のみ/更新可データの使い方を紹介します。

クラスの分割

ユーザクラスはデフォルトでは本人しか見られない状態です。ACLを変更することもできますが、クラスを分割するのがお勧めです。

  • ユーザクラス
    自分のみ閲覧、更新可能
  • ユーザプロフィールクラス
    誰でも閲覧可、自分のみ更新可

このように誰でも閲覧できるクラスを設けることで、情報の出し分けが可能になります。

リレーション

上記の例で言うところのユーザクラスとユーザプロフィールクラスはリレーションでつないでおきます。この時、繋ぎ方としてはユーザ -> ユーザプロフィールのみで良いでしょう。ユーザプロフィールは誰でも見られますが、ユーザクラスは自分しか情報が見られません。自分であればユーザクラスから参照すれば良いだけなので、ユーザプロフィールから参照することはほぼないと言えるでしょう。

api.User
  .equalTo('objectId', api.User.currentUser().objectId)
  .include('UserProfile')
  .find();

例えばコミュニケーションアプリを作っている場合を想定します。

  • スレッドクラス
    誰でも閲覧可、オーナーのみ更新可
  • スレッドステータスクラス
    誰でも閲覧可、誰でも更新可

スレッドに対するコメントによってスレッドステータスクラスを更新します。このような形式の場合はスレッドクラス -> スレッドステータスクラスを参照するリレーションを組んでおきます。

こんな場合にも

例えば課金ユーザの状態によって機能を変えたいと思います。ユーザクラスの中に課金フラグをもたせてしまうと、ユーザ自身がそのフラグを操作できてしまいます。そこで課金状態を管理するテーブルを別で作成し、参照できるけれど更新できないデータとして定義します。そうすることで安全にアプリの機能提供ができます。

まとめ

行ごとのACLで管理できない場合は、クラス自体分けてしまいましょう。行ごとのACLだと、更新や公開されては困る情報まで出てしまう可能性があります。データストアのクラスについては自由に増やすことができますので、データを安全に保つためにもクラスの分割管理をお勧めします。

中津川 篤司

中津川 篤司

NCMBエヴァンジェリスト。プログラマ、エンジニアとしていくつかの企業で働き、28歳のときに独立。 2004年、まだ情報が少なかったオープンソースソフトの技術ブログ「MOONGIFT」を開設し、毎日情報を発信している。2013年に法人化、ビジネスとエンジニアを結ぶDXエージェンシー「DevRel」活動をスタート。