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

3.1. Give descriptive names to fields.

The rule goes without saying. Field names should communicate domain-specific meaning and not the implementation details. It's really stupid and simple rule. Consider the following type:

type Meeting {
-  body_html: String # BAD
+  description: HTML # GOOD
}

Whoever sees the type Meeting for the first time will be guessing what is exactly stored in the bodyHtml field. While backend developers can add a description to fields it is much easier and more clear to have a name that doesn't require additional explanation. A name that clearly communicates its domain meaning. So in the database it can still be bodyHtml while in API it will have nice and concise description field with a proper HTML type saying everything without additional explanations.