A convention set by our glorious leader @dzucconi was that fields that return collection counts would all move into their own counts object, as to not muddy the API with multiple *_count fields.
While it feels like overkill to already start doing this when a type gains its first count field, I would argue that it makes the overall API more consistent/predictable and also ensure we don’t need to move fields around and deprecating them once a second count field gets added.
When adding fields, we should try to start codifying whether or not that field is supposed to always return a value or if it’s optional. E.g.
new GraphQLNonNull(type)This information is especially useful in Eigen with its slow deploy time, where fixing bugs and rolling out updates is very time consuming.
GraphQL has a special type to convey a value holds an identifier. Thus far we have been using GraphQLString mainly, but going forward we should use GraphQLID instead.
In addition, in most cases the ID is something that maps to an underlying database, in which case the ID cannot be null, so typically the definition would look like:
new GraphQLNonNull(GraphQLID)