bubbleにおいて多量のデータ(500行以上)を扱う際に起こるエラーとbubbleの処理の限界

bubbleで500行以上のデータを扱い make change to list of thing や delelte list of thing を行うと処理が成功しません。bubbleの限界なのでしょうか?

具体的には、アプリにcsvデータをインポートして、それらの一部または全部を加工・削除するワークフローを作りました。
①最初は make chenge list of thing で加工を試みました。 make chenge list of thing で500を超えるデータすべてに仮加工を施し、次に仮加工により判別できた一部のデータをまとめて削除、残ったデータの一部を加工、といった手順です。

make change list of thing で試してみると、処理にえらい時間がかかった上で「operation timed out – app too busy」と出てしまい処理が完了しません。make change の方でも delete thing の方でもです。

②もう一つのやり方として list shifter プラグインを使用し1個ずつ順番に処理してみましたが、処理を完了してもデータを覗いてみると処理が正しくできておらず失敗に終わりました。データを何度も更新すると時間差で処理の一部が徐々に反映されるときもありましたが、完璧にはほど遠い状況です。

bubbleで多量のデータを処理するのは不可能なのでしょうか?

原因や解決策など、何かご存じのことがあれば教えていただきたいです。よろしくお願いします。

「いいね!」 1

数日前に3,000件ほどのデータを一括処理しましたが、特に問題ありませんでした。
もしかして、フロント側で実行していますか?
フロント側でこれほど多くのデータを一気に処理するとブラウザがbusyになってもおかしくないと思うので、Backendに移してBubbleのサーバー側で処理させるといいと思います:person_gesturing_ok:

すみません、フロント側、バックエンド側、という概念がわかっていません、、

軽く調べてみると、これなどがその解説でしょうか、、??

一回試してみます。。

「backendに移してbubbleのサーバー側で処理させるといいと思います」ということは、通常のフロント側(?)というのはbubbleでないサーバーで処理していると言うことですか?

その場合、フロントでのbubbleでないサーバーの処理と、バック側のbubbleのサーバーの処理とどのような違いがあるのでしょうか??

お世話になっております、、返信聞きたいです、、(T-T)

akiさんではないですが、答えておきます。

Bubbleの通常のページで作成するWorkflowはフロントエンド、有料プランで使用できるBackendWorkflowを使う処理がBackendです。

フロントについては、処理そのものはクライアント(ユーザー)のブラウザで実行されています(例外あり)。
一方Backendについては、Bubbleサーバーのみで実行となります。
この違いにより、処理途中でユーザーが切断状態になっても処理が完了するか否かが変わります。

BackendWorkflowと使用するには、
Settings → API → Enable API with Backend workflows
にチェックが必要です。

「いいね!」 2

なるほどです、、、akiさんの回答からするに、一般的にフロント側よりもバックエンド側で処理を行った方が高速で正確、という認識で大丈夫でしょうか?

一概に高速かはなんとも言えません。

backendで処理する場合はクライアントとデータ通信を行う必要が無い分、データ量(レコード件数など)が多い場合は早くなることが多いです。
また、個別の処理はフロントでもバックでも変わりません。ただし、前に書いたとおり処理がすべて走りきっていない状態でブラウザを閉じられる、ブラウザバックされるなどをされても影響が出ないようになります(結果的には値は想定通りに書き換わるので正確だと言えないこともないですが・・・)。

「いいね!」 2

お返事遅くなりました!
そしてゆきくん、全て解説してくださってありがとうございます:pray:

ゆきくんの言うとおり、バックエンドで実行すればブラウザがクラッシュしたり閉じられたとしても、全てのデータがきちんと書き換わるので、安全性は高いと思います。
また、バックエンドを使うには有料化する必要があり、有料化するとBulk処理というのも使えるようになるので、これもおススメです。

NoCodeStudyのこの動画を見てもらうと、概ね理解が深まると思います。

「いいね!」 2

なるほどです!!つまり通常はサーバー → クライアントにデータ通信を行った上で、クライアントの端末上で計算やデータ更新を行っていたのが、backendの処理だとクライアント → サーバーに命令文だけ送ってサーバー側で計算を行うことにより、1回1回の処理が(比較的)高速になりクライアントの画面上で何か変更があっても処理を行うのがサーバー側のため影響を受けない、ということですね!

ありがとうございます!!bulk処理というのは初耳です、動画見て学習します!

ありがとうございます!!!

