ノーコード ラボ

NoCode 関連のツールの紹介、使い方などをやさしく説明しています。

Bubble でデータ更新!auto-binding か Workflow、どっちを使う?

f:id:yksmt:20200806171642p:plain

皆さん、こんにちは!今回は Bubbe の auto-binding(即時更新機能)について、まとめてみました。データ更新する際、auto-binding?それとも Workflow?をテーマに考えてみたいと思います!

Bubble の auto-binding 機能とは?

auto-buinding 機能は、入力と同時にデータベースの値を即時更新できる機能です。ユーザーが「保存」ボタンをクリックするといったアクションが必要ないため、データを登録する項目が多い場合や、更新が頻繁に発生するようなサービスでは、UX を飛躍的に向上させる効果が期待できます。

しかし、Bubble で auto-binding を導入するには、必ずプライバシールールを合わせて定義する必要があります。逆に言えば、プライバシールールが設定されていなければ、auto-buinding の機能は使用できません。

また、Bubble では、データ登録や更新は通常、Workflow で「ボタンがクリックされた時」や「データに変更があった時」といったイベントを作成しても定義することができますので、今回は、データ更新を行う際に、auto-binding と Workflow の特徴を比較して、どちらがどういう時に適しているのか?という部分について考えてみたいと思います。

Input forms のエレメントで設定可能

ではここで、一度 auto-binding の設定方法について確認しておきましょう。auto-binding はデータ更新時に発火する機能ですので、設定は Input forms のプロパティにある「Enable auto-binding on parent element's thing」という項目にて設定します。また、ここでいう「parent」とは、Design タブで Input forms が配置されているエリア(つまりは親エレメント)のことを指します。

以下のサンプルは、Food Type というデータベースから取得したデータを Repeating Group の Data source に設定していて(この Repeating Group が parent にあたります)、その中に配置した Input エレメントで Food Type の name というフィールドのデータを auto -binding にしています。

f:id:yksmt:20200806133738p:plain

使用する場合は、Privacy role の設定とセットで行う

また、auto-binding を使用する場合は、セキュリティ上「誰がどのデータを更新できるか」という設定が必要な為、必ず Privacy role の設定を行う必要があります。

もし、設定していない場合は、「Enable auto-binding on parent element's thing」にチェックを入れても、「You want this input to modify a thing of type ~」といったメッセージが表示され auto-bingind は有効化されません。

f:id:yksmt:20200806135452p:plain

Privacy role の設定は、Data タブの Privacy から Data Type に対して定義し、Allow auto-binding にチェックを入れて、更新対象とするフィールドを選択します。

f:id:yksmt:20200806140857p:plain

Privacy role については、以下の記事でもご紹介していますので、ご参考くださいね。

blog.nocodelab.jp

auto-buinding と Workflow どっちがいい?

では、実際、データを更新する場合はどちらの方が適しているのか?という部分について、それぞれの特徴を比較しながら見ていきたいと思います。

auto-binding の特徴

auto-binding を利用する際のメリットは、上記でお伝えした通り「保存」ボタンをクリックするなどのアクションを省くことができるため、サービスによっては UX の効果を向上させることが期待できます。

設定も、Privacy role を適切に定義すれば、あとは「Enable auto-binding on parent element's thing」にチェックをいれるだけで、Input や Dropdown の値を更新したタイミングでデータベース内の自動更新が完結できます。

f:id:yksmt:20200806151822p:plain

f:id:yksmt:20200806152007p:plain

しかしながら、実際にデータベースに反映されるタイミングが「値を確定した時」という暗黙のルールが加わるため、ユーザーが Web アプリに精通していれば問題ないかもしれませんが、場合によっては「更新されていることに気がつかなかった」といった場合や「フォーカスが移動した時に更新されるとは思わなかった」ということが起こる可能性もあります。画面設計については Alert を表示するなどして一定の配慮をするか、もしくは自動更新される旨を、先にユーザーに伝えておく必要があるかもしれません。

