The way we currently find out whether recommendations are already completed has several disadvantages:
The frontend constantly needs to poll the job via /jobs/{job_uuid} waiting for a 404 (not found). It cannot distinguish between job completed (getting a 404 because the completed job is already deleted) or backend unavailable.
When generating a list of recommendations, only the job id of the last job is returned.
No guarantee that the other jobs are already completed. The "last" job in the list might take longer than some other jobs and thus incomplete results might be presented
Unnecessary waiting for jobs that are completed earlier. Some recommendations might be ready to display earlier but need to wait until the "last" job in the list is done.
We need to expose the jobs_controller#show method to every user. This basically allows every user to query all jobs (json API uses uuids but the html ids are guessable!)
We should provide a new endpoint to check whether the currently running recommendation job(s) for a particular ingredient are already completed or not. This also requires changes in the frontend.
The HTTP status code 202 (Accepted) is an intended way to deal with this kind of asynchronous tasks (see https://youtu.be/oG2rotiGr90?t=42m15s).
The way we currently find out whether recommendations are already completed has several disadvantages:
/jobs/{job_uuid}
waiting for a 404 (not found). It cannot distinguish between job completed (getting a 404 because the completed job is already deleted) or backend unavailable.jobs_controller#show
method to every user. This basically allows every user to query all jobs (json API uses uuids but the html ids are guessable!)We should provide a new endpoint to check whether the currently running recommendation job(s) for a particular ingredient are already completed or not. This also requires changes in the frontend. The HTTP status code 202 (Accepted) is an intended way to deal with this kind of asynchronous tasks (see https://youtu.be/oG2rotiGr90?t=42m15s).