| 1. I do already have the `Node` interface, but it's called `IdentifiableObject` as I cannot follow the convention, because the interface has 2 fields: - id: the actual WordPress ID - globalID And the convention says that Node can have only a single field: https://graphql.org/learn/global-object-identification/ 2. It's better to keep it as an Input Object as it's more extensible by plugins, which may have their own fields to sort by. Also existing resolvers can be reused, instead of having to create a dedicated enum for each single type every time. I think it's more elegant than using enums. 3. You have the totalCount field already for every field. Eg: there's `posts` and `postCount`, `users` and `userCount`, etc. I could implement connections, and maybe I will in the future, but I need a compelling reason to do it: It was needed by Facebook for their never-ending feed, but as WordPress sites are naturally paginated, I believe it's not a real need. And connections also bring some pain: I know that WPGraphQL has had many issues with it, maybe even ongoing, with some edge cases where it doesn't work well, and if I'm not mistaken it needs additional DB calls. 4. The plugin already attempts to provide all the filtering supported by WordPress. Check out all the `filter` inputs (in fields `posts`, `users`, `comments`, etc) (In addition, I'll be releasing extra functionality via directives some time in the future) And it uses the "oneof" input object to simplify fields, so you have `post(by: {id: 1}}` and `post(by: {slug: "some-slug"}}` |