ノーコード ラボ

NoCode 関連のツールの紹介、使い方などをやさしく説明します。質問やご指摘大歓迎です。わからないことがあったら、コメントや Twitter などで聞いてください!

Bubble の Database trigger event 機能を使ってみよう!

f:id:MKCHI:20211227054516p:plain

皆さんは Bubble の Backend workflows に「Database trigger event」というアクションがあるのをご存知でしょうか。

f:id:MKCHI:20211223134123p:plain

Backend workflows と言えば「API workflow」がよく利用されますが、同じメニューにある「Database trigger event」とは何なのか知らない方も多いのではないでしょうか。
「Database trigger event」を利用するとアプリの高速化やコードの共通化ができます。
今回はそんな「Database trigger event」について詳しくご紹介していきたいと思います。

Database trigger event とは

Bubble の比較的新しい機能です。(Personal プラン以上で実行可能)

「Database trigger event」はデータベース(Type)の変更をトリガーとして、Backend 側でワークフローを実行する方法です。
監視しているデータ Type のデータが変更されるたびに、イベントの「Only when...」条件をチェックし、条件が一致すると「Database trigger event」のワークフローを実行します。

アプリケーション内の様々な場所で変更されるデータがあり、そのデータが変更されるたびにチェックや関連データを更新したい場合に利用すると便利なアクションです。
具体的には、アプリケーション内の様々な場所で変更される値Aを変更すると自動的に値Bも変わるような更新処理や、あるデータが変更されるたびにその値を外部 API に同期させるような処理をおこなうことができます。

「Database trigger event」は、アプリ上の変更から実行されるだけでなく、ワークフロー、API コール、Bubble エディターでの手動編集など、データへのあらゆる変更方法で実行されます。

また、特徴として、2つの特別なデータ型を持っています。
「Thing(Type) Before Change」と「Thing(Type) Now」です。
「Thing Before Change」は、監視データ変更前(ワークフロー開始前)の値で、「Thing Now」は、監視データ変更後(ワークフロー終了後)の値となります。
この2つのデータ型を持っていて、ワークフロー全体を通して両方のバージョンにアクセスできるため、変更履歴なども簡単に作成できます。

それでは次は実際にサンプルを2つ作ってみましょう。

サンプル1(Signup 時の自動画像追加)

サンプルの1つ目は、サインアップ時に画像が保存されていなければ自動的に User タイプにランダム画像を追加するような処理を作成します。

事前準備

Backend 処理を有効にするために、Settings の「API」タブにある「Enable Workflow API and backend workflows」にチェックをします。

f:id:MKCHI:20211227060227p:plain

Data タブに移動し、User タイプに各ユーザ用の Image フィールドを追加します。

f:id:MKCHI:20211223143444p:plain

次に、新規でランダム画像保持用の Profile pic タイプを作成し、image フィールドを作成します。

f:id:MKCHI:20211223143556p:plain

作成した Profile pic タイプにランダムユーザ画像用の画像データを登録しておきます。

f:id:MKCHI:20211223143842p:plain

SignUp 処理の作成

Design タブで Email 用の Input Element と、Password 用の Input Element を配置します。
サインアップ用の Button も配置します。

f:id:MKCHI:20211223144200p:plain

f:id:MKCHI:20211223144210p:plain

次に、Workflow タブで Button のワークフローを作ります。
「Click here to add an action」から「Account」−「Sign the user up」を選択します。

f:id:MKCHI:20211223144435p:plain

「Email」に先ほど作成した Email 用の Input 、「Password」にも先ほど作成した Password 用の Input の Value を指定します。

f:id:MKCHI:20211223144630p:plain

ここまでで画面側の処理は作成完了です。
いつもと変わりありません。

Backend workflows の作成

次に User タイプを監視する Backend Workflow を作成します。
メニューから Backend Workflows を選択します。

f:id:MKCHI:20211227062010p:plain

「Click here to add a backend workflow」から「General」−「New Database trigger event」と選択します。

f:id:MKCHI:20211223145459p:plain

イベント名を「signup」、今回は User タイプのデータを監視するので Type は「User」に設定します。
条件「Only when...」に「User Now's Image is empty(変更後の User データの Image が空の場合)」と入力します。

f:id:MKCHI:20220104231635p:plain

「Click here to add an action」から「Data」‐「Data(Things)」‐「Make change to thing」を選択します。

f:id:MKCHI:20220104231908p:plain

「Thins to change」に「User Now(変更後の User データ)」を指定し、Image を Profile pic タイプからランダムで取得するように設定します。

f:id:MKCHI:20220104231946p:plain

このように設定すると、アプリや Bubble エディターでの User Type 変更時に Image 画像が空の場合、ランダムで画像が自動挿入されるようになります。

f:id:MKCHI:20211223151453p:plain

サンプル2(ログ自動追加)

サンプルの2つ目は、ユーザーログの自動追加を作成します。
User タイプを Create / Make Change / Delete したときに、誰がどのユーザーをいつ Create / Make Change / Delete したというログをログ用の DB に取得する処理です。

なお、ログは操作タイミングごとにデータが蓄積されるため、運用が長くなるに比例してログの量も増えていきます。
どこかのタイミングでデータを切り捨てる必要があるため、実際の運用時にはご注意ください。

事前準備

Backend 処理を有効にするために、Settings の「API」タブにある「Enable Workflow API and backend workflows」にチェックをします。

f:id:MKCHI:20211227060227p:plain

