I have a requirement to perform an asynchronous job(let's call js function X) for an API A.
I am planning to implement it using the following approach.
1. Create API B and expose function X in it using nodejs.
2. Create API A and call API B from nodejs using the callback (async).
3. API A will return immediately to the consumer after the async call to API B.
4. Once API B processing is completed, the flow will return to callback processing of nodejs of API A and do appropriate processing as required.
In step 3, I have called API B using async callbcak. As per my understanding, that creates another thread (per call) and lives until the API A processing is completed. Also, a callback thread (shared) will keep runing in the nodejs runtime.
Is above approach ok or have drawbacks/defects from implementation / standards perspective ?
flow looks good - and should work as expected, as you described
the threading model you described may not be accurate, but that's okay - the flow is correct
Just for clarity -
In 3 - API A will return immediately after you call response.end() in your node.js, you would typically do this after you start your async jobs
In 4 - control is returned to the callback in node.js
One additional comment, since its all nodejs, you could also call function X directly from your API A's nodejs,
Having API B also have its own advantages like - analytics, management etc.
Thanks for your inputs. So, for each call back (async calls) new thread is instantiated ?
no, nodejs is single threaded event loop - so callback just goes to event queue