I am building API for processing with Lumen, the processing job is taking around 1-3 seconds per request.
So far i did it with job queue and beanstalkd and it is asynchronous, meaning i return job_id that i can check later for the result.
I am also writing PHP client to utilize the API and for that i am wondering if i should include 'wait' parameter server side or client side? If wait is implemented serverside i will need to sleep and check the database for results once the job is dispatched and then return result when available (in next 1-5 seconds until available), or if it is client side i will need to sleep and check with the job_id via specific route if the job finished and to get the results.
Which option is better option?
I would have an endpoint which its sole job is to check job ids and wait. There would be no option to wait for the result on other endpoints as it will break the asynchronicity, consumers would just always wait as its easier.
Ok, the client would send the job and get a job id back.
Then you send that job id to a wait endpoint, the endpoint will wait/hang till the job is complete or fails. Then you can query the job again and get the result.
That will prevent the need to poll the server, and also prevent blocking in the client by needing to sleep, poll, sleep.
Abit like LXD operations endpoint: https://github.com/lxc/lxd/blob/master/doc/rest-api.md#10operationsuuidwait