Code Style Guidelines for GraphQL

[buskamuza]

Document code style guidelines for GraphQL schema. Currently, the following unwritten agreements exist:

1. quantity should be used, not qty
2. Camel case SHOULD be used for queries and mutations (root-level fields)
3. Camel case SHOULD be used for arguments 3.1. Investigate if Snake case should be used (in case it's already more widely used than Camel case)
4. Upper camel case SHOULD be used for types
5. Snake case SHOULD be used for fields

• Investigate if the above rules make sense or other agreements should be introduced. Document the agreements as guidelines.
• Investigate if any other code style guidelines make sense and document them.

[jednano]

1. I agree that we shouldn't be shortening names.
2. Agreed.
3. Not sure what else there is to investigate. The GraphQL docs themselves use camel case arguments, which is consistent with everything else.
4. Agreed.
5. Again. GraphQL docs use camel case everywhere for fields. I think anything else would be considered bad practice.

The most common consumer of a GraphQL API is a browser (i.e., JavaScript). As such, we should conform to JavaScript's patterns and use camel case throughout.

• JavaScript clients shouldn't have to change the case into something else in order to have consistent casing in their applications
  • Any such conversions cause overhead in the client, which is unacceptable.
  • A non-native function is required to perform such conversions, which adds additional footprint to the JavaScript payload.

[buskamuza]

What do we do with EAV attributes - they are snake case?

• Convert them for consistency

[orlangur]

@buskamuza 2-5 why SHOULD and not MUST?

[stijnbernards]

1. I agree that we shouldn't be shortening names.
2. Agreed.
3. Not sure what else there is to investigate. The GraphQL docs themselves use camel case arguments, which is consistent with everything else.
4. Agreed.
5. Again. GraphQL docs use camel case everywhere for fields. I think anything else would be considered bad practice.

The most common consumer of a GraphQL API is a browser (i.e., JavaScript). As such, we should conform to JavaScript's patterns and use camel case throughout.

• JavaScript clients shouldn't have to change the case into something else in order to have consistent casing in their applications

  • Any such conversions cause overhead in the client, which is unacceptable.
  • A non-native function is required to perform such conversions, which adds additional footprint to the JavaScript payload.

I Agree with you on 3 and 5 GraphQL response fields must be camelCased.