а не, в твоем случае все проще.
funcion asyncLoop() {
 return fetch(...)
   .then(...)
   .catch({
      updatetoken(...);
      throw new Error('Error')
   })
}
asyncLoop().catch(asyncLoop)

Здравствуйте, в 12 ноде импорты экспорты без флага можно юзать?

ога, вник, поправил

13

оба вы не правы, ему нужны авейты и вайл

Чем лучше рекурсии?

тем что рекурсия для нерекурсивной задачи это глупость

и стек не бесконечный

да

that true

набрсай человеку как это должно выглядеть

щас бы с телефона код набрасывать, примеров и мануалов по авейтам полный интернет

😏

А вот Линус бинарники на телефоне ебашил!!

если за это хорошо платят - почему бы и нет

Да ему 14 лет было)

Парни, есть тут архитекторы, кто с микросервисами наебался наработался вдоволь?

Как кто решает доступность ресурсов сервисов в контексте конкретного проекта?

У меня следующая архитектура:
0) Пакет/модуль для какого-то фрейма
1) сервис = n пакетов, если они под один фрейм, например если пакеты под adonis, собираем сервис на adonis
2) проект, собсна состоит из грядки сервисов

Случай:

Есть сервисы:
0) Авторизация, управление доступом
1) Управление файлами
2) Управление компаниями
3) Управление пользователями

Надо мне доступность файла обеспечить: для пользователя который его загрузил, для компании и только авторизированным.

Как можно решить:
0) В каждом сервисе у сущностей завести scope, что по сути теги и маркировать сущности по необходимости. Например при создании файла пользователем вхерачивать в scope идентификтаор компании, идентификатор пользователя и идентификаторы его групп например
Херово, потому что сервис получает лишнюю ответственность, за которую он не должен отвечать
1) Городить ещё один сервис, в котором регистрировать любые события создания/обновления, но в результате получаем жирную точку отказа, а в случае если надо выбрать файлы например, которые принадлежат компании и не принадлежат какому-то конкретному пользователю получаем ещё и отдельный сервис, отвечающий за поиск и фильтрацию сущностей (например на эластике), либо городим pivot-сервисы, которые отвечают только за связи, что бы в случае с миграцией не получить жёсткие связки. Опять же получить десинк где-нибудь — только в путь.

Может кто почитать что предложит где на эту тему или ёпытом поделиться?

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