現在、キューの機能を使用して応答を処理することでこれを行っています。ユーザーは、セキュリティ ルールによってユーザー ID を要求のプロパティとして書き込むように強制され、自分の ID を含むキュー内のアイテムのみを読み取ることができます。
セキュリティ ルール (クライアントに関連する部分):
"queue": {
"tasks": {
".indexOn": [
"_state"
],
"$id": {
".read": "auth !== null && ((!data.exists()) || (data.child('user').val() === auth.uid))",
".write": "auth !== null && ((!data.exists() && newData.child('user').val() === auth.uid && newData.child('_state').val() === '<start state goes here>') || (data.exists() && data.child('user').val() === auth.uid && !newData.exists()))"
}
}
}
これにより、クライアントは新しいジョブを作成したり、ジョブを削除したりできますが、その内容を変更することはできません。
<start state goes here>
クライアントが開始状態でのみエントリを追加できるようにするには、上記のルールに入力する必要があります。
仕様
{
"error_state" : "error",
"finished_state" : "finished",
"in_progress_state" : "in_progress"
}
クライアントが要求がいつ解決されるかを知るために監視する可能性がある終了状態を指定するには、デフォルト以外の仕様が必要です。
その他の考慮事項
クライアントは、このように使用されるタスクをクリーンアップすることに依存することはできません。タイムアウト後に応答を自動的に削除するようにサーバーを構成する必要があります。たとえば、ユーザーは、応答が返される前にページを更新したり、ページを離れたりする可能性があります。これが発生する確率は 1% 未満ですが、完了した応答でキューがいっぱいになると、パフォーマンスが低下します。