1. Naming rules
2. Type rules
- 2.1. Use custom scalar types if you want to declare fields or args with specific semantic value.
- 2.2. Use Enum for fields which contain a specific set of values.
3. Field Rules (Output)
4. Argument rules (Input)
5. Rules of lists
6. Mutation rules
7. Rules of linkages between types (relationships)
- 7.1. GraphQL schema should be "hairy"
8. Authorization
- 8.1. Schema diffing based authorization
9. Other rules
- 10.1. Use markdown for documentation
A. Appendix
- A-1 Useful links
Credits

1. Naming rules

GraphQL uses regexp /[_A-Za-z][_0-9A-Za-z]*/ to validate property and type names. In other words, GraphQL lets you use multiple styles, such as camelCase, under_score, UpperCamelCase end CAPITALIZED_WITH_UNDERSCORES. Notice that that kebab-case is not supported.

The support for multiple naming conventions leads to a question of which one to use.

We looked at Eye Tracking's research that tried to analyze camelCase and under_score. However, it didn't find any favorites.

In the absence of conclusive research, we suggest following these rules:

1.1. Use camelCase for GraphQL fields and arguments.

1.2. Use UpperCamelCase for GraphQL types.

1.3. Use CAPITALIZED_WITH_UNDERSCORES to name ENUM types.

1.4. Avoid using get in your Query resolvers.