皆さんは Bubble の Backend workflows に「Database trigger event」というアクションがあるのをご存知でしょうか。
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つ作ってみましょう。
サンプル１（Signup 時の自動画像追加）
サンプルの1つ目は、サインアップ時に画像が保存されていなければ自動的に User タイプにランダム画像を追加するような処理を作成します。
事前準備
Backend 処理を有効にするために、Settings の「API」タブにある「Enable Workflow API and backend workflows」にチェックをします。
Data タブに移動し、User タイプに各ユーザ用の Image フィールドを追加します。
次に、新規でランダム画像保持用の Profile pic タイプを作成し、image フィールドを作成します。
作成した Profile pic タイプにランダムユーザ画像用の画像データを登録しておきます。
SignUp 処理の作成
Design タブで Email 用の Input Element と、Password 用の Input Element を配置します。
サインアップ用の Button も配置します。
次に、Workflow タブで Button のワークフローを作ります。
「Click here to add an action」から「Account」−「Sign the user up」を選択します。
「Email」に先ほど作成した Email 用の Input 、「Password」にも先ほど作成した Password 用の Input の Value を指定します。
ここまでで画面側の処理は作成完了です。
いつもと変わりありません。
Backend workflows の作成
次に User タイプを監視する Backend Workflow を作成します。
メニューから Backend Workflows を選択します。
「Click here to add a backend workflow」から「General」−「New Database trigger event」と選択します。
イベント名を「signup」、今回は User タイプのデータを監視するので Type は「User」に設定します。
条件「Only when...」に「User Now's Image is empty（変更後の User データの Image が空の場合）」と入力します。
「Click here to add an action」から「Data」‐「Data(Things)」‐「Make change to thing」を選択します。
「Thins to change」に「User Now（変更後の User データ）」を指定し、Image を Profile pic タイプからランダムで取得するように設定します。
このように設定すると、アプリや Bubble エディターでの User Type 変更時に Image 画像が空の場合、ランダムで画像が自動挿入されるようになります。
サンプル２（ログ自動追加）
サンプルの2つ目は、ユーザーログの自動追加を作成します。
User タイプを Create / Make Change / Delete したときに、誰がどのユーザーをいつ Create / Make Change / Delete したというログをログ用の DB に取得する処理です。
なお、ログは操作タイミングごとにデータが蓄積されるため、運用が長くなるに比例してログの量も増えていきます。
どこかのタイミングでデータを切り捨てる必要があるため、実際の運用時にはご注意ください。
事前準備
Backend 処理を有効にするために、Settings の「API」タブにある「Enable Workflow API and backend workflows」にチェックをします。
Data タブに移動し、Option Sets にログに書き込む用の3種類のコードを作成します。
「New option set」から OperationType を新規作成し、「New option」から Create / Make Change / Delete の3つのオプションを作成します。
次にログ用の 新しい User_Log タイプを作成し、 以下のようにフィールドを追加していきます。
| フィールド名 | フィールド内容 |
|---|---|
| Modified_User | 変更されたユーザーを格納 |
| Operation_Type | Create / Make Change / Delete のどれかを格納 |
| Operation_User | 操作ユーザーを格納 |
| User_Before | 変更前のデータを格納 |
| User_After | 変更後のデータを格納 |
Backend workflows の作成
次に User タイプを監視する Backend Workflow を作成します。
メニューから Backend Workflows を選択します。
「Click here to add a backend workflow」から「General」−「New Database trigger event」と選択します。
Create 時のログ書き込み処理の作成
イベント名を「Logger(Create)」、今回は User タイプのデータを監視するので Type は「User」に設定します。
条件「Only when...」に「User Before Change's Creation Date is empty（変更前の User データの作成日時が空の場合）」と入力します。
「Click here to add an action」から「Data」‐「Data(Things)」‐「Create a new thing」を選択します。
「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 などログに残しておきたい項目を設定 |
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 データの 作成日時 が空ではない場合）」と入力します。
「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などログに残しておきたい項目を設定） |
Delete 時のログ書き込み処理の作成
Create 時と同様に、「New Database trigger event」を作成します。
イベント名を「Logger(Delete)」、User タイプのデータを監視するので Type は「User」に設定します。
条件「Only when...」に「User Now's email is empty （変更後の User の email が空の場合）」と入力します。
「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などログに残しておきたい項目を設定） |
このように設定すると、アプリや Bubble エディターで User タイプ の Create / Make Change / Delete を実施した際に、User_Log タイプ に自動的にログが書き込まれるようになります。
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」に移動してパフォーマンスの向上を図ってみてはいかがでしょうか。
