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.
About the IndieWeb, yes I know about it, and I want to use it. Partly that's why my static site is based on Hylia (https://github.com/hankchizljaw/hylia), because it has Webmentions in its roadmap. Alas! Nobody ever implemented it, and now Hylia is archived!
I don't have the knowledge of JavaScript to implement webmentions in Hylia all by myself (I'm more of a PHP developer). I could still try, but it'd take quite some time, which I don't have (I'd rather employ it on my actual project)
I absolutely agree with this. I believe that directives are among GraphQL's most important features, and seeing some servers dealing with them only as an afterthought makes me sad
This is a great idea! If my proposal starts getting support and I get to submit the issue for the spec, I'll certainly include block literals as part of it
This is the reason why I want to support such a query for my GraphQL server:
My goal is to allow users of my WordPress plugin (i.e. not just coders, but also non-techies, such as bloggers) to configure how the GraphQL server will behave through a user interface, with no coding involved whatsoever.
That query to send email notifications is then a use case all by itself, and a demonstration of what these features can achieve:
Using embeddable fields, starting from a `Post`, the UI would enable users to compose the notification message using placeholders `{{ title }}`, `{{ content }}`, `{{ date }}`, etc. With the flat chain syntax it gets better, since they could retrieve data from other entities, such as `{{ author.email }}`, or even iterating down from `Root` doing `{{ root.me.email }}`. Then this string is injected into the directive `@sendEmail` (which would be provided by some WP plugin), and added to the schema through IFTTT rules, as I've described here: https://blog.logrocket.com/adding-directives-schema-code-fir...
As a result, the user can install a WP plugin, add `@sendEmail` to the schema through configuration, and customize the email, without touching one line of code.
You mean a filter to transform the query from A (say, with syntactic sugar syntax) to B (with final syntax)?
I'm actually doing something similar in GraphQL by PoP, on a couple of levels: queries are decoupled into requested and executable, where they can differ in syntax, directives attached to them, and others. I wrote a bit about this strategy here:
PQL is a superset of the GraphQL query, so GraphQL by PoP transforms from GraphQL to PQL syntax and then executes it. For instance, this GraphQL query:
```
query {
posts {
excerpt
titleES: title @translate(from:"en",to:"en")
}
This works great. Only issue is when there's some error when retrieving the data, and I need to return an error message with the path to the problem in the query. In that case, the path corresponds to the transformed PQL query, not the original GraphQL query. (It would be possible to have a mapping for them, token by token, but I haven't coded it)
---
Btw, connected to PQL, GraphQL by PoP can support the embeddable fields feature because the PQL supports composable fields, which can be considered its superset:
I've also proposed composable fields for the GraphQL spec (https://github.com/graphql/graphql-spec/issues/682) but it hasn't got any support (that's why I'm now asking if embeddable fields could have some backing)
Hey everyone, I've added support to what I call "embeddable fields" on my GraphQL server:
```
query {
posts {
description: echo(value: "Post {{title}} was published on {{date}}")
}
}
```
I'm currently trying to find out if the GraphQL community would benefit from this feature. If so, I'll propose it for the spec, but as an optional (similar to cursor connections).
I've written a long post describing this new feature, which is the link I've shared. I've also started a discussion on /r/graphql:
"The syntax described and implemented in this project is a re-imagining of the GraphQL syntax, supporting all the same elements (field arguments, variables, aliases, fragments, directives, etc), however designed to be easy to write, and easy to read and understand, in a single line, so it can be passed as a URL param."
I agree with your statement that GraphQL used for meta-scripting should be an anti-pattern. I'm not actually claiming what we should be doing, but what could be achieved if it is led in a proper direction. I actually proposed those 2 extra features for the spec (composable fields and composable directives) which, I believe, would do a great deal concerning this respect.
> we see the GET method to do more than 'getting' - sending emails no less!
You're right in this remark, but this is just a demo to make it easy to make my point (as I mention in the article, I'm just printing the content on screen, not actually sending the email). In real life, whenever there's a mutation (such as sending an email), then you'd need to execute it via `POST`.
But for that same example, just remove one line from that big query (`sendByEmail`) and everything else is idempotent. That's the value of this method.
- 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"}}`