お世話になっております、お陰様で backend workflow を習得し、正常に処理をすることができました!

その発展系として、 backend workflow on a list を使ってみたのですが、繰り返し処理が途中で止まってしまいます。。質問として投稿していますので、もしお手隙でしたらアドバイス頂けると有難いです、、、

よろしくお願いします。。

それとすみません、akiさんに紹介していただいた nocode study ですがログインできなくて困っています、、パスワードが合っていないと言われ、パスワードリセットしてもメールが届きません。。。dmmオンラインサロンに入っているユーザーの特典とのことなので、dmmオンラインサロンと同じメアド/パスワードですよね??

お世話になっております、お陰様で backend workflow を習得し、正常に処理をすることができました!

その発展系として、 backend workflow on a list を使ってみたのですが、繰り返し処理が途中で止まってしまいます。。質問として投稿していますので、もしお手隙でしたらアドバイス頂けると有難いです、、、

よろしくお願いします。。

具体的なフローが無いとアドバイスも難しいです。

すみません。外部サービスのapi連携よりデータを取得し、そのデータを create a new…でbubbleのデータベース内に登録する繰り返し処理です。

登録したいデータ数は600行ほどあり、何度やっても260行程で処理が止まってしまうという状況です。

ページ内でボタンをクリックすると backend workflow として schedule api workflow A が起動し、

A の中では「apiコールしてデータを取得する」→「 schedule api workflow on a list(=B) (→で step1のapiコールの値をパラメータで送る)」という2つのワークフローを入れています。

B の中に「 create a new… 」を作り繰り返し処理としてapi、Aのパラメータで得られたデータをbubbleのデータベースに登録する流れです。

外部APIのコール上限回数に到達している、という可能性はないですか?
あるいは、APIワークフローの呼び方が間違っているのかも。
on a listとして、正常にListデータを送れていますでしょうか?
Bulk処理を使うと、正常に動作しなかった部分に関してはエラーメッセージが返ってくることがあります。
NoCodeStudyにログインできない問題は、NoCodeCamp運営へお問い合わせください:person_gesturing_ok:

コール数の上限に達しているというのは考えていなかったです。。問い合わせてみます。
pereating group にapiコールで得られたデータを正常に表示できているので、呼び方は間違っていないと思います。

「 on a list として、正常に list データを送れていますか?」とはどういうことでしょうか??

ログイン問題の件はすみません、そうですよね、問い合わせ先を間違えました、失礼しました。

よく考えるとコールを行うと一気に1,000件以上をデータを取得することができるので、コール回数が上限に達しているということはないと捉えていいですかね?

①コールして、 ②repeating group にその結果を表示する、というワークフローで一気に1,000件以上のデータが表示されます。 schedule api workflow では①に続く②を「 create a new… 」に変えているだけです。

それとも1回のコールと「 create a new 」の繰り返し処理、ではなく「1回のコールと1回の create a new 」を繰り返し処理、なので260回でapiコール上限、ということでしょうか?

akiさんではないですが、回答します。

APIのコール制限は対向システム側でどのようにリミットをかけているかなので、ここで聞いても判断できないことです。
また、一度に1000件が取得できることと、複数回の呼び出しを実行することはそもそもリミットのかけ方として条件が異なるので、1000件の取得を一度にできることと1件の取得を1000件繰り返すことは別です。
また、1秒あたりの読み込み回数制限や1分ごと、1時間毎に制限していることもあるので対向システムのドキュメントを確認してください。

repeating group表示するといったデータを一度取得する処理をフロントで実行しているのであれば、そのデータを使ってbackend workflowをlist実行すればよいのでは遠見おますが、そのようにしていないのでしょうか?
実際の実装方式がどのようになっているかわかりませんが、APIの呼び出しを都度実行していないかなど確認が必要に思います。

「いいね!」 1

なるほどです、、、リミットの上限が複数の条件について設定してあるのですね、、

最初はRGを使いフロント側②データを表示してから create a new の繰り返し処理を backend 側の schedule api workflow でやっていましたが、プログレスバーが表示されタイムアウトになってしまいました。繰り返し処理自体は backend 側で行っていますが、RGが絡むとフロントも巻き込むようです。対処として読み込みも backend 側に埋め込んだ結果、それでも途中で止まった、という経緯ですね。

api提供先に問い合わせてみた上で、とりあえず260未満で止めて複数回に分けた処理で試してみます。