Подскажите почему промис не работает. Нужно сделать запрос к базе, запушить инфу в массив и вернуть заполненный массив. Но выводится в консоли все равно пустота https://pastebin.com/AU1y5ZEX

он и выполняется. в цикле ты создаешь промисы, после чего вызываешь resolve(). цикл не ждет завершения промисов

Получается мне либо переписывать это на синхронное выполнение либо обертывать все просимы в промисы и получать ответ от каждого из серии матрешки?)

Я считаю, что на запрос
/api/v1/users?id=42
Нужно ответить, например:
• 200 {ok:true, data: {user:{…}}} когда такой юзер есть;
• 200 {error:true, code:'user_not_found'} когда юзера нету;
• 200 {error:true, code:'wrong_auth_cookie'} когда не была выполнена авторизация;
• 404 {error:true, code:'fatal_error', message:'Path /api/v1/users does not exists'} когда версия v1 уже не поддерживается или при любой другой опечатке в запросе (если он всё ещё в пределах /api/*);
• 400 {error:true, code:'fatal_error', message:'Parameter "user_id" is missing'} когда в запрос поданы некорректные параметры (но не их значения!).

То есть, на мой взгяд, код «200» обозначает, что запрос верный и API отработало верно (то есть сам СЕРВИС обслужил запрос), а коды 4xx обозначали бы только то, что API используется неправильно.
Туда же можно воткнуть проверки Content-Type и самого метод (get/post), может юзерагент чекнуть, чтобы поисковики случайно не заходили (им можно отдавать 403 например).

Такая ошибка на фронте обозначала бы ошибку в КОДЕ приложения, или факт того, что приложение нужно обновить/исправить (или сервис сейчас не работает – пусть возвращает 503 если у него база данных отвалилась, например).

Это идеально отделяет их от «отрицательных ответов» – когда нет объекта, нет прав на изменение, попытка сохранить некорректные данные – всё это _нормальные_ запросы к API, которые нормально отработали и вернули нормальный, просто отрицательный результат. Я наоборот не понимаю, с чего это они должны возвращать 404…

Я считаю, что на запрос
/api/v1/users?id=42
Нужно ответить, например:
• 200 {ok:true, data: {user:{…}}} когда такой юзер есть;
• 200 {error:true, code:'user_not_found'} когда юзера нету;
• 200 {error:true, code:'wrong_auth_cookie'} когда не была выполнена авторизация;
• 404 {error:true, code:'fatal_error', message:'Path /api/v1/users does not exists'} когда версия v1 уже не поддерживается или при любой другой опечатке в запросе (если он всё ещё в пределах /api/*);
• 400 {error:true, code:'fatal_error', message:'Parameter "user_id" is missing'} когда в запрос поданы некорректные параметры (но не их значения!).

То есть, на мой взгяд, код «200» обозначает, что запрос верный и API отработало верно (то есть сам СЕРВИС обслужил запрос), а коды 4xx обозначали бы только то, что API используется неправильно.
Туда же можно воткнуть проверки Content-Type и самого метод (get/post), может юзерагент чекнуть, чтобы поисковики случайно не заходили (им можно отдавать 403 например).

Такая ошибка на фронте обозначала бы ошибку в КОДЕ приложения, или факт того, что приложение нужно обновить/исправить (или сервис сейчас не работает – пусть возвращает 503 если у него база данных отвалилась, например).

Это идеально отделяет их от «отрицательных ответов» – когда нет объекта, нет прав на изменение, попытка сохранить некорректные данные – всё это _нормальные_ запросы к API, которые нормально отработали и вернули нормальный, просто отрицательный результат. Я наоборот не понимаю, с чего это они должны возвращать 404…

200 это когда все отработало как нужно. Там никак не должно быть ошибки внутри

Я считаю, что на запрос
/api/v1/users?id=42
Нужно ответить, например:
• 200 {ok:true, data: {user:{…}}} когда такой юзер есть;
• 200 {error:true, code:'user_not_found'} когда юзера нету;
• 200 {error:true, code:'wrong_auth_cookie'} когда не была выполнена авторизация;
• 404 {error:true, code:'fatal_error', message:'Path /api/v1/users does not exists'} когда версия v1 уже не поддерживается или при любой другой опечатке в запросе (если он всё ещё в пределах /api/*);
• 400 {error:true, code:'fatal_error', message:'Parameter "user_id" is missing'} когда в запрос поданы некорректные параметры (но не их значения!).

То есть, на мой взгяд, код «200» обозначает, что запрос верный и API отработало верно (то есть сам СЕРВИС обслужил запрос), а коды 4xx обозначали бы только то, что API используется неправильно.
Туда же можно воткнуть проверки Content-Type и самого метод (get/post), может юзерагент чекнуть, чтобы поисковики случайно не заходили (им можно отдавать 403 например).

Такая ошибка на фронте обозначала бы ошибку в КОДЕ приложения, или факт того, что приложение нужно обновить/исправить (или сервис сейчас не работает – пусть возвращает 503 если у него база данных отвалилась, например).

Это идеально отделяет их от «отрицательных ответов» – когда нет объекта, нет прав на изменение, попытка сохранить некорректные данные – всё это _нормальные_ запросы к API, которые нормально отработали и вернули нормальный, просто отрицательный результат. Я наоборот не понимаю, с чего это они должны возвращать 404…

тут смотря как посмотреть,и завист от требований клиента.  например у меня был кейс когда какой-то промежутчный узел в сети отдавал 404 и запрос до апи даже не доходил. в такий кейсай даже на обишбку лушче вернуть 200

вам там на бекенде вообще легче ошибок не возвращать, хоть пустой ответ. Легче не аргумент

тут смотря как посмотреть,и завист от требований клиента.  например у меня был кейс когда какой-то промежутчный узел в сети отдавал 404 и запрос до апи даже не доходил. в такий кейсай даже на обишбку лушче вернуть 200

Обычно на фронте ловите ошибку в кетч и все норм, а тут даже успех нужно проверять

Это какой промежуточный узел между бэком и фронтом мог отдать 404 ?

был кейс что какой-то роутер вроде отдавал 404,причину не знаю

Роутер это часть приложения или окружения бэкенда, скорее косячнули сами чего по факту не должно было быть

физический роутер где-то в сети клиента