One of the main uses in PHP/Laravel (probably borrowed from Ruby on Rails) is caching views for Russian doll caching and caching SQL query results: https://lar

One of the main uses in PHP/Laravel (probably borrowed from Ruby on Rails) is caching views for Russian doll caching and caching SQL query results: https://laracasts.com/series/russian-doll-caching-in-laravel https://laracasts.com/series/russian-doll-caching-in-laravel (subscription only) Unfortunately, it looks like they retired their database caching lesson, which was a mistake on their part since it was so good: https://laracasts.com/discuss/channels/laravel/cache-tutorials https://laracasts.com/discuss/channels/laravel/cache-tutoria... (links to defunct https://laracasts.com/lessons/caching-essentials https://laracasts.com/lessons/caching-essentials) Laracasts are the best tutorials I've ever seen, regardless of language, outside of how php.net/<keyword> search and commenting was structured 20 years ago. They would be the best if they got outside funding to provide all lessons for free. Anyway, one HTTP request can easily generate 100+ SQL queries under an ORM. Which sounds bad, but is trivially fixable globally without side effects via global "select" query listeners and memoization. I've applied it and seen 7 second responses drop to 100 ms or less simply by associating query strings and responses with Redis via the Cache::remember() function. I also feel that there's a deeper problem in how web development began as hacking but devolved into application-heavy bike shedding. We have a generation of programmers taught to apply decorators by hand repeatedly, rather than take an aspect-oriented (glorified monkey patching) approach that fixes recurring problems at the framework or language level. I feel that this is mainly due to the loss of macros without runtimes providing alternative ways of overriding methods or even doing basic reflection. So code today often isn't future-proof (requires indefinite custodianship of conventions) and has side-effect-inducing or conceptually-incorrect changes made in the name of secondary concerns like performance. The antidote to this is to never save state in classes, but instead pipe data through side-effect-free class methods, then profile the code and apply momoization to the 20-% of methods that cost 80+% of execution time. Also microservices are definitely NOT the way to go for rapid application development or determinism. Or I should say, it's unwise to adopt microservices until there are industry-standard approaches for reverting back to monoliths.