高性能なRetoolアプリケーションの構築

Retoolアプリケーションを最良の状態に保つための基本的な指針といくつかの提案を示します。Retoolでのアプリケーションの構築は、従来のWebアプリケーションの構築とよく似ています(非常に簡単です)。そのため、ベスト・プラクティスはどちらにも当てはまります。

基本

パフォーマンスは、アプリケーションごと、クエリーごと、さらにはユーザーごとに異なります。アプリケーションは様々な理由で低速になることがありますが、その低速なパフォーマンスは必ず再現できるわけではありません。独自のアプリケーションをデバッグするときのように、あらゆる面について考えてみてください。どのデバイスを使用しているか? 自分のサーバーがどこにあり、ネットワーク速度はどのくらいか? 自分の側で最近変化したことがあるか?

Retoolによって、ベースラインのクエリー・パフォーマンスにある程度のオーバーヘッドがかかります。クエリー自体へのRetoolによるオーバーヘッドは通常は150ms程度ですが(この短縮に取り組んでいます)、結果のダウンロード、JSによる変換、UIでの表示、および依存関係の再計算のプロセスには、データベースやAPIでクエリーを直接実行するよりもずっと時間がかかる可能性があります。Retoolでの照会時間とSQLやAPIクライアントでの照会時間を比較するのではなく、同様の規模のデータを扱う他のWebアプリケーションや管理UIと比較した方が公平です。

Retoolチームは、アプリケーションのパフォーマンスの向上に積極的に取り組んでいます。Retoolは、いくらか粗い部分がある、まだ新しい製品ですが、現在のこのプラットフォーム上で高性能なWebアプリケーションを構築することは十分に可能です。これがさらに簡単になるように積極的に取り組んでいます。

ベスト・プラクティス

ページのロード時に実行されるクエリーの数を制限します。Retoolでは、ページのロード時にクエリーを実行し、オプションで遅延時間を追加することができます。これはダッシュボードに常に最新のデータを反映するために役立ちますが、アプリケーションが起動時に過負荷になる可能性があります。ページのロード時に実行するクエリーの数とサイズを制限し、入力が変更されたときにそれらを実行するか手動で実行することを検討してください。

クエリー・キャッシングをうまく利用します。Retoolでは、クエリーの結果をキャッシュできます。特定のクエリーについてクエリー・エディターで「advanced」タブをクリックし、チェックボックスを選択するだけです。自分の組織の詳細設定ページ(/settings/advanced)で複数のユーザーにわたりクエリーをキャッシュすることもできます。大規模な分析クエリーを実行している場合や、一般的には常に最新の数値が必要なわけではない場合は、パフォーマンスの向上のためにキャッシングの使用を検討してください。

アプリケーション内のコンポーネントとクエリーの数を制限します。他のWebアプリケーションと同じで、アプリケーションに含まれているコンポーネントとクエリーが多いほど(特に、それらがインタラクティブである場合)、性能基準を満たすために努力が必要になります。できるだけ余分なコンポーネント・セットをなくし、N+1問題を回避するためにクエリーをマージします。

ここでのもう1つのベスト・プラクティスは、1つの大きなアプリケーションよりも複数の小さなアプリケーションを使用することです。1つの画面にすべての機能を含める必要がない場合は、ユース・ケースに特化したいくつかのRetoolアプリケーションを作成して、他のRetoolページを開くButtonコンポーネントでアプリケーション同士を結び付けることを検討します。Query Libraryを使用すると、一元的な場所で複数のクエリーを記述してから、複数のアプリケーションでそれらを再使用することができます。

複数の大きなデータセットによってフロントエンドが過負荷にならないようにします。フロントエンドに50万行のデータをロードすると、その処理能力の限界を超えます。特定のタイプの視覚化のためにブラウザーに大量のデータが必要でない限り、そのようなことは避け、かわりにクエリー・レベルで変換と集約を適用します。Retoolのお客様は、多くの場合、この問題を回避するためにTableコンポーネントでサーバー側のページネーションを使用します。

依存関係の長い連鎖を最小限にします。Retoolでは、各アプリケーションの依存関係グラフが構築され管理されているため、どこででも{{ }}内にJavascriptを記述することができます。その連鎖が深く複雑であるほど、モデル更新時の再計算と移入に時間がかかります。できるだけ参照を浅くし、他のコンポーネントのプロパティに依存するコンポーネントが多くなりすぎないようにします。

複雑なものはできるだけバックエンドに移動します。RetoolではどこでもJavascriptを記述できるため、フロントエンドが無秩序になる可能性があります。これは、フロントエンドに機能を追加する方が簡単であるため(少なくとも一時的には)、開発者がバックエンドへの機能追加を避けることで起こります。Retoolは、適切に設計されたバックエンドの上に構築されたフロントエンドとして使用するのが最も適しています。可能な限り、複雑な変換ロジックをAPIに移動して、アプリケーションを高性能な状態に保ちます。