Reputation: 1613
We have a web-api based server, and the users do requests.
Many requests have consequences that go beyond the answer that we need to give the user.
So we want to give him/her the answer but then continue processing the implications.
Sometimes we need this "next actions" to happen fast. sometimes we can wait a bit.
I though of the following options:
Before giving the response - open another thread for the job
But seems to me very expensive, and maybe even won't work.
Before giving the response - put the job on some queue that listen to
But seems to me that it might postpone the execution to much
Am I right? Am I wrong?
What are the guidelines/best practices for this kind of questions
Upvotes: 2
Views: 121
Reputation: 4073
I think that the best way to do background processing in that case is to use some queue e.g. azure webjobs or maybe something more complex like NServiceBus. You have to just send message/order processing and return response which inform user that this order has been accepted. There is even special HTTP code (202) for such actions.
Opening another thread is not so good because you lose control on that. There is no easy way to monitor that. What if that thread crash or application pool recycle? You lose all data, user will be waiting forever. It's just not reliable
Upvotes: 1