за наводку спасибо. но все таки можешь указать почему async-lock в данном случае - это плохо?

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

в случае postgresql - Serializable Isolation Level?

Всем привет! Подскажите пожалуйста, у меня есть RESTApi, где у всех юзеров есть уникальный x-api-key, по нему они могут обращаться к моим эндпоинтам и получать информацию
Я хочу дать возможность сторонним сервисным приложениям получать доступ к аккаунту пользователя и ходить по апи и получать его данные(oAuth)

Сам вопрос, могу ли я интегрировать oAuth в свою систему, без полного её переписывания? Или мне нужно переписывать все методы регистрации/авторизации и вообще теперь не использовать x-api-key, а токен от oAuth?

а под юзерами имеешь ввиду обычных пользователей или как?

Всем привет! Подскажите пожалуйста, у меня есть RESTApi, где у всех юзеров есть уникальный x-api-key, по нему они могут обращаться к моим эндпоинтам и получать информацию
Я хочу дать возможность сторонним сервисным приложениям получать доступ к аккаунту пользователя и ходить по апи и получать его данные(oAuth)

Сам вопрос, могу ли я интегрировать oAuth в свою систему, без полного её переписывания? Или мне нужно переписывать все методы регистрации/авторизации и вообще теперь не использовать x-api-key, а токен от oAuth?

Ребят, такая проблемка есть.
Допустим есть роуты которые зависят от значения в базе
что имею ввиду:

const store = new Store(); // какое-то хранилище, не важно это redis или бд, т.к. будет запрос к нему, то это уйдет в фон (запрос к диску если это бд, запрос к redis-у и тд)
if (!(await store.get(key))) {
  await store[key] = value;
}

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

const order = await store.findOne({ where: { key }});
if (!order) {
  await store.create({}); // создаем новый заказ
}

если будет 2 параллельных запроса, то возможна ситуация что в теперь в store будет 2 заказа

есть вариант использовать https://www.npmjs.com/package/async-lock, но возникает одно но - у меня несколько нод, т.е. по сути надо это вытянуть в отдельный worker. И тут возникает вопрос, т.к. будет много "зафриженных до определенного момента" запросов, будут ли какие-то подводные камни? (просадки по памяти, возможности отваливания чего-то)

Есть ли какие стандартные решения этой проблемы, когда используется несколько нод и они все перед nginx (действует как балансер тут) ?

который отличается от внутреннего

redis-semaphore и аналоги

Либ для создания провайдера мало, все они старые
Гайдов так вообще не найти адекватных

Тут есть несколько вариантов, например можно не rest, а websocket соединение поднять, тогда вы привяжите юзера к одному инстансу и не будете париться)) Еще вариант иметь стейт выполнения запросов в общей бд, т.е. добавляться стейты будут вразнобой, а вот выполнятся будут ровно по порядку))
P.s. вы там очередь захотели сделать, но очередь вам поможет разве что просто соединить события от юзера для разных серверов, но ведь в очередь могут прилететь не последовательно и тогда как эту очередь разруливать?) Проще уже тогда в базе стейт сделать, там хоть есть возможность в разной последовательности выполнить))

ну так протокол не меняется, либы протестированы, багов нет