Caching support?

[joshuaiz]

Not really a pressing issue but a question: has anyone gotten BRE working with either WP Rest Cache or Rest API Cache?

After trying both of those out, they do not seem to like the menu endpoint from BRE at all, so much so that I have had to disable them.

I have some front end javascript caching working with Local/Session Storage in a headless WP app but some server-side caching that works with BRE for specific endpoints would be great to help with initial page loads.

[erwstout]

There is no native support for caching built in... It depends on your opinion but generally you wouldn't want to cache API data since you'd want the latest data incoming and could frustrate clients (I made a post but it doesn't show up, what gives?!). I understand why you'd want to for performance but having the smallest response possible, which we try to do, should keep your site performant.

On Sat, Aug 18, 2018, 10:56 PM Joshua Michaels notifications@github.com wrote:

Not really a pressing issue but a question: has anyone gotten BRE working with either WP Rest Cache https://github.com/airesvsg/wp-rest-api-cache or Rest API Cache https://wordpress.org/plugins/rest-api-cache/?

After trying both of those out, they do not seem to like the menu endpoint from BRE at all, so much so that I have had to disable them.

I have some front end javascript caching working with Local/Session Storage in a headless WP app but some server-side caching that works with BRE for specific endpoints would be great to help with initial page loads.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/factor1/better-rest-endpoints/issues/23, or mute the thread https://github.com/notifications/unsubscribe-auth/AJASef9v4cFUFG3iXRFRkVuLIgk-hm64ks5uSP4dgaJpZM4WC14W .

[joshuaiz]

Thanks @erwstout - that is the correct strategy for sure. However even just trying those plugins they did not like the BRE endpoints.

Looking forward to when BRE has full WooCommerce support, in my case product posts won't change very often so it would be good to cache the requests.

As a workaround, I've come up with a solution that writes the endpoint response to a json file which is then uploaded and served from Amazon s3 which is much faster than an actual REST API call. It also updates the json file whenever a post is saved/updated. That seems to be working really well.

In any event, there would definitely be situations where caching would be useful: menus and pages are two, especially if they aren't changing much. For a front end app, does it really make sense to make a call to grab the nav menu each time your component is loaded?

[erwstout]

I agree with you that it should at least not cause the WP install to fall over and that caching menus would be a good call as well.

Do you have any error logs or anything that you could provide so I could look into this more? Thanks!

[joshuaiz]

Thanks @erwstout.

I just re-activated WP REST API Cache and it bugs out on my menu endpoint:

https://example.com/wp-json/better-rest-endpoints/v1/menus/main-menu/

Using axios for my API fetching nothing is console.logged as an error message but the menu doesn't load at all. When I console.log the menu response with WP REST API Cache activated, all that is returned is an x-debug message but split out into a 6535 character array (with all of the x-debug inline styles and html). That makes it super hard to debug. I haven't even located the actual error yet.

Mind you this is a headless WP app in React so no php on the client end.

What's strange is there is no error(s) at all if I visit the actual WordPress site.

Here's a screenshot of the response (partial):

Without the WP REST API Cache plugin activated, everything works as normal.

To my above solution to write the endpoint to a JSON file and then upload it to S3, I've made it into a plugin: https://github.com/joshuaiz/wc-rest-json-s3.

It's set up out-of-the-box for grabbing WooCommerce products as they were taking the longest to load but this could be configured for any endpoint. While not caching per se, when used with local/session Storage and Amazon S3, it's pretty darn fast and definitely faster than a regular REST API call.

[erwstout]

Interesting. I'll have to try to replicate. I noticed in that screen shot that its spitting out an array of HTML which is interesting. Makes me almost wonder if something is returning a 404.

[joshuaiz]

Trying to read through the characters I did see x-debug in there so it is spitting out the error and x-debug formatting.