for sure. but it's not "hard" (of course abstraction is hard to learn and see, but not to implement, I hope you understand my meaning here. I apologize for the lack of clarity) to build something like (very rough sketch):

  function get_all_products() {
     return cached(function () { return Sql::Select(PRODUCT_TABLE); }, Cache::GetSessionCacheKey());
  }

  render_template(Page::GetTemplate(), 
     [ "products" => get_all_products(), 
       "user" => get_user_data()
     ]);

or as I did for https://goldeneaglecoin.com/ , I would internally route "HTTP" calls, so the javascript and PHP would look identical:

  /* 
   * @url: /products
   * @cache: session(1h)
   */
  function get_products() {
     return Sql::Select(PRODUCT_TABLE);
  } 

  render_template(HTTP::GET("/templates/products"), HTTP::GET("/products");

while the javascript looks like:

  GET("/products").then((products) => render_template("/templates/products", products))

The caching is declarative, and the code is "stateless." This is fast enough that caching the render is pretty much not necessary, despite running on a t2.medium, and easily sustains > 100 rps. In the happy path, it reads a single value in the object cache. Only an initial hit will cause a render (using a bytecode compiled optimized template), and only the first XHR will cause an actual lookup in the server side cache (if necessary) because the browser then does the rest.

I wrote this code 12 years ago, and porting to react doesn't require any change on the server side. We just put RTK-Query in front and let it do all the rest.