6 ms·
it's not an insult. yes. cache heavily. shitty php stacks serving trillions of dollars of ecommerce sales have managed to do it for a long time.
by calvinmorrison 18d ago
it's not an insult. yes. cache heavily. shitty php stacks serving trillions of dollars of ecommerce sales have managed to do it for a long time.
- zbentley 17d agoThose ecommerce stacks serve a large fixed number of pages. cgit does not. Imagine if WooCommerce had a route "/product/<sku1>/compare/<sku2>" which displayed an auto-generated comparison between any two product pages. Now imagine running a million-SKU WooCommerce site, where each product page was 100kb of text. Now imagine scrapers are permuting those URLs. How would you cache that? That's what cgit/kernel.org and many other Git forges are dealing with. These aren't static websites, even if the underlying Git repo is largely static; they're rendering arbitrary diffs and other generated-on-the-fly views into Git history. The ability to do that is a large part of the value of a Git UI.
- inigyou 17d agoCan you explain how a cache lets you avoid serving a request for the first time?