Так в итоге просто идет создание своего набора резолверов. которые просто вручную пробрасываются на призму, так?
типа

function productsResolver(args) {
    return prisma.products(args);
}

хитрость в том, чтобы автоматически скинуть сразу все

а если что-то не нужно, то как быть?

скрыть например доступ к полю password_hash у юзера

или например вообще наружу не пробрасывать query -> users

или ладно, может у тебя есть пример  проекта с биндингами?

нашел
https://github.com/graphql-boilerplates/node-graphql-server/tree/master/basic

посмотри на это https://github.com/maticzav/graphql-shield

огонь, спаибо

а можешь подсказать, как привязать binding к проекту?
Я так понял нужно сделать схему бд, потом схему Query и Mutation, в которой нет сущностей, а только набор запросов и мутаций, и потом как?

спасибо

Кто знает, почему prisma-binding не возвращает внутренние поля. Например, когда запрашиваю prisma.query.products() - возвращает всё, кроме categories

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

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

переделал под prisma-binding

Лично я, уже больше 4 месяцев работая на проекте, использующем кодогенерацию (не prisma, а собственное решение компании) уяснил что для хоть мало-мальски больших приложений с большим количеством серверной логики не стоит прибегать к кодогенерации.
Приходится использовать, как писали выше, два уровня graphql-api: с одним общается клиент, с другим - бэкенд, для доступа к БД.
Я работаю по такой схеме:
1) Создаю/меняю схему данных с помощью StarUML (редактор uml-схем).
2) Генерирую код на основе схемы. Генерируется полное GraphQL-API со всеми crud операциями, фильтрацией и пагинацией, по всем канонам Relay.
3) Дальше - самое веселое. Я пишу кастомные запросы и мутации для уровня клиента. И  здесь мне уже нечем генерировать код - всю пагинацию, сортировку, фильтрацию я должен делать сам. При написании resolvers для этих кастомных запросов использую сгенеренное graphql-api. И здесь вторая проблема - все, что сгенерено - не оптимизировано так как я бы это сделал вручную при исопльзовании mongodb driver или mongoose. Ведь множество операций я, зная логику приложения, мог бы писать асинхронно, мог бы отправлять пользователю ответ а сам доделывать нужные мне операции, просто имел бы больше власти. Не вижу профита в использовании graphql для доступа к БД по сравнениию например с использованием mongoose.

Сделал для себя вывод, что генерация удобно только там где клиент полностью отображает структуру данных в БД

О! Мой клиент.

Посмотри https://github.com/graphql-compose/graphql-compose

Эта штука как раз для того чтобы генерить и редактировать схему как тебе нужно через набор своих функций помогаек.