Data タブに移動し、Option Sets にログに書き込む用の3種類のコードを作成します。
「New option set」から OperationType を新規作成し、「New option」から Create / Make Change / Delete の3つのオプションを作成します。

f:id:MKCHI:20220106003522p:plain

次にログ用の 新しい User_Log タイプを作成し、 以下のようにフィールドを追加していきます。

フィールド名 フィールド内容
Modified_User 変更されたユーザーを格納
Operation_Type Create / Make Change / Delete のどれかを格納
Operation_User 操作ユーザーを格納
User_Before 変更前のデータを格納
User_After 変更後のデータを格納

f:id:MKCHI:20220106003552p:plain

Backend workflows の作成

次に User タイプを監視する Backend Workflow を作成します。
メニューから Backend Workflows を選択します。

f:id:MKCHI:20211227062010p:plain

「Click here to add a backend workflow」から「General」−「New Database trigger event」と選択します。

f:id:MKCHI:20211223145459p:plain

Create 時のログ書き込み処理の作成

イベント名を「Logger(Create)」、今回は User タイプのデータを監視するので Type は「User」に設定します。
条件「Only when...」に「User Before Change's Creation Date is empty(変更前の User データの作成日時が空の場合)」と入力します。

f:id:MKCHI:20220106003938p:plain

「Click here to add an action」から「Data」‐「Data(Things)」‐「Create a new thing」を選択します。

f:id:MKCHI:20220106004145p:plain

「Type」に「User_Log(ログ用テーブル)」を指定し、以下のように設定します。

フィールド名 設定値
Modified_User User Now(作成したユーザー情報)
Operation_Type Create(Option Sets から選択)
Operation_User Current User(操作ユーザー)
User_After User Now's email, User Now's Name などログに残しておきたい項目を設定

f:id:MKCHI:20220106005346p:plain

Make Change 時のログ書き込み処理の作成

Create 時と同様に、「New Database trigger event」を作成します。

イベント名を「Logger(Edit)」、User タイプのデータを監視するので Type は「User」に設定します。
条件「Only when...」に「User Now's Modified Date > User Before Change's Modified Date and User Before Change's Creation Date is not empty(変更日時が作成日時より大きい、かつ、変更前の User データの 作成日時 が空ではない場合)」と入力します。

f:id:MKCHI:20220106005957p:plain

「Type」に「User_Log(ログ用テーブル)」を指定し、以下のように設定します。

フィールド名 設定値
Modified_User User Now(変更されたユーザー情報)
Operation_Type Make Change(Option Setsから選択)
Operation_User Current User(操作ユーザー)
User_After 変更後のデータ(User Now's email, User Now's Nameなどログに残しておきたい項目を設定)
User_Before 変更前のデータ(User Before Change's email, User Before Change's Nameなどログに残しておきたい項目を設定)

f:id:MKCHI:20220106010236p:plain

Delete 時のログ書き込み処理の作成

Create 時と同様に、「New Database trigger event」を作成します。

イベント名を「Logger(Delete)」、User タイプのデータを監視するので Type は「User」に設定します。
条件「Only when...」に「User Now's email is empty (変更後の User の email が空の場合)」と入力します。

f:id:MKCHI:20220106010701p:plain

「Type」に「User_Log(ログ用テーブル)」を指定し、以下のように設定します。

フィールド名 設定値
Modified_User User Before Change(変更前のユーザー情報)
Operation_Type Delete(Option Setsから選択)
Operation_User Current User(操作ユーザー)
User_Before 削除前のデータ(User Before Change's email, User Before Change's Nameなどログに残しておきたい項目を設定)

f:id:MKCHI:20220106010850p:plain

このように設定すると、アプリや Bubble エディターで User タイプ の Create / Make Change / Delete を実施した際に、User_Log タイプ に自動的にログが書き込まれるようになります。

f:id:MKCHI:20220106011147p:plain

Database trigger event の注意点

Database trigger event を使う場合、いくつかの注意点があります。

① 管理者権限で実行される

「Database trigger event」は管理者権限で実行されるため、プライバシールールは無視されます。
実行された検索は、現在のユーザーが見ることができる結果だけではなく、ルールを無視した全ての結果を返すことになります。

② 他のTrigger を実行できない

Database trigger event の Trigger で開始されたワークフロー中にデータが修正された場合、その修正が別の Trigger イベントを開始する条件となるかは確認しません。

③「Only when... 」条件が限定される

Database trigger event の「Only when... 」条件では、Bubble データベースの全リストを参照できるわけではなく、「Thing Now 」と 「Thing Before Change 」しか使用できません。
データベースの全リストは、Trigger によって実行されるワークフローで利用できます。

④ Trigger 条件の複雑さに注意する

Database trigger event のワークフローは他の Bubble のワークフローと同様に、対象データが変更されるたびにその条件を確認します。
そのため、1人のユーザのデータ変更であれば問題ありませんが、1度に100人のユーザのデータ変更などを実行するとアプリが遅くなるかもしれません。
必要なときだけワークフローを実行するような条件を設定してください。

まとめ

「Database trigger event」は、アプリケーション全体に関わる共有処理(チェックやデータ更新など)などで利用すると便利ですよね。

また、ページに多数のアクションを追加するとアプリは重くなっていきます。
アプリのパフォーマンスが悪いと感じた場合など、一部の処理を「Database trigger event」に移動してパフォーマンスの向上を図ってみてはいかがでしょうか。