Caching the API for improved performance?

[seb86]

In version 2.1.2 of CoCart I prevented the "WP REST API Cache" plugin from caching any route requested via CoCart.

A lot has changed since that release and I am now looking at improving performance now that the products API is part of the core.

I have only had a few requests on this so it hasn't been a high priority but it's also a double edge sword.

If caching was enabled, at what point does the API request get updated? How long is it cached for? How is it cached?

While it's not something I want to completly say no too, it is something that needs to be discussed.

Obviously having a decent web host is the best option if your using a REST API to make requests and shouldn't be any higher than 600ms for a decent shared host.

But the size and time of each requests vary especially when it comes to the customers shopping cart so when I hear that a request took over a 1000ms it looks bad on my end even though it's not my fault. Just the way it is.

But I don't want it to be so I would like to hear your thoughts and any ideas you can come up with to improving the performance.

In CoCart v3.1 I have already made it possible to reduce the request of the cart by only returning the fields you need but I want to take it further.

[boutzamat]

I tried improving the API performance too, as +1s was just too long for 39 products. During this, i tried editing the plugin directly and remove nearly all the fields except from the ID's, just to see how much i could improve it theoretically. Unfortunately, even with no fields the response time was still 0.5s which is still too much for 39 products. This has nothing to do with your plugin but WP/WC's database design i believe.

I don't believe the API should be running without a cache at it could really hit the user experience. These tests was on a local server, with only me testing. Imagine how busy the server in production would become, when more customers are using it.

The only thing that i can think of that would invalidate a cached dataset, is if the stock changes or if a product is created, edited or deleted, in which case i think the cache should be regenerated.

Currently, i am using WP REST API CACHE (manually registered the routes as they are disabled by CoCart). It really improved the performance. Went from +1s to 20-30ms.

However, i'm not a fan of their API for the following reasons.

1. To identify the cache you want to flush, you need to md5 hash the URL (/wp-json/cocart/v2/products) as that is the ID of the cache. The only problem is that when i hash it, it's not the same. Tried both with and without the trailing slash "/" but the hash still doesn't match.
   

2. There's no cache regeneration option. You can only flush it and wait for the next cron job to regenerate the cache.
   This wastes alot of unnecessary resources (unecessary cron jobs if nothing has changed), and will most likely also mean that a visitor might encounter an un-cached response and wait for many seconds for it to be generated.

I am therefore currently looking into generating cache as a file, as it is even faster than WP REST API Cache, since it fetches the cache from a database. Went from 20/30ms to 10ms when using a cache file.

This is the code i wrote to clear the WP REST API Cache when:
Product is saved or updated, or if the stock quantity is changed. It works with Ajax too, so it also runs if a variation is updated without the parent product is saved. I have still not implemented it on delete. Sadly WooCommerce has soooo many different hooks and i need to figure them all out. Besides, this code isn't working because of the MD5 issue i described above, but the hooks are running when expected. If anyone want to use it, they are free to try and make it work with the WP REST API Cache plugin if they want. I will personally modify it to create a static minimized JSON file on the server for my usecase.

function vuecommerce_rest_api_cache_clear()
{
	// Create a md5 hash of the CoCart products endpoint
	$hash = md5('/wp-json/cocart/v2/products');

	// Request a cache delete based on the md5 hash
	\WP_Rest_Cache_Plugin\Includes\Caching\Caching::get_instance()->delete_cache($hash);
}
add_action('woocommerce_product_before_set_stock', 'vuecommerce_rest_api_cache_clear');
add_action('woocommerce_variation_before_set_stock', 'vuecommerce_rest_api_cache_clear');
add_action('save_post_product', 'vuecommerce_rest_api_cache_clear');
add_action('woocommerce_ajax_save_product_variations', 'vuecommerce_rest_api_cache_clear');

[seb86]

Maybe a better REST API cache system is needed. One that is suited for CoCart and WooCommerce.

[boutzamat]

The goal would be to create a new cache imediately when some specific events happens. Even better, if possible, only then.
This will make sure the data is never outdated, nor is it regenerated for no reason. By default i think the above hooks makes sense, but with the possibility to change and add more hooks.

I actually think WP REST API Cache is suitable for how most people are planning to use CoCart. If we can find a way to regenerate the cache manually instead of waiting for the cron job to run. Ofcourse we'd need to be able to exclude some endpoint as well such as the cart.

I'm going to look into the md5 thing tomorrow again and see if i can make the cache flush feature work for now.
I'll also look deeper into the code and see if i can find a way to regenerate the cache on demand. If that succeeds, i think this would be a great choice for caching in most cases.

My use case is a bit different. I fetch all products once (asynchronously), and then use the data to create the app as it contains everything i need for the store (checkout is handled the classic way).
This means that in my case, WP REST API Cache isn't the best choice, but generating my own cache-file would be, as the response time is even faster that way. I also remove redundant information such as the site URL from the cached file to keep it as small as possible. I wouldn't recommend anyone doing it that way unless they're building the same way i am. But if anyone wanna know more, they are welcome to ask into this :D

[seb86]

So last week I experimented on building my own cache for the REST API that saves the response as a JSON file with the request hashed by MD5 and loads that JSON file if one exists. Only GET requests of course. No database, no transients required.

There are plenty of filters for developers to change things how they wish from the headers, length of the cache and which API's to cache.

I also make sure what API's to ignore should they cause issues like WC Report API does.

At the moment it's just a prototype but I will have CORS built in and support for WooCommerce out of the box including the ability to clear the cache when products are updated.

I've only tested locally but I'm sure once I have more time to work on it, it should be the fastest and supported REST API cache out there.

[seb86]

P.S. What I found interesting is if the JSON file is manipulated in any way. The cache file is ignored and it get's a fresh response.