> In many cases it is much better to send requests more frequently, similarly to how a server side rendered website would behave. Instead of fetching 10,000 products, just fetch a page of products. Much faster. Have endpoints for filters and searches, also paginated. This can be fast if you do it right. Since you're only sending minimal amounts of data everything is fast.

This is actually a great example of what I mentioned elsewhere about how people seem to have forgotten how to make a SPA responsive. These are both simpler implementations, but not really the best choice for user interaction. A better solution is to take the paginated version and pre-cache what the user might do next: When the results are loaded, return page 1 and 2, display page 1, and cache page 2 so it can be displayed immediately if clicked on. If they do, display it immediately and silently request and cache page 3 in the background, etc etc. This keeps the SPA responsive with few to no loading spinners if they take the happy path, and because it's happening in the background you can automatically do retries for a flaky connection without bothering the user.

This was how gmail and google maps blew peoples' minds when they were first released, by moving data to the frontend and pushing requests to the server into the background, the user could keep working without interruption while updates happened the background without interrupting their flow.

Yeah you can do that, but it's not necessary. You'll have to figure out a clever way to first wait for the data the user actually needs on the first load, then silently cache the other stuff in the background. Then you'll have the best of both worlds, but it complicates the application. It might make sense for Gmail and google maps, but there are a lot of web apps for which it does not make sense to put the work into this.