Как создать корневой запрос/аргумент(ы) мутации в API GraphQL?

#graphql

Вопрос:

Мне нужен «глобальный аргумент», который может быть указан (не более) один раз и применяется ко всему запросу (с любым количеством запросов/мутаций внутри). Если бы я мог попросить клиента указать это в query(arg: "value") {...} и/или mutation(arg: "value") {...} я бы это сделал… но я понимаю, что это зарезервировано для «переменных». Мне не нравятся другие варианты, о которых я знаю:

  1. Заголовок HTTP — связывает это только с HTTP, не в схеме, плохо документировано.
 POST /graphql X-MyArg: some-value ...  {"query":"{someQuery{id name}}"}  
  1. Параметр строки запроса HTTP (URL) — тьфу… Мне нравится один общий URL-адрес, также те же проблемы, что и с (1)
 POST /graphql?myArg=some-value ...  {"query":"{someQuery{id name}}"}  
  1. Введите промежуточное поле-оболочку, чтобы предоставить этот аргумент … но это делает все дольше, и я не знаю способа сказать «это должно быть указано/запрошено не более одного раза», в то время как поддержка нескольких случаев не имеет смысла, по крайней мере, для некоторых из них (например, аутентификация / авторизация / безопасность, связанные и другие).
 POST /graphql ...  {"query":"{wrapper(arg: "some-value"){someQuery{id name}}}"}  
  1. Обманывать/взламывать и требовать $arg , чтобы переменная (предназначенная для определения клиентом (- ами) API) была указана, в то же время каким-то образом предотвращая появление структуры, которую я использую, когда на эту переменную фактически нигде не ссылаются изнутри.
 POST /graphql ...  {"query":"query($arg:String){someQuery{id name}}","variables":{"arg":"some-value"}}  

Кто-нибудь может помочь? Я что-то упускаю или меня действительно заставляют выбрать одну из этих ядовитых таблеток?

Комментарии:

1. …. и причина/требование для » необходимости иметь «глобальный аргумент» » заключается в … ?

2. Это не должно иметь значения, и я не могу раскрыть это. Дизайн правильный, вы не должны пытаться идти туда, чтобы сорвать вопрос. Конечно, я могу изменить дизайн, чтобы он соответствовал инструменту, но именно это было бы неправильно.

3. (Я отметил это как вариант № 3, кстати)

4. Обычно это должно быть #1 или #2 (или и то, и другое; зависит от ожиданий безопасности; использование анализа промежуточного программного обеспечения в контексте) … «Я не могу раскрыть» реальное/лучшее решение без какого-либо (даже искусственного) прецедента/контекста использования … вам это тоже может не понравиться :p

5. @xadm: Спасибо, я так и подозревал.