Current CTO exploring entrepreneurship on the side; coach; mentor; instructor.
Dedicated to promoting digital literacy and ideological diversity in tech.
For processes that you know specifically have a long processing time, you can use a combination of synchronous and asynchronous messaging and polling.
For example, when you complete a git merge in Bitbucket, the client (website) sends a request to the api server to merge the request.
The api server replies telling the client that it has received the request and is processing.
In the meantime, Bitbucket continuously polls a different API with a processID given to it in the prior request: each time asking if the job is done yet. Once it receives an affirmative, it updates the view.
This kind of scenario can be done server to server just as easily.
I will also vouch for a message queue solution as suggested by Erick as a great alternative.
For processes that you know specifically have a long processing time, you can use a combination of synchronous and asynchronous messaging and polling.
For example, when you complete a git merge in Bitbucket, the client (website) sends a request to the api server to merge the request.
The api server replies telling the client that it has received the request and is processing.
In the meantime, Bitbucket continuously polls a different API with a processID given to it in the prior request: each time asking if the job is done yet. Once it receives an affirmative, it updates the view.
This kind of scenario can be done server to server just as easily.
I will also vouch for a message queue solution as suggested by Erick as a great alternative.
Thanks Brandin. This is something new that I learnt today.