Open buskamuza opened 4 years ago
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.
What do we do with EAV attributes - they are snake case?
@buskamuza 2-5 why SHOULD and not MUST?
- I agree that we shouldn't be shortening names.
- Agreed.
- Not sure what else there is to investigate. The GraphQL docs themselves use camel case arguments, which is consistent with everything else.
- Agreed.
- 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.
Document code style guidelines for GraphQL schema. Currently, the following unwritten agreements exist:
quantity
should be used, notqty