Repo: https://github.com/MoonHi-ghway/schema-design-workshop
- 5 scalar types: Int, Float, Boolean, String, ID
- Fields are nullable by default
- Convention is for enum types to be ALL CAPS
- Input type: wrapper around a set of fields passed into a mutation
- input should be named similar to the mutation.
PostPhotoandPostPhotoInput
- input should be named similar to the mutation.
- Subscriptions handle real time use cases
- You can make relationships between the same objects. For instance, you can have a City that has connections to other, nearby Cities
- Design for the client. This should always be your first thought.
- Use specific, consistent naming
- Custom objects over scalar values
const server = new ApolloServer({ typeDefs, mocks: true });does all the mocking for you. Sweet.- Useful patterns: specific queries
petById(id: ID!): Pet! petByName(name: String!): Pet!
- Input types kind of map to forms on the front end
- Name mutations like verbs
- Fragments aren't in your schema, they're part of the graphQL query language you can use while querying, whereas inputs are part of the actual schema definition language
- Have mutations return Payloads as custom objects so you can add fields
- "mutation response object"
- Design your schema so that you don't have to answer lots of questions about your schema. Naming is super important. Make it as simple as possible for the people consuming the schema. Keep it simple, be declarative, so that when you read it, it just naturally makes sense. It's all about communication.
- https://github.com/graphqlworkshop/schema-activity/blob/complete/src/typeDefs.graphql
- Union Types: handle returning lists of different types
union AgendaItem = StudyGroup | Workout. Then you specify what fields you want for each type, and they don't have to be the same across types. Uses the fragment syntax. Allows you to return a list of different types, which can be wildly different objects. - Interfaces: kind of like inheritance. Things that implement an interface must implement all fields in the base class. Custom fields can then also be added. Use when your different objects share common fields.
- Don't use interfaces as a way to package variables. You still are trying to communicate and document. Don't take shortcuts when designing a schema, be declarative and overly descriptive.
- Pagination:
- Offset pagination: pagination by page (limit, page)
- Cursor-based pagination: (limit, after). Give me a certain number of results after a certain unique ID.
- random metric: they use unions about 85% of the time compared to interfaces 15% of the time
- Interfaces borrowed from OO and are kind of an "enforcement" concept