In Dgraph, lists are represented as an unordered set with non-nullable values. The GraphQL spec is ambiguous in parts, so @abhimanyusinghgaur has clarified with the GraphQL WG:
Null values are allowed. A field of type [Int]! can be set to [1, null, 2, null].
Duplicate values are allowed. A field of type [Int!]! can be set to [1, 1, 2, 2].
Since this caused some confusion earlier I will clarify: lists in GraphQL must be stored using an ordered data structure, but they needn’t retain input order.
This means that it is perfectly acceptable for an input of [1, 2, 3] to return [2, 1, 3] when querying, but every subsequent query must also return [2, 1, 3] unless the list is modified. Dgraph already does this.
However, I think a list that retains the order of input would be a nice-to-have, and it does not violate the spec. There have been requests for it, and if lists are reworked to support duplicates and null values, it may be feasible to implement this too, since we no longer need to use a set to represent the data.
Even this is not mandated by spec, but it is just how dgraph works. The clarification I got for lists in reference to order is this:
The order in which the GraphQL server sends the list items, should be the same order in which the client parses them. So, the client should use an ordered data-structure for deserializing the server output.
There is no requirement from the spec to have the GraphQL server return an ordered list. It is completely implementation-dependent.
Seeing lists from the perspective of JSON lists, clarified all the confusion for me. i.e., whatever can be transported by JSON is also allowed by the spec.
And JSON input, storage, and output preserves the order from input to output. Order of object properties may be reordered as MySQL does, but the arrays will always maintain the same order.