3 ms·
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
by larve 4y ago
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/ 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.