Skip to content

Instantly share code, notes, and snippets.

@yuchenQ
Last active August 30, 2020 23:48
Show Gist options
  • Save yuchenQ/5ae3f864f0364860f1b91e252c4bd8dd to your computer and use it in GitHub Desktop.
Save yuchenQ/5ae3f864f0364860f1b91e252c4bd8dd to your computer and use it in GitHub Desktop.
# BEFORE: defining schema type based on what we get from API
# when we call "GET" content API:
type content {
workId: String! # must have a string
artistId: String!
tags: [String!]! # Array<String>
sourceImages: [sourceImage!]!
}
# when we call "GET" recommandedContent API:
type recommandedContent {
workId: String!
artistId: String
tags: [String]! # [] | Array<String>
}
# when we call "DELETE" deleteContent API:
type deleteContent {
workId: String # null | String
}
# ================================================================================================
# AFTER
# Since we wanna consolidate `recommandedContent + deleteContent` by reusing the `content` type
type content {
workId: String
artistId: String
tags: [String] # null | [] | Array<String>
sourceImages: [sourceImage!] # null | Array<String>
}
type mutatedRecommandedContent {
content: content
}
# this reflects regularity of API response
type mutatedDeleteContent {
content: content
}
# ================================================================================================
# Questions:
# 1. What is the benefit from trying abstracting common types & reuse existing types?
#
# 2. Should the schema type exactly reflect what we get from the backend?
#
# 3. Bonus question: How to achieve a readable & maintainable & resuable schema?
#
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment