Жалко, конечно, что пока не работает оно :(

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

Ну надо по сути как тут делать
https://t.me/graphql_ru/46957

Соответственно, для метаданных Extensions (https://docs.nestjs.com/graphql/extensions)
А для дополнительных сведений в схеме Directive (https://docs.nestjs.com/graphql/directives) с подменой принтера схемы

У меня в ближайшее время план форкнуть к принтер, сделать из него npm модуль и использовать внутри @nestjs-graphql с подменой при сборке

Потому что есть кейсы, где без директив ну вообще никак

Собстна, тебе с Apollo Server тоже ничего не мешает подменить принтер схемы при необходимости

Пока кейсов не было, к счастью, но думаю они возможны)

Кстати а jit подружить с type-graphql не пробовали?

Кстати, даже не видел такого. Речь про эту репу я так понимаю? https://github.com/zalando-incubator/graphql-jit

Да, с аполло если подкидывать обычную схему все работает как отлично, с тем же mercurius он из коробки есть, а вот в автосгенерированную схему от typegraphql не выйдет

Мне на прошлом проекте пришлось на файлики перейти, разбор схемы занимал очень много времени

На самом деле когда говорим про то, что в графкуэле зашито 2 языка
- язык SDL для объявления схемы при старте сервера (schema first approach)
- язык GQL для написания запросов в рантайме

Тоже самое справедливо и для директив (посмотрите в спеке DirectiveLocation)
- TypeSystemDirective директивы для SDL
- ExecutableDirective директивы для GQL

Так вот когда для директив указан один из локейшенов ExecutableDirective то они вроде как экспоузятся в интроспекции. А вот TypeSystemDirective ни в коем случае не должны попадать в эту интроспекцию, это строго серверные метаданные.

Но по какому-то кривому обстоятельству директивы specifiedBy и deprecated экспоузятся в интроспекцию.

Т.е. получается, что в спецификации GraphQL явно не хватает 3го типа директив, типа PublicTypeSystemDirective. Т.к. по безопасности вроде нельзя серверные директивы типов отдавать наружу, но при это существует две серверных директивы, которые обходными путями все-таки затащили в интроспекцию.

Что могу предложить
- не использовать пока для клиентской стороны директивы.
- поступить как аполло со своим федерейшеном - тупо завести в корне пару полей, которые будут возвращать вам необходимые метаданные для вашего клиента

"Пропинать" working group через rfc, чтоб завели такие директивы, и в частности Ли Байрона – очень доооолгая затея. Может пройти год, а то и два, пока это дело станет доступным.

Поэтому и рекомендую заводить в корне свои магические поля, которые в обход графкуэльной интроспекции вернут вам дополнительные метаданные.

И все таки ради интереса, хотелось бы услушать про ваши кейсы где "где без директив ну вообще никак"...

Второй вариант, кстати, очень интересный - даже не думал о нем. Куда копнуть, чтобы понять что там в аполло сделали? В доках есть?

Без директив вообще никак на мой взгляд в nullable/undefinable проблеме (https://t.me/graphql_ru/44684). Я для себя сделал вывод, что единственный путь решения проблемы, выглядящий наиболее "нативно" - генерация директив в схему на стороне сервера и соответственно своя кодогенерация на фронте, которая бы учитывала в том числе декораторы

Тут можно почитать https://www.apollographql.com/docs/federation/federation-spec/

Все до безобразия просто. Они завели два поля в квери

extend type Query {
  _entities(representations: [_Any!]!): [_Entity]!
  _service: _Service!
}

где _service возвращает SDL с внутренними (серверными) директивами как им надо. Чтоб можно было на гейтвее собрать большую схему из разных сервисов.

а _entities просто возвращает в рантайме данные для сущности по ее id, который дергается опять таки гейтвеем, когда расширяются и вяжктся типы между несколькими сервисами.

Спасибо! Думаю, что такой подход действительно можно для некоторых кейсов применять. Вопрос с nullable/undefinable это правда не решит, потому что требует выполнения запроса, но инфа все равно очень полезная

> Опциональность полей может означать:
> * Что поле можно не передавать или обнулить его значение при помощи null
> * Что поле можно не передавать, но нельзя обнулить
> * Что поле должно быть обязательно передано, но может быть обнулено

О хороший вопрос!
У меня решается просто правилами, без директив и всяких или или – Если поле передано в переменных, то взять его значение и записать в базу.

И все ньюансы уже закладывать в сами инпут типы.
Для мутаций create - всегда явно помечать обязательные поля. Для update обязательные поля не помечать как NonNull, чтоб их можно было не передавать (не изменять). Если необходимо какие-то поля удалить, то заводим отдельную мутацию или отдельный аргумент, где явно передаем список полей на удаление.

На практике, таких операци, где надо удалить поле у меня было очень мало. И просто обходились дополнительной мутацией.

Я бы рекомендовал от общих кейсов перейти к конкретным, и вы увидите что это не настолько большая проблема. И 99% проектов с такой проблемой не сталкиваются, либо спокойно валидируются в рантайме, либо обходятся доп описанием в дискрипшене к мутации/аргументам.

PS. Мир не идеален, но вы можете сделать идеальный дескрипшн для людей. И при небольшой сноровке, даже парсить эти дескрипшены на клиенте через интроспекцию. И тогда вам точно не нужны будут директивы.

Накостыльте спецсимволы в описании 😉 Всяко лучше, чем в корне поля крутить как в аполо федерейшене.