ユーザー検索のベストプラクティス

ユーザー検索のベストプラクティスをいくつか紹介します。

• Management APIに対して要求を行うにはトークンが必要です。詳細については、「Management APIのアクセストークン」をお読みください。

• ユーザー検索要求にはread:usersスコープが必要です。

• 最新の検索結果を取得するには、認証時に即時一貫なエンドポイント（IDでユーザーを取得やメールアドレスでユーザーを取得など）を使用します。これらのエンドポイントを使用した検索には、要求の直前に発生したものも含め、成功したすべての書き込み操作の結果が反映されます。

• メタデータにはよく知られたスキーマを使用します：

  • プロパティには一貫したデータタイプを使用します。

  • 動的なプロパティ名は避けます。

  • 大きなスキーマサイズや深い構造は避けます。

  • 認証および認可の目的に必要のないデータの保存は避けます。

• 検索クエリは、2秒以内に完了しない場合、タイムアウト（HTTPステータスコード503）になります。時間がかかるクエリは、それが複雑なクエリであるか、クエリにエラーがあり、その結果、そのクエリがすぐには完了しないことを示しています。

• 検索クエリでapp_metadataやuser_metadataにユーザー定義の属性が含まれている場合には、タイムアウトする可能性があります。ユーザーのリストや検索は、重大な操作では使わないことをお勧めします。

• （結果が1000件を超えるような）大規模なデータセットを返す検索条件は使用しないでください。

• 存在に関するクエリは使用しないでください（たとえば、「値に関係なく、あるプロパティを持つすべてのユーザーを教えて」など）。

• 検索APIをポーリングしないでください。

• ルールやpost-login（ログイン後）アクションなど、ログインフローの拡張ポイントではユーザー検索要求を行なってはいけません。

• 大きなメタデータフィールドは使用しないでください（メタデータフィールドを2 KB以下に抑えるようにします）。

• 検索にワイルドカードを使用すると、パフォーマンスに影響する可能性があります。場合によっては、大規模なデータセットでワイルドカード検索を行うと、タイムアウトエラーが発生することがあります。また、検索語句の前にワイルドカードを付けることは避けたほうがよいでしょう。ワイルドカードをサフィックスとして使用する方がパフォーマンスが保たれます。

• スペースをエスケープしてパフォーマンスを改善させます（例：q=name:John Doeはq=name:John\ Doeにします）。