The current REST API is currently bloated with so much information one seldom needs when using the software as a headless CMS and could be improved in speed relatively. I suggest running with GraphQL.
This would improve speed of API, All developer to query only information needed.
This could be a start. GitHub - wp-graphql/wp-graphql: 🚀 GraphQL API for WordPress
Read-only archive : Issues · ClassicPress/ClassicPress · GitHub
Author : Laurence Bahiirwa
Vote count : 9
Status : open
Tags :
request-modify-feature
difficulty-hard
Comments
There are already a few requests about the REST API; hopefully it’ll be moved to a core plugin. At that point there’s no bloat - install WP-GraphQL or activate the REST plugin, whatever suits your purpose.
Generally I’m against adding things to core unless it’s going to enhance things for everyone - in exactly the sense that Gutenberg doesn’t.
~ posted by invisnet
There are 2 main pieces to the WP REST API. The infrastructure used to create endpoints shipped in WordPress 4.4, almost 3 years ago. The basic content endpoints for posts, comments, terms, and users (and meta and settings) shipped in WordPress 4.7, almost 2 years ago.
Removing either of these pieces or moving them to a plugin would break many major plugins and a huge amount of active sites. It would be interesting to try to estimate how many, but I can tell you it’s going to be a huge number.
Implementing a GraphQL API is an interesting idea, but due to existing usage, you can’t really “upgrade” an API. Once it’s released, it’s out there, as a contract that its users expect to be supported for a long time.
I think a GraphQL API should be implemented based on the existing REST controller code, to greatly reduce the amount of custom logic needed. I haven’t seen a plugin yet that takes this approach, but if we look at this feature request as “add a GraphQL API”, a plugin is a great starting point for making this work.
I want to state the huge amount of effort and time that would be involved in this project, mostly around testing and polishing. It took a consistent team of ~5 people around 4 years to develop the REST API, because core WordPress functionality doesn’t fit easily into an API-like structure. And, on top of that, GraphQL is a good bit more complicated, both to implement/test and to understand.
Finally, responding to Tim’s specific questions above:
Here is some info for write operations (“mutations”) using GraphQL: https://graphql.org/learn/queries/#mutations
Not really a big problem, IMO, and also the _fields
parameter pretty much solves this.
The basic idea of GraphQL is that you specify exactly the information you need - and the structure you need it in - with the API call. This could include data from multiple built-in endpoints, in any format you want, and it is presumably less work than writing an entire custom endpoint.
Complex applications often need to perform many REST requests in a sequence, and these would be optimized and combined into fewer GraphQL requests, which could change pretty drastically depending on the state of the application. There are libraries to help with query-building etc, but I’ve yet to see this working (or failing) in the real world, and we should look for some examples.
This would depend on the API implementation. Disabling plugin loading during REST requests sounds like a separate feature request to me
~ posted by James Nylen
I like the idea of having GraphQL in core but I don’t think it’s possible to replace the existing REST api with GraphQL since many sites are using it and it has been around for a couple of years.
GitHub - wp-graphql/wp-graphql: 🚀 GraphQL API for WordPress is a great start of be able to use GraphQL with WordPress and it’s gives a good idea of how much work it is to bring GraphQL into WordPress.
Think it would be possible to offer both solutions (instead of upgrading) where GraphQL use the REST API logic.
~ posted by Fredrik Forsmo
REST APIs and GraphQL APIs are useful for different use-cases; one should not be traded for the other.
For those who are not familiar with the reasons why, this guy does an OUTSTANDING job explaining why:
REST vs. GraphQL: A Critical Review
~ posted by Mike Schinkel
I think calling it upgrade was misguided and misleading. I can not change the title unfortunately however modern apps are pushing for GraphQL in the stead of the REST API and using ClassicPress as a CMS/backend with tools like JS on the frontend. Is there a way to reconsider this. Or take on the plugin on GitHub - wp-graphql/wp-graphql: 🚀 GraphQL API for WordPress
~ posted by Laurence Bahiirwa
Updated.
~ posted by James Nylen
I’d like to throw my 2 cents in here. I’d LOVE to see a community driven effort to adapt GQL into WP. However, I fully and strongly advocate against WP-graphql being that integration.
Unfortunately I think this project is essentially unsalvageable, it’s insecure, buggy, and not very well-designed.
It’d be great to see a project like this started from scratch, developed by a solid team of people who truly understand WP’s core, GQL and can implement it in a way that’s solid, safe and adheres strictly to WP’s conventions.
~ posted by J
I’ve been reading about GraphQL, and this page Graphiti is pretty compelling to me as to why it’s not a good way to do an API. This implementation is in Ruby on Rails, and is completely standalone, but the main point is that REST done right can be more like a mixture of the current REST and some QL.
GraphQL should remain as a plugin, not in core.
~ posted by Joy Reynolds
I vote to close this petition as: Plugin Territory.
1 Like
viktor
April 8, 2022, 2:51pm
5
I agree, this is definitely for a plugin to do.
2 Likes
viktor
Closed
April 11, 2022, 12:00pm
6
This topic was automatically closed after 2 days. New replies are no longer allowed.