Bubbleにおけるワークロード最適化の考え方 vo3

成功しているアプリケーションは、複雑な処理をユーザーに感じさせず、ユーザーが抱える問題を迅速に解決するスムーズな体験を提供します。ワークロードを計画する際には、ユーザー体験とワークロード消費の最適なバランスを取ることが重要です。アプリのスケールに応じてワークロードの増加は避けられませんが、適切な設計と計画によって必要以上にワークロードを消費することは防げます。

ワークロードとユーザー体験のバランスを考える際の3つのレベルを紹介します：

• ユーザー体験に影響を与えずにワークロードを節約する: ユーザー体験を損なうことなくワークロードを節約できる場合は、その変更を直ちに実施すべきです。
• わずかなユーザー体験の犠牲でワークロードを節約する: わずかな体験の質を犠牲にしてもワークロードを減らせる場合、その影響を慎重に評価しつつ決定を行います。
• 大きなユーザー体験の犠牲でワークロードを節約する: 大きな犠牲を払う場合、ワークロードを節約することに重点を置きすぎて、アプリの本質的な価値を損なってしまう可能性があります。この場合、再考が必要です。

ワークロードは、アプリのスムーズな動作を支えるために存在するものであり、節約しすぎることは本末転倒になる可能性があります。アプリの主な目的やユーザーが期待する機能を果たせない場合、ワークロードの節約に対する考え方を見直すべきです。

‍

‍

ワークロード最適化のためのフレームワークとして、複雑性（Complexity）、ボリューム（Volume）、繰り返し（Repetition） の3つの柱を紹介します。

1. 複雑性（Complexity）
   • 目的を達成するためのプロセスの複雑さに関連しています。必要以上の複雑な処理は、ワークロードを増加させる原因になります。例としては、過剰な制約を持つ検索や不要にネストされたワークフローが挙げられます。

‍

1. ボリューム（Volume）
   • サーバーが返すデータ量に関する意識です。必要以上のデータを返すと、無駄なリソース消費につながります。例えば、データベースから実際に必要な以上のレコードを返すことはワークロードの無駄に直結します。

1. 繰り返し（Repetition）
   • サーバーで同じタスクが何度も実行されている場合、それが必要かどうかを見直します。例えば、ページロードごとに検索を繰り返すような設計は、必要以上のワークロードを消費します。

ページロードの最適化例

ページロードの最適化において、毎回「Go to page」アクションが発生する場合、そのページがリロードされていなくてもイベントがトリガーされます。

これを最適化するためには、ユーザー主導のイベント（例えばボタンをクリックした時など）に置き換えることで、無駄な繰り返しを減らすことができます。また、ページロード時にデータを全て取得するのではなく、必要なデータのみを後でロードすることで、ワークロードを最適化することが可能です。

‍

複雑なアプリケーションにおいて、バックエンドワークフローはさまざまなプロセスやタスクを自動化するために重要です。

最適化のためには、ワークフローの実行頻度や処理するデータ量を見直すことが必要です。例えば、リストデータを処理する際には、再帰的ワークフローよりも「リストに対するAPIワークフローのスケジュール（Sewall）」を使用する方が効率的です。

セキュリティと最適化のバランス

ワークロードの最適化も重要ですが、特定のケースではセキュリティを優先すべきです。例えば、APIリクエストに認証を要求することで、不正なアクセスからアプリを保護し、無駄なリソース消費を防ぐことができます。また、データAPIで必要以上のデータを送信しないようにすることも、セキュリティと効率の両面で重要です。

‍

Bubbleのワークロード最適化においては、複雑性、ボリューム、繰り返しの3つの柱を常に意識し、適切なバランスを取ることが重要です。すべてのアプリはユニークであり、最適化の方法もそれぞれ異なりますが、これらのフレームワークを活用することで、効率的かつ効果的な最適化を実現することができます。詳細については、Bubbleのマニュアルや関連ビデオを参照し、さらなる最適化のアイデアを見つけてください。

‍

https://www.youtube.com/watch?v=VRfKjciZn2g

‍

‍