Processing GraphQL input variables.

GraphQL has input object types defined in the schema. This means that one could look up what they are and use an variable of one of those types, such as InsertUser or even FilterUser or OrderUser. The first one of these examples mostly contains data, but if User has links it may also contain command for filtering objects to be linked as opposed to raw data. The other two are just commands abstracted away into input objects.

We use these commands from input objects to compile the query, so these “variables” aren’t really query parameters, they may just be the query itself. E.g. OrderUser variable could be passed as {"order": {"name": {"dir": "ASC"}}}. The final query will have an ORDER BY .name ASC clause, but won’t have any parameters.

However, the more likely application of passing complex data to a GraphQL query is some kind of bulk insert scenario, where the data is an array of InsertUser objects for example. In theory if we restrict the elements to be homogeneous in structure (such that they all fit the same query shape) it would be possible to generate a FOR ... INSERT query that uses JSON functions to decompose the original JSON input blob into a bulk insert.

The bottom line is that the current implementation is limited to dealing with only scalar input variables and doesn’t have a way of dealing with the above scenarios. In order to make it fully compatible with them 2 changes need to happen:

1. There logic that interprets “commands” needs to be abstracted in a way that it works both on actual GraphQL literals and variable values.
2. In case of bulk inserts an additional check needs to be performed to validate that the insert shape is the same across the entire bulk operation.

This is related to #1229

[1st1]

I realize that commands in variables present problems with caching

Not only that, they are essentially a way to change a query substantially – add extra filters, nested inserts, etc. I guess for this kind of functionality we’ll have forms API some day, but for now we should keep our GraphQL simple.

[elprans]

I’m also leaning to restrict variables to data only (i.e no commands).