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

Да у меня знакомый бек.. вечно говорит что это "херово" нагружать токен..

Типо там достаточно лишь рефре и аксес и userID к примеру

Понял, спасибо

Рега это другой модуль - аккаунт, он запускает у модуля авторизации создание нового юзера и получает токен с ид и ролью, этот ид использует как ид юзера у себя в табличке в модуле аккаунт, при отображении списка юзеров с ролями, передаёт список ид юзеров в модуль авторизации и тот возвращает список ид с ролями, птом джойнит и отдаёт на фронт как один список

А вообще может подскажешь логику с этой регистрацией - авторизацией.

Получается я сделал так:
Человек вводить данные, они проходит валидацию, закидываются в базу, возвращаются созданный пользователь.

Но мне еще нужно получить для него jwt tokens, я могу вернуть что типо 2 объекта
{
user,
tokens
} ?

Или лучше когда я буду регистрироваться, то вначале идет рега, возвращаются юзер, после на фронте посылается еще 1 запрос, на авторизацию, от куда прийдут токены ?

Я делаю так, что эндпоинт регистрации в ответ возвращает либо ошибку валидации, либо пару токенов. В payload аксесс-токена запихни id юзера. Отдельный запрос на получение токенов не надо. Точнее надо, но для рефреша (туда передаешь рефреш-токен, а получаешь новую пару)

Товарищи, если используются субдомены, то авторизацию только кукой?

Единственный кейс, где может, на мой взгляд, пригодиться OneToMany, это если тебе нужно на странице вывести список авторов и сразу же списки их статей в единой таблице. Но проблема тут в том, что ORM через OneToMany это оптимальным образом всё равно не сумеет вытащить. В идеальном случае это делается через 2 запроса к бд (первый с пагинацией, а второй с IN), но ORM так не сделает

Товарищи, если используются субдомены, то авторизацию только кукой?

Куку так и так придётся юзать для хранения refresh-токена)