Проблему 1 и 2 полностью решает библиотека nestjs-graphql-tools https://github.com/Adrinalin4ik/Nestjs-Graphql-Tools. Что касается авторизации полей это нормально проверять что можно отдавать авторизованному пользователю, а что нет. В ресте этого нет, т.к. концепт другой, однако рест может отдавать много лишнего и отсутствует гибкость (в этом его минус), особенно чувствуется, когда тебе от юзера надо одно имя, а ты тянешь его полностью, либо городишь специальный путь на запрос пары полей из модели. Это же можно отнести к большому бойлерплейту. С кешированием есть проблемы, однако это не везде применимо, а где применимо они либо частично, либо полностью решены. Эффективность graphql точно не ниже чем рест. Любой запрос можно решить по разному. Если у тебя жирная кверя и супер глубокая вложенность, то никто не запрещает тебе сделать сделать специальный резолвер, который соберёт все и вернёт структурированные данные, грубо говоря рест в graphql. Парсинг перед исполнением дело страшное, согласен. Запрос на интроспекцию весьма тяжёлый. С тем же парсингом, он не должен парсить до конца, он должен парсить до лимитов, и это то, что он делает. Если пугает, то сделай лимит на вложенность 2-5 и он глубже не полезет, а сразу выкинет ошибку. При нахождении левой директивы в запросе или дубликата, можно тоже сразу выкидывать ошибку.
Проблему 1 и 2 полностью решает библиотека nestjs-graphql-tools https://github.com/Adrinalin4ik/Nestjs-Graphql-Tools. Что касается авторизации полей это нормально проверять что можно отдавать авторизованному пользователю, а что нет. В ресте этого нет, т.к. концепт другой, однако рест может отдавать много лишнего и отсутствует гибкость (в этом его минус), особенно чувствуется, когда тебе от юзера надо одно имя, а ты тянешь его полностью, либо городишь специальный путь на запрос пары полей из модели. Это же можно отнести к большому бойлерплейту. С кешированием есть проблемы, однако это не везде применимо, а где применимо они либо частично, либо полностью решены. Эффективность graphql точно не ниже чем рест. Любой запрос можно решить по разному. Если у тебя жирная кверя и супер глубокая вложенность, то никто не запрещает тебе сделать сделать специальный резолвер, который соберёт все и вернёт структурированные данные, грубо говоря рест в graphql. Парсинг перед исполнением дело страшное, согласен. Запрос на интроспекцию весьма тяжёлый. С тем же парсингом, он не должен парсить до конца, он должен парсить до лимитов, и это то, что он делает. Если пугает, то сделай лимит на вложенность 2-5 и он глубже не полезет, а сразу выкинет ошибку. При нахождении левой директивы в запросе или дубликата, можно тоже сразу выкидывать ошибку.