また、現在の Bubble では、複雑な条件の Privacy role は一部作成できません。例えば、リレーションシップの関係にある Data Type(ここでは仮に A と B とします) において、一方の Data Type(A) には User 情報を保持していて、もう片方(B)には User 情報を保持していない場合、B のデータを更新できるのは A と紐づいている User にするというルールでは一部適用されない権限が発生します。この場合は、 Rules that use "This B's X's Y" can't grant search access right now というメッセージが表示されることになります。

以下のサンプルは、Food Type を表示検索できるのは、Food Type と紐付いている Recipe Type の User としていますが、検索の権限は適用されないことになります。

f:id:yksmt:20200806145856p:plain

Privacy role はセキュリティ上、適切に定義する必要があります。

例えば、Current User is logged in といった定義だけで Allow auto-binding の権限を付与するのは、ログインさえしていれば誰でも auto-binding を介してデータが更新できてしまうという意味になりますので、ユーザーを特定して更新させたい場合には不適切です。

また、Find this in searches の権限を持っていて、View all fields や 対象のフィールド表示権限はない(通常このような権限付与の仕方はしませんが...)といった場合でも Allow auto-binding 自体は設定できてしまうので、結果「どの行を更新したのか分からない」ということも起こり得てしまいます。

その為、auto-binding を利用する場合は、Privacy role の定義に問題がないか、しっかり確認しておくようにしましょう。

Workflow の特徴

では、次に Workflow でデータ更新をさせるメリットについて考えてみたいと思います。

まず1つ目は、Workflow で設定すると、データを更新するという Action である「Make changes to thing...」を呼び出すタイミングで、別のアクション、例えばCustom state の値を更新するといったフローを Step2 や Step3 などに同時に複数追加することが簡単にできるという点があります。

また、更新する際のイベントで「An input's value is changed」を使用すると auto-binding 風にすることもできますが、そうではなく、複数の項目の値をユーザーに入力してもらい、最後に「保存」ボタンをクリックするというイベントでフローを作成した場合は、アプリに不慣れなユーザーでも直感的に分かりやすいという利点もあります。そして、それ以外にも DB への接続回数を減らせるという大きなメリットもあります。サービスが大きくなればなるほど、ユーザーによるサーバーへの接続回数を減らす利点は大きくなります。

以下は Workflow で更新する場合のサンプルです。

f:id:yksmt:20200806160912p:plain

f:id:yksmt:20200806160732p:plain

なお、マニュアルにある通り、Workflow でのデータ変更には、auto-binding の時とは逆にプライバシールールは適用されないという点があります。その為、更新する際は、このデータを更新できるのは誰かという条件を When などで絞り込む必要があります。

では、上記の特徴を踏まえて、以下に、auto-binging か Workflow かどちらが適しているのか判断するポイントをご紹介しておきたいと思います。

auto-binding が適している時

  • データベース構造がシンプルでプライバシールールが明確である場合
  • ユーザーへの操作回数を減らす UX を検討している場合
  • ターゲットや利用ユーザーが Web アプリに慣れている人である場合
  • データを更新した際に、付随させるような後続の処理が不要である場合
  • ユーザーによるサーバーへの接続回数をさほど気にしなくても良い場合

Workflow が適している時

  • 親子関係やリレーションシップの関係を持つ複雑なデータベース構造が多い場合
  • 権限が異なるユーザー(管理者、インストラクター、メンター、一般、ゲストなど)が多い場合
  • ユーザーにデータが更新されるタイミングを分かりやすく認識させたい場合
  • データ更新する際に、付随させる後続の処理がある場合
  • できるだけサーバーへの接続回数を減らしたい場合

まとめ

いかがでしたか?今回は、Bubble でデータ更新するなら、auto-binding か Workflow のどちらを使うかをテーマに考えてみました!ご自身のサービスでは、いったいどちらが良いかのか?他にも色々な視点で検討してみてくださいね!では、次回もどうぞお楽しみに~!