Fields are not serialized in order

[That3Percent]

According to the GraphQL spec, fields should be serialized in order.

7.2.2 Serialized Map Ordering
Since the result of evaluating a selection set is ordered, the serialized Map of results should preserve this order by writing the map entries in the same order as those fields were requested as defined by selection set execution. Producing a serialized response where fields are represented in the same order in which they appear in the request improves human readability during debugging and enables more efficient parsing of responses if the order of properties can be anticipated.

The current implementation instead serializes the field in alphabetical order such that the query

{
  entities(first: 1) {
    owner
    id
  }
}

produces

{
  "data": {
    "entities": [
      {
        "id": "0x4027de966127af5f015ea1cfd6293a3583892668",
        "owner": "0x029aa20dcc15c022b1b61d420aacf7f179a9c73f"
      }
    ]
  }
}

with the field orders id and owner in reverse order from what the spec requires.

[That3Percent]

This would be a breaking change, so is subject to the same considerations as #2868

[leoyvens]

Last time we discussed this and decided to close #601, we decided we'd rather specify alphabetical order than the spec order.

[That3Percent]

There are a few arguments for following the spec:

Parser Performance
If one were to write an efficient parser for a #[derive] style GraphQL library you can take advantage of the fact that you know the types of all values ahead of time and that keys are ordered in accordance with the spec. Doing so can save a considerable amount of memory and speed compared to a naive HashMap style parser which is not amenable to streaming.

Duplicate Field Names
The GraphQL spec does not require that field names be unique - only variable names.

GraphQL does not require any particular serialization format. But, JSON also does not require unique field names (it says SHOULD).

There are cases where this makes sense. For example:

{
  accounts(first: 1, block: { number: 5 }) { 
    id
  }
  accounts(first: 1, block: { number: 6 }) { 
    id
  }
}

You may use renaming for this, but it is not necessary (especially if using a streaming style parser to pull out a list of changes to the entity over time).

Serializer Performance
Should we change from BTreeMap to Vec this will save memory and time when serializing.

The spec is default
When breaking with a spec, the burden of proof is on you to provide a really good reason that the spec cannot be complied with or is detrimental. There is no such reason here.

[That3Percent]

It turns out that the GraphQL in the Duplicate Field Names section is invalid, as pointed out to me by @leoyvens.

http://spec.graphql.org/October2021/#sec-Field-Selection-Merging