SpreadsheetUrlDownload und UrlDownload Steps für GraphQL APIs

Hallo Synesty Team,
wir nutzen nun vermehrt die GraphQL API von Shopify. In der GraphQL API Spezifikation werden Daten oft als Variable übergeben, bzw. viele Mutations in Shopify gehen gar nicht ohne Variablen. Aktuell müssten Mutation und Variablen im POST Body gesendet werden, es wäre aber super cool, wenn man wie in gängigen GraphQL Clients (z.B. GraphiQL) die Query und die Variablen separate eingeben könnte, siehe https://graphql.org/learn/queries/#variables

Vielen Dank für die Anregung.
Zum Verständnis: man kann ja jetzt auch im body mit Freemarker Variablen arbeiten. Auf das Beispiel bezogen wären kämen da eigentlich nur die geschweiften Klammern hinzu. episode könnte dann eine Flow-Variable sein.

query HeroNameAndFriends(${episode}: Episode) {
  hero(episode: ${episode}) {
    name
    friends {
      name
    }
  }
}

Geht es darum die gleiche Syntax (also nur $ ohne geschweifte Klammern) und ein JSON-Dictionary zu verwenden?

Nichtsdestotrotz packen wir das mit auf die Wunschliste.
Sobald der unser großes September Update durch ist, wollen wir uns verstärkt dem Thema HTTP-API Anbindungen widmen, worunter auch GraphQL fällt.

Ganz so leicht ist es leider nicht. Wenn man die Mutation Query und Variablen in einem HTTP Request schicken möchte, dann muss man diese in ein gemeinsames JSON Objekt packen und muss dann z.B. den Mutation String in eine Zeile packen, wohingegen die Variable(n) als eigenes JSON Objekt erstellt werden müssen. Es ist aber in allen mir bekannten GraphQL API Clients Gang und Gäbe, diese getrennt voneinander einzugeben:

In Synesty muss man das aber wie folgt umsetzen:

{
"query" : "mutation productAppendImages ($input: ProductAppendImagesInput!) {productAppendImages (input: $input){newImages {id originalSrc} product {id} userErrors {field message}}}",
"variables": { 
	"input": {
		"id": "gid://shopify/Product/${product_id!?trim}",
		"images": [
			{ "src": "${ImageSrc!?trim}" }
		]
	}
}

}

Man hätte es ein ganzes Stück leichter Queries aus Vorlagen und anderen Programmen einfacher zu portieren. Ich hatte leider mit der aktuellen Variante so meine Müh und Not, weil aus den Input Steps sind unerwartete Zeilenumbrüche oder Whitespaces eingeschlicen oder es zu API errors kam, weil man für diesen Weg wieder andere HTTP Header setzen musste…

Ok danke für die Verdeutlichung. Das klingt sinnvoll. Wir versuchen das bei der Planung zu berücksichtigen.