7 ms·

Show HN: New GraphQL API for WordPress

65 points by leoloso 4y ago

bastawhiz 4y ago
This is cool, but I'm curious to know what took 16k commits. The projects that I've been on with more then ten thousand commits had many dozens or hundreds of folks working full time. And to crank that out in 1.5 years! That's 22 commits per day, every day. That's a fairly meaty engineering org's cadence. Is there some complexity that needed to be overcome that the post doesn't get into?
- hansonkd 4y ago
  A lot of one word typo fixes, commits to fix one blank line, and automated package rewrites. Each release is about 3-4 commits of the same thing (bumping versions, etc) with 1-4 releases a day. So to fix a one word typo ends up being about 3 separate commits.
  - leoloso 4y ago
    check my response above
- rmccue 4y ago
  For comparison, the WordPress REST API was about 4k commits over ~4 years or so (prior to us merging it into WordPress itself): https://github.com/WP-API/WP-API https://github.com/WP-API/WP-API (That said, commit count is a pretty useless metric.)
- leoloso 4y ago
  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?).
cinntaile 4y ago
Why is the years of development or the number of commits relevant? It feels like there is an unstated incentive at play here? Are you trying to get hired?
- xnx 4y ago
  I think it's an attempt to convey the level of effort involved? Seems like an even worse measure than lines of code.
  - contravariant 4y ago
    It's the kind of metric I'd use if I wanted to convey how much time was wasted on something.
- deleted 4y ago
  [deleted]
- leoloso 4y ago
  > 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.
tofuahdude 4y ago
[flagged]
- plebian 4y ago
  Why be like this
- dang 4y ago
  Please don't break the rules like this. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/showhn.html https://news.ycombinator.com/showhn.html
Kwpolska 4y ago
What real-life use-cases do you envison for a GraphQL API for WordPress? What does it solve that the existing REST APIs cannot? Why would you make a GraphQL API out of a CMS for (primarily, out of the box) blogs?
- dimmke 4y ago
  WordPress serves as kind of an ad hoc CMS for many different kinds of backends. Because it’s easy to extend and a lot of people are familiar with it. When I worked at the CDC, the entire backend of cdc.gov was a heavily HEAVILY customized version of WordPress that did static publishing. I’d guess it’s still that way. It’s why WooCommerce was so popular. Role your own eCommerce. GraphQL is good because using WP headless is popular these days.
  - coding123 4y ago
    Using WP headed is a good way to become a 0-day.
- tylermenezes 4y ago
  GraphQL supports schema stitching, so you can have one API endpoint request lots of different information from different services, and combine information seamlessly server-side. (e.g. Wordpress author -> user service -> posts on a different service) Here's how we're using Wordpress and other GraphQL services at a smallish nonprofit: https://blog.codeday.org/how-graphql-helps-us-showcase-codedays-impact https://blog.codeday.org/how-graphql-helps-us-showcase-coded... That page is powered by Wordpress over GraphQL, and you can try it yourself at https://graph.codeday.org/ https://graph.codeday.org/ (here's a sample query - query { blog { posts { nodes { title author { discordInformation { username discriminator }}}}}})
  - weird-eye-issue 4y ago
    I think you missed a }
- waffl 4y ago
sakopov 4y ago
What's the purpose of throwing GraphQL in front of a single API? I always thought of it as an API Gateway of sorts which fits better in a microservice type architecture and aggregates requests across multiple microservices. At least that's how I have seen it used. What is the need for GraphQL in the WordPress scenario?
- jayd16 4y ago
  Presumably its still useful as a standard mechanism for response field selection and preventing n+1 queries when trying to join data across multiple types of entities.
- leoloso 4y ago
  Check my response above to Kwpolska
dwwoelfel 4y 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 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.
- leoloso 4y 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/ 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"}}`
camsjams 4y ago
How does this compare to WPGraphQL https://www.wpgraphql.com https://www.wpgraphql.com that's been around for quite some time (https://github.com/wp-graphql/wp-graphql https://github.com/wp-graphql/wp-graphql) Did you find shortcomings with that plugin?
- leoloso 4y ago
  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/ 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.
