Model-specific types for ordering

[danielrearden]

For each model, we currently have a matching FilterInput type that's used for filtering. Would it make sense to do the same for sorting? Minimally, this could look like this:

input NoteOrderByInput {
  field: NoteOrderBy!
  order: SortDirectionEnum = ASC
}

enum NoteOrderBy {
  title
  description
}

By using an enum for the field value, we improve the experience for consumers of the API by enabling autocompletion for it. We can also leverage GraphQL's type system for validating the value rather than necessarily having to do it at the model level.

Ideally, the spec would also support sorting by related model properties. Of course, this also means supporting sorting by aggregate values for one-to-many and many-to-many relationships, so I understand if maybe that's overkill for the spec. However, individual services should at least be able to extend the spec to add this functionality. Unfortunately, neither the existing format nor the one above lend themselves to doing that.

Something like this would be more flexible:

input NoteOrderByInput {
  title: SortDirectionEnum
  description: SortDirectionEnum
}

Now if I want to extend the spec by adding sorting by a relationship field, I can do:

input NoteOrderByInput {
  title: SortDirectionEnum
  description: SortDirectionEnum
  comments: CommentAggregateOrderByInput
}

That's a bigger deviation from the existing spec, but it's also more flexible.

[wtrocki]

It is amazing to have your involvement in such early stage of the spec! Thank you so much!

While spec is driven by community, we need to keep some of the initial assumptions right.
One of it is that CRUD rules should be simple enough so you could write this methods by hand and do not generate large fields that could be useful at development time to sacrifice overall schema size and API visibility. While this is something great to have - we will need to think how to also meet criteria mentioned above.