Если я пишу RESTful API, и мне нужно делать следующие

запросы:
1. Всех пользователей
2. Всех пользователей с их типами
3. Всех пользователей с их типами и связями с группой
Как будет лучше?
/api/users
/api/users/with-types
/api/users/with-types-and-groups
или
/api/users
/api/users?types=true
/api/users?types=true&groups=true

Ваш restful api пахнет как graphql

Напомню сам вопрос - ну не вижу я середину тут (((

Типы пользователей это их кореша и братухи?

Когда юзеров возвращаешь всех, возвращай только поля с той же таблицы (и максимум отношения типа 1-к-1) по роуту GET /api/users, когда получаешь одного пользователя возвращай все его отношения, включая типов и группы, по роуту GET /api/users/:id

Кстати прикол для любителей TypeORM, если в таблице юзеров 1000 юзеров и каждый юзер находится в 100 группах, вопрос: сколько строк вернёт JOIN юзеров и групп (который происходит при подгрузке отношения)? Поскольку я потерял веру в этот чат, сразу ответ напишу: 100к.

Ну если агрегировать группы юзера на выходе в какой-нибудь array_agg(jsonb_agg(/* */)) То выйдет 1000 записей (как и должно) а не 100к

TypeORM так не умеет.

А заставлять целевую аудиторию того сообщения пользоваться SQL это кощунство.

Тю

А какая орм так умеет? Просто интересно Это не самая тривиальная задача для орм))

Табличка от отношения many-to-many все равно будет по итогу прочитана полностью. Но минимизировать количество дубликатов в передаваемых данных умеет MikroORM. Там есть две стратегии разрешения отношений: через JOIN, либо дёргая по ID. Вот тебе нужна вторая. Ещё это умеет Objection

микроорм вообще не понравилась самая неочевидная настройка/использование (изза этих fork) изза необходимости юзать легаси декораторы и допиливать тсконфиг еще пришлось чтобы только завести эту микрорм потом она всё равно достает поля которые я не прошу и прибивает им undefined ну и эта тема с fork на каждый чих вообще хз что такое ну и по производительности на последнем месте в сравнении с остальными ормами (@prisma/client sequelize typeorm kysely drizzle) (но возможно я не правильно готовил микроорм)

Все о чем ты говоришь пофиксили в последних версиях. По производительности не знаю. Сейчас посмотрю.

тесты (ровно так же как и щупал микро орм) буквально 3 недели назад делал

А какие?

не просто смотрел как быстро достают данные без joinов await Promise.all() 50_000 queries in await Promise.all() ("SELECT email FROM users WHERE users.id = $1") with random users.id 10 separately times await one by one in for loop 50_000 queries in await one by one in for loop ("SELECT email FROM users WHERE users.id = $1") with random users.id 10 separately times

Зато инстансы получаешь сразу, не надо писать код по проведению результата к entity.

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

Ну это не честный тест. Ты базу перегрузишь таким огромным количеством запросов. Он там под капотом делает запросы типа "where id in" и отсылает на каждую таблицу по одному запросу.

"не надо" неприменимое выражение, имхо в кейсе сокращения углов по максимуму - надо в кейсе продового приложения с нормальными временными и денежными инвестициям - наверно не надо

так все на равных условиях

Стикер