KodyBerns99 4y ago
I did use wpgraphql with worddpress but it is also good to see something new popping up. I will give it shot in my future projects.

65 points by leoloso 4y ago

This is cool, but I'm curious to know what took 16k commits. The projects that I've been on with more then ten thousand commits had many dozens or hundreds of folks working full time. And to crank that out in 1.5 years! That's 22 commits per day, every day. That's a fairly meaty engineering org's cadence. Is there some complexity that needed to be overcome that the post doesn't get into?

hansonkd 4y ago
A lot of one word typo fixes, commits to fix one blank line, and automated package rewrites. Each release is about 3-4 commits of the same thing (bumping versions, etc) with 1-4 releases a day. So to fix a one word typo ends up being about 3 separate commits.
- leoloso 4y ago
  check my response above
rmccue 4y ago
For comparison, the WordPress REST API was about 4k commits over ~4 years or so (prior to us merging it into WordPress itself): https://github.com/WP-API/WP-API https://github.com/WP-API/WP-API (That said, commit count is a pretty useless metric.)
leoloso 4y ago
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?).

cinntaile 4y ago

Why is the years of development or the number of commits relevant? It feels like there is an unstated incentive at play here? Are you trying to get hired?

xnx 4y ago
I think it's an attempt to convey the level of effort involved? Seems like an even worse measure than lines of code.
- contravariant 4y ago
  It's the kind of metric I'd use if I wanted to convey how much time was wasted on something.
deleted 4y ago
[deleted]
leoloso 4y ago
> 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.

tofuahdude 4y ago

[flagged]

plebian 4y ago
Why be like this
dang 4y ago
Please don't break the rules like this. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/showhn.html https://news.ycombinator.com/showhn.html

Kwpolska 4y ago

What real-life use-cases do you envison for a GraphQL API for WordPress? What does it solve that the existing REST APIs cannot? Why would you make a GraphQL API out of a CMS for (primarily, out of the box) blogs?

dimmke 4y ago
WordPress serves as kind of an ad hoc CMS for many different kinds of backends. Because it’s easy to extend and a lot of people are familiar with it. When I worked at the CDC, the entire backend of cdc.gov was a heavily HEAVILY customized version of WordPress that did static publishing. I’d guess it’s still that way. It’s why WooCommerce was so popular. Role your own eCommerce. GraphQL is good because using WP headless is popular these days.
- coding123 4y ago
  Using WP headed is a good way to become a 0-day.
tylermenezes 4y ago
GraphQL supports schema stitching, so you can have one API endpoint request lots of different information from different services, and combine information seamlessly server-side. (e.g. Wordpress author -> user service -> posts on a different service) Here's how we're using Wordpress and other GraphQL services at a smallish nonprofit: https://blog.codeday.org/how-graphql-helps-us-showcase-codedays-impact https://blog.codeday.org/how-graphql-helps-us-showcase-coded... That page is powered by Wordpress over GraphQL, and you can try it yourself at https://graph.codeday.org/ https://graph.codeday.org/ (here's a sample query - query { blog { posts { nodes { title author { discordInformation { username discriminator }}}}}})
- weird-eye-issue 4y ago
  I think you missed a }
waffl 4y ago

sakopov 4y ago

What's the purpose of throwing GraphQL in front of a single API? I always thought of it as an API Gateway of sorts which fits better in a microservice type architecture and aggregates requests across multiple microservices. At least that's how I have seen it used. What is the need for GraphQL in the WordPress scenario?

jayd16 4y ago
Presumably its still useful as a standard mechanism for response field selection and preventing n+1 queries when trying to join data across multiple types of entities.
leoloso 4y ago
Check my response above to Kwpolska

dwwoelfel 4y 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 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.

leoloso 4y 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/ 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"}}`

camsjams 4y ago

How does this compare to WPGraphQL https://www.wpgraphql.com https://www.wpgraphql.com that's been around for quite some time (https://github.com/wp-graphql/wp-graphql https://github.com/wp-graphql/wp-graphql) Did you find shortcomings with that plugin?

leoloso 4y ago
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/ 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.

KodyBerns99 4y ago

I did use wpgraphql with worddpress but it is also good to see something new popping up. I will give it shot in my future projects.