search

petertenhoor / headless-wp-graphql-poc

Proof of concept for headless WordPress using the wp-graphql plugin, Apollo and Next.js.
7 stars 1 forks source link

Interesting results! A couple of questions #1

Open binaryfire opened 4 years ago

binaryfire commented 4 years ago

Hey Peter,

Very interesting results, thanks for sharing. I've been trying to decide between WPGraphQL and REST for a new project. So you'd suggest custom REST endpoints would be faster?

I was under the impression WPGraphQL didn't load plugins / themes and that was one of the reasons it was faster than the REST API. However from what you're saying, it seems that isn't true and the only difference is the ability to be more specific with queries?

Also, what are your thoughts on this? https://wordpress.org/plugins/wp-rest-cache/ From what I can tell, it object caches REST endpoints which means they could take advantage of Redis?

Cheers :)

petertenhoor commented 4 years ago

Hi there,

As far as I am aware the WordPress core, plugin code and theme code will always be loaded as soon as wp-config.php or wp-load.php is required in your project.

The only way to fetch WordPress data without loading all of the unneeded code is connecting directly to the WordPress database from an external API / script using MySQL queries. I would not recommend this approach!

That's why I decided to use the REST API and accept the fact that (unless you use some static site framework like Gatsby) a caching middleware between WordPress and the front-end application is required to build a fast headless WordPress website.

Meanwhile I have three headless WordPress websites running in production. All of them were built using (custom endpoints within) the WordPress REST API. My front-end application requests data from a custom express server middlware which fetches the data from WordPress and caches responses in a static file (or Redis) cache which WordPress can flush. Using this tactic, it does not really matter if the data source is slow in the first request since both API requests and SSR request will be cached after that and the front-end will be fast.

This is one of the headless WordPress websites I've built using the REST API and Next.js with a custom express caching proxy: https://ribsdelivery.nl/

I have tested the REST API cache plugins, but in the end it is still PHP which has to load all WordPress code, check if the requested data is cached and if so, fetch it and serve it. This takes at least a few 100 milliseconds which is expensive for your front-end performance. A caching layer on nginx / server level like Varnish should work though!

I am not sure if WPGraphQL became faster since my proof of concept, so it might be worth giving it a new shot. I know there's a lot of good developers working on it on a daily base! You should check out their slack channel if you have any more questions: https://wpgql-slack.herokuapp.com/

Good luck on your Headless WordPress project, and please let me know if you have any more questions or findings!

binaryfire commented 4 years ago

@petertenhoor Thanks, this is very helpful! At the moment (unless there's a fairly straightforward out-of-the-box middleware solution I can use?) I think I'll avoid middleware. I'm just starting with headless WP so I want to keep complexity down for now :)

Until then, do you know of an easy way to caching WPGraphQL? I've searched but haven't found any resources or guides on this. For example it would be great if I can implement something like that REST API cache plugin for WPGraphQL. That way I can leverage Redis.

Using nginx's FastCGI cache for REST endpoints also sounds like a cool and pretty straightforward idea! Are there any plugins I could use as a starting point to create my own nginx API cache plugin? Something which has invalidation functions already built in.