• thing：

    オブジェクトのこと（？）

    thingに対してCRUD操作を実行するとか言っていたので、多分そう。

  • Bubble vocabulary

    • 最初の選択肢：データソース
    • 以降全てのチャンク：電子メールフィールドや、first, containsなどの演算子

    (Data Source) + (Operators)

    例1：Current User’s Email

    例2：Current User :contains

  • 意図したデータが表示されない / 表示したくないデータが表示されている

    • プライバシールールの設定がちゃんと出来ていないことが原因かも

      デバッガーを見ればプライバシールールで今設定されているものを確認できる。（非表示になっているものだけ）

  • アプリのデータベースの構造化において、正解は1つではない。各アプリによって最適解は異なるので、その時の仕様や状況にあわせて作ること。

    ただし、拡張性を持たせることは忘れずに！

    • （Bubble開発者の）経験則として、リストに100個を超えるthing（オブジェクト）を保存する必要があるアプリの場合は、フィールド上のリストとしてではなく、独自のデータ型にして検索を実行する必要がある。

      リストに含まれるものが多いほど、アプリのパフォーマンスは遅くなるが、リストのサイズが小さい場合は、リストフィールドは検索よりも処理が速いため、アプリのニーズを知ることが重要であるとのこと。

    • 【どうするのが良いか判断するのに最適な方法】

      • 100人以上のユーザーがこのthing（オブジェクト）を作成する必要があるのか、それとも私たちのコンテキストで作成する必要があるのかを自問すること

        例）1つの投稿に1,000件のコメントを保存したい場合があったとする。

        その場合、適切なデータ関係を使用して適切に構造化すると、アプリ全体でthing（オブジェクト）を構築するためのオプションが限りなく簡単になり、データ型を接続できる方法がさらに増える。

  • 再利用可能な要素には、それぞれ独立したワークフロータブが存在する

    • 再利用可能なワークフローを作成する良い方法である

  • 再利用可能な要素の中に、さらに再利用可能な要素を追加することも可能

    • それぞれの再利用可能な要素を整理した状態で保つこともできる

  • デバッガー

    • 通常モード（Normal）：

      低速モードで中断することなくワークフローが実行される。

      各アクションと次のアクションの間には1秒の一時停止があり、

    • ステップバイステップモード（Step-by-step）：

      複数のワークフローが実行される時に最も頻繁に使用するモードである。

      それぞれのワークフローが次々に実行され、全てがデバッガーで同じ実行モードに従う

  • LiveモードとDevモード

    • 両方ともアプリのデータベースを含む別個のデータベースを持っている。

    • これまでデータベースに追加した全てのアプリデータは、ライブデータを表示するために開発バージョンのデータベースにあった。これをショートカットして、DevからLiveに変更することも可能。

    • Devモード：

      開発モード。意図的に行われるため、デプロイ時にアプリがどのように見えるか、どのように機能するかをテストできる

      ユーザーはデフォルトでライブ環境（Liveモード？）を使用する＝Liveに変更がデプロイと同じ意味になるのか？！

  • BubbleでAPIを使うとできること

    • ツイートを表示したり
    • 曲を再生できたり
    • 天気情報を取得できたり

  • Bubbleで使える5つのHTTP REQUEST

    • GET
    • POST
    • PUT（既存のthingの全てのフィールドを書き換える）
      • データを破壊する可能性もあるため、使う際は細心の注意が必要
    • PATCH（特定の値のみ変更できる）
      • 特定のフィールドを選択的に更新できる一方で、他のフィールドは既存の値を安全に保持できる
    • DELETE

  • 5つのHTTP REQUESTをセキュリティ上安全に行うために「認証」機能が存在する

    • 認証は外部アプリケーションの仕組み
    • APIはアクセスを許可する前に、ユーザーが誰であるかを確認する
    • Bubble APIコネクタを使用してアプリを最初から構築するには、APIのドキュメントで認証が必要なリクエストがあるかどうかがわかることに注意することが重要
    • 認証の要件はプラットフォームによって異なるため、多くの場合、サインアップ後にアプリの機能にアクセスするためにアプリにサインアップする方法と同様に、アクセスしようとしているAPIには、おそらく、そのユーザーだけに固有の文字列の形で、一種のパスコードである「API KEY」が付与される
    • 一般的に、以下のリクエストの場合に認証が必要になることが多い（破壊行為に繋がるため）
      • PUT
      • PATCH
      • DELETE

  • APIコネクタ

    • BubbleのAPIコネクタに変更を加えた際は毎回初期化をすること。そうすることで変更内容が反映されて最新の設定になる
    • エンドポイントに動的なパラメーターを設置したい場合（動的にidをセット出来るようにしたい等）

      • [id]というように、変数名をブラケット（[]）で囲えばOK

        • 例：https://academy-demo-api.bubbleapps.io/api/1.1/obj/movie/[id]

      • Private（非公開）のチェックは外すこと。これで動的に値をセット出来るようになる

        ※API KEYを動的パラメーターとして設定する場合は、Private（非公開）にチェックは入れたままにしておくこと

        （データとして使用するときに変更する必要がないため）

  • Settings

    • Languagesは、開発画面の言語設定ではなく、エラーが出たときに日本語で表示されたりなどの設定らしい