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"}}`
The easy use case is to fetch data from a WordPress backend, and render your site using some JS library (React, Vue, Next.js).
But it can do much more than that (indeed, I like to think of GraphQL as the single tool to deal with any content-related task). These are some interesting use cases:
- Use a WordPress backend as an upstream server to manage all your data, and feed it to downstream servers/applications/websites
- Use GraphQL to extract information from 1 or more sources (such as users from the WordPress sites and the newsletter contact data from Mailchimp) and combine the data (and analyze it all together as a single dataset)
- Execute operations using GraphQL to adapt the content on your site, either as a one-off when installing a new site, or regularly. Eg: replace all "https://myoldsite.com" to "https://mynewsite.com" in the content after changing the domain or doing a migration, and execute queries to replace any "http://" to "https://" when a writer publishes a new blog post
- ETL (Extract, Transform, Load) of anything that involves content, whether stored in WordPress or external sources
- Interact with 3rd party services. Eg: Use GraphQL to connect to the Google Translate API and translate all the blog posts to a different language, or send a tweet after a blog post is published
- Send notifications (by email, Slack, etc) after something happened (a new post, comment, etc)
It can also be used with pipelines, and it can complement WP-CLI whenever it falls short of being able to do something. An example of this:
I myself use GraphQL via my plugin to connect to the GitHub API and fetch data from my releases, which can then be downloaded automatically and installed on my testing sites before running integration tests. I tried using WP-CLI directly for this and it fails, because the GraphQL API gives the .zip download file URL via a header, and this data needs to be extracted first. So I extract the header via GraphQL, and then inject it into WP-CLI, and the whole process is automated.
Many of these tasks, you can do them with dedicated plugins (such as for content migration). The beauty of GraphQL is that it's like a Swiss-army knife: you can write your own GraphQL query to execute many of these tasks, customizing it for your own needs, and avoiding to buy other plugins.
I will not say why this plugin may be better as I'm naturally biased, but you can check the features from both plugins (mine under https://graphql-api.com/features/) and see how they compare.
I haven't tried, but I believe that you can actually install both plugins side by side (using WPGraphQL's single endpoint, and my plugin's Custom Endpoint under a different route), and using the same GraphQL queries to test them, check their speed, usability, security mechanisms, configuration, extensibility, and anything else that could be relevant for your project.
> I think it's an attempt to convey the level of effort involved
Exactly this.
Also it's a way to point out that I took no shortcuts. When you have a deadline with a client, you start dropping features out, and adding @todos to fix something sometime in the future. Since this is my own project, I took the decision to do it well, at the cost of needing extra time and effort (eg: adding hundreds of tests, making services injectable and reusable, etc). The payoff will come in the future as the codebase proves to be more sustainable, and I require drastically less effort to maintain it.
There was a lot of rewriting stuff to make the engine GraphQL-first. Before, the engine received a different spec as input, and GraphQL worked behind an adapter. Now, the engine speaks GraphQL language.
Then completing the GraphQL schema, fully complying with the spec, and adding all the new features. That was quite a bit of effort.
Yes, there were many "typo" commits, changing simply one word. But there were also plenty of commits with dozens of changes and, in the initial rewriting stage, even hundreds of changes.
It really took 16k commits. I'll write a blog post on graphql-api.com and provide some more info (maybe sometime this weekend?).
No, that's not true. If you read the article, you will see it is a Show HN.
I added several GraphiQL clients to play with it, so readers can interact with my service.
The thing is this: I wrote my article to fit the "Show HN" status! In other words, it was in part because I wanted to rank high, that I added all those GraphiQL clients to the article.
Why? That's what I explain in my blog post: because Show HN gives me higher chances of ranking high. So I've been truthful to the spirit of it.
But the blog post could not have that title "GraphQL on WP will look like this" because it makes me look arrogant, because there's another solution, WPGraphQL, and that solution could also become the solution.
In other words: I'm doing the Show HN properly, but I wrote my blog post to fit the bill.
- 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"}}`