I'm diving deeper into the world of promises in javascript. I grasp the fundamental syntax where promises are used by clients for handling asynchronous tasks like this:
async function fetchMovies() {
const response = await fetch('/movies');
// waits until the request completes...
console.log(response);
}
From what I gather, fetch returns a promise that resolves as soon as the API --in this case /movies-- responds.
A thought crosses my mind: Is there a scenario where the API endpoint itself returns a promise as a response to an HTTP request? Something along these lines:
...
const app = express();
...
app.get('/',function (req, res) {
let promise = new Promise((resolve,reject) => {
...heavy work here (possibly calling another fetch or something)
resolve({"msg":something});
})
return res.send(promise);
});
On the client side, not much would change since it still receives a promise and must wait for it to resolve before processing the response. However, sending the promise immediately would free up the API's CPU to handle other tasks concurrently.
My hunch is that this might not be practical as I haven't come across it in practice. It seems like resolving promises within one realm, either an API or client, makes more sense than interchanging them. Still, I wanted to ponder over this concept in case I am overlooking something.
PS: During my attempt at implementing the second code snippet, I encountered various errors. Thus, I contemplated more on the viability of the idea rather than fixing the bugs in the implementation.