Graphql

The Graphql schema is public and thus hard to change. Because it is hard to change, naming is very important!
Read this article about building evolvable schemas
Read this article about mutation naming (Anemic Mutations)

Schema types and properties

All Graphql types should have

• id: ID!
• createdAt: Date
• updatedAt: Date
  Delete for deletions, remove to ‘remove from’:
• deleteCar(id: ID!)
• removeOptionFromCar(optionId: ID!, carId: ID!) ‘Number’ can be shortened to Nr:
• chamberOfCommerceNr
• branchNr
• phoneNr
• houseNr
• houseNrSuffix EmailAddress should be written out full, not shortened to email
• emailAddress

Naming conventions

• My- Queries and mutations that use data of the currently logged in user should use the My prefix. I.E. MyDeal retrieves the Deal of the currenly logged in user. updateMyUserProfile updates the profile of the currently logged in user.
• Retrieving - Retrieving data happens by type. I.E. getting an Article happens with the query Article() NOT getArticle(). This follows graphcool’s/Prisma’s query naming convention.
• Retrieving multiple - Retrieving multiple entities uses all. I.E. allArticles()

PubSub Topics

Use lower-kebab-case naming for PubSub topics, as shown in the GCP documentation.

Code naming

Don’t make life hard for your fellow developers, read this article about naming psychology.

• Names should be descriptive: const userId Perfectly understandable. ‘const uId’ is NOT, and it is horrible.
• Don’t be TOO descriptive. sign(contract: Contract) this is descriptive enough. ‘signContract(contract)’ is redundant.
• Scope/context aware naming: If the scope of your variable is tiny, it is ok to have a short name for your variable: contracts.filter(c => !!c) C is obviously contract in this example.
  validateEmailAddress(email: string) There is no ambiguity in email in this context
  Phone.emailAddress - phone.email could mean an actual email message here.

---