Boris007, если есть несколько устройств и выход должен быть сразу со всех, то следует вводить RefId.
Для примера сущность Refs (id, userId, validFrom, validTo). И прописывать RefId как в Access Token, так и Refresh Token.
При выходе вы для записи с RefId прописываете validTo = Now. При обновлении Access Token через Refresh сходство refresh_token проверять не нужно, а просто распарсить его и проверить RefId, если он еще активен, генерите новый Access Token.
А что значит упарвление рестораном?
К примеру:
- Найм сотрудников, приготовление блюд почти не реально автоматизировать.
- Учет / расходов и доходов - уже есть 1С тот же,
R-Keeper себя и то называет - автоматизации ресторанов.
Активация от данных оборудования, где ставиться программа.
Активатор генерит QR с сылкой с кодом сгенеренным по оборудованию.
Пользователь сканирует с экрана QR получает код и вводит.
Сейчас мобильный инет есть почти везде, где есть офисы организаций.
У нас не нужно подтверждение. Каждый сервис является "источником правды", а все остальные сервисы просто обновляют у себя частичку/копию нужной информации.
Сообщения вида "Создан пользователь ID такой-то, Name такой-то" и все сервисы кто подписан и кому нужна какая-то информация о пользователе просто обновляют свои данные.
Andrei SunnyPh, А смысл в такой избаточности?
Статус код приходит в http протоколе и вам все равно придется его обрабатывать, так как если придет ошибка сетевого уровня (для примера 503), то без этого никак.
IsSuccess - определяется из статус кода.
List ErrorMessages - ошибка всегда одна, но может содержать уточняющие данные. Лучше string "Error" и list ErrorDetails
При этом Result упакован в обьект. Это почти тоже самое, что изначально спрашивали, паковать ли в массив.
А вот из полезного в случае ошибки у вас нет "Времени запроса", Url самого запроса.
"но просто переделать методы на async Task и понаставить await-ов недостаточно же, необходимо прокинуть везде CancellationToken" - достаточно.
Как у вас в примере это самое правильное
У вас по условию 2 ядра. Так что при запросах от 10 тыс клиентов, многим придется ждать.
Наличие пула потоков только уменьшает затраты на создание/инициализацию новых потоков, что явно является не самой долгосрочной операцией.
Для примера сущность Refs (id, userId, validFrom, validTo). И прописывать RefId как в Access Token, так и Refresh Token.
При выходе вы для записи с RefId прописываете validTo = Now. При обновлении Access Token через Refresh сходство refresh_token проверять не нужно, а просто распарсить его и проверить RefId, если он еще активен, генерите новый Access Token.