"variables" are empty

[ziflex]

Object, which is sent to the server, has a variables property.
Accordingly to GraphQL spec it should contain query's variables.
But it turned out that Relay compiles the query and inserts variables inside of it.
Is it bug or feature? With current implementation it's almost impossible to use these values outside of GraphQL.

[josephsavona]

Great question! This is intended - scalar values are printed inline, while input objects and enums are printed and sent as variables. This is somewhat of an arbitrary choice, though we have found that it's easier to debug queries with unlined argument values.

[ziflex]

@josephsavona, is it possible to change this behavior?

[josephsavona]

Possible, yes, but what's the use case? As I said, the current approach has made queries easy to read and debug.

[ziflex]

@josephsavona I need these values before data resolving in schema.
So, what can I do to change it?

[josephsavona]

Ah, if I understand correctly you're trying to access the argument values at each resolve function. In GraphQL, It doesn't matter if the arguments are printed inline or using variables: they're accessible the same way, via the second args param to resolve. The graphql-js guide has an example at http://graphql.org/docs/getting-started/ (Search for "args").

[ziflex]

@josephsavona no, I need it outside of GraphQL pipeline, before it reaches it, in a middleware. The thing is that I use dynamically generated schemas for some forms and based on root query I need to define which schema I should use for particular request.
Therefore, I need to be able to get these values from request's body.

[josephsavona]

I see - thanks for clarifying your use case. While changing the way queries are printed may work this is a brittle approach as we may change the format at any point. Instead, it sounds like this is ultimately a problem of identifying (on the server) the schema that the client is using. The general solution in Relay to transmitting extra information between client and server is to use a custom network layer. With this approach, you can send the printed query (regardless of inclined variables or not) along with whatever metadata you need to identify the schema being used.

[ziflex]

@josephsavona custom NetworkLayer is not an option, because during single session there might different forms which require different GraphQL schemas.
So, that's why I wanted to pass data with query in order to define proper schema.

[josephsavona]

Hmm. A custom network layer does seem like the right approach here, but we'd need more information to give suggestions about implementing it:

• do you have multiple distinct apps each with their own schema, or one app that uses multiple schemas? (aside: if one app, why not merge the schemas?)
• how did you configure babel-relay-plugin and how are you transforming your app code if there are multiple schemas?

The gist of these questions is that Relay requires the schema for a file to be known statically in order to transform it. Given that the schema is known statically per file, it should be possible to use that mapping in a custom network layer.

[ziflex]

@josephsavona let me explain what app does.
We have 2 services: Composer and Renderer.
Composer creates form definitions with fields, data sources for them and validation rules. During composing the form, we generate schemas and compile queries for dta fetching and mutation and store them as a part of definition.

Renderer is supposed to render form based on this definition.
Here Relay comes.
We have 2 root containers (agreed, probably it's bad), first root query fetch the form definition - here we have statically defined query, and once we got it, execute 2nd root query for data fetching using dynamically compiled query from fetched definition. And here, we've got a problem. On server side, we need to know, which schema should be used, since every form have it's own schema. That's why I need to have these variables in request body.

[josephsavona]

Thanks again for clarifying. As I mentioned above, relying on how Relay formats queries is a brittle approach that we don't recommend. Further, we'd prefer to avoid adding constraints on the formatting just to satisfy one product - this would limit our ability to iterate to possibly make improvements that benefit all users.

That said, my original suggestion seems to apply: the supported approach here is to use a custom network layer. Since your top level root container fetched the form, it must know to what schema that belongs. It can then inform your network layer what schema to use for the inner query.

An alternative implementation of a custom network layer is to access the query representation itself (via RelayQueryRequest.getQuery()) to get the instance of RelayQueryRoot - and from there determine the variables being used (on the client), such that it can pass metadata to the server.

[josephsavona]

@ziflex I'm going to close this since it isn't a bug or enhancement. Feel free to ask follow-up questions here, or even better on stack overflow or in the discord channel.

[ziflex]

@josephsavona ok, thanks for help!