Hacker News new | ask | show | jobs
by dwwoelfel 1256 days ago
A few ideas to improve the schema based on looking at the examples:

1. Make `globalId` part of a "Node" interface that all of the types implement. This will work better with tooling like Relay (used for refetching and caching). It will also let you add a `node` field that can be used to fetch any node in the graph.

2. Make the sort input an enum so that you have `sort: TITLE_DESC` instead of `sort: {by: TITLE, order: DESC}`.

3. Implement the connection spec instead of returning a list of items: https://relay.dev/graphql/connections.htm. This will let you add pagination data to the field and other useful info like totalCount.

4. Spin up a postgraphile instance with the `@graphile-contrib/pg-simplify-inflector` and `postgraphile-plugin-connection-filter` plugins and copy everything they do.
1 comments
leoloso 1256 days ago
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"}}`

link