Нормально ли общаться с микросервисами через промисы?

Question

[vetsmen]

Нормальная ли практика общаться с микросервисами через промисы?
Есть подобная конструкция:

const getData = (data) => {
    return new Promise((resolve, reject) => {
        rpc.send(data);
        rpc
            .onRequest(newData => resolve(newData))
            .onError(error => reject(error));
    })
}

где RPC - какой-то протокол, через который идет общение с микросервисом.

В связи с этим появляются вопросы:
1) Что, если ответ от микросервиса будет долгим, а запросов генерироваться будет много? Ведь по идеи стек вызова может переполниться из-за кучи промисов с состоянием pending.
2) Что, если ответ не придет вообще? Ведь промис просто так не reject'нится, опять упираемся в переполнение стека. Первое приходит в голову setTimeout, который будет сам reject'ить промис по истечению определенного времени, но тогда данные будут утеряны, которые возможно могли придти бы позже.

Comments

[Lynn «Кофеман»]

А что у вас есть альтернативы?

[Сергей Соколов]

Хоть раз сталкивались с «переполнением стека» от накопившихся Promise'ов?

[vetsmen]

Сергей Соколов, в комментариях к ответу я уже ответил, что «Вероятность такого исхода есть, когда ответ от микросервиса никогда не придет (например когда запрос где-то потеряется на принимающем сервисе и не вернет ответ)»
Стек имеет ограничения, и логично, что в теории это возможно, если промис не разрешится никогда. Но к ответу мы уже пришли ниже.

Answer 1

[Сергей Соколов]

Практика – нормальная.

Обе проблемы «Что, если» надуманы и нерелевантны.
Что конкретно хотелось бы делать в случае подзадержвашегося ответа? Скажем, установили некий порог в 10 секунд. Ответа всё ещё нет.
Варианты, собственно: подождать ещё, либо реджектнуть. Ещё можно представить вариант - оборвать предыдущую попытку и отправить то же самое повторно.

Answer 2

[Виталий]

Посмотри на nest там уже есть реализация