Use serde_json::Map without preserve_order

[kamilkisiela]

Currently, we’re using serde_json for subgraph communication and the final response serialization. It uses preserve_order features and IndexMap under the hood of Value::Object.

While preserving key order is desirable in the final response, it comes at a big performance cost (10-15% latency improvement).

serde_json has to be compiled with or without the preserve_order feature. We can't do much here.

We could implement FastValue enum as an alternative to Value enum and replace do FastValue::Object(HashMap), but I'm not sure it's a good idea...

The other approach would be to store the position (in the query) of fields and implement a custom serialization logic that depends on this position. This is what I prefer to be honest.

When deserializing, the order of keys in Object does not matter, it only matters when we serialize the response and send as bytes to the client.
This clearly indicates that preserve_order is not needed.

[linear]

GW-418 Use serde_json::Map without preserve_order

Currently, we’re using serde_json for subgraph communication and the final response serialization. It uses preserve_order features and IndexMap under the hood of Value::Object.

While preserving key order is desirable in the final response, it comes at a big performance cost (10-15% latency improvement).

serde_json has to be compiled with or without the preserve_order feature. We can't do much here.

We could implement FastValue enum as an alternative to Value enum and replace do FastValue::Object(HashMap), but I'm not sure it's a good idea...

The other approach would be to store the position (in the query) of fields and implement a custom serialization logic that depends on this position. This is what I prefer to be honest.

When deserializing, the order of keys in Object does not matter, it only matters when we serialize the response and send as bytes to the client.
This clearly indicates that preserve_order is not needed.