> Now what happens if you have a bunch of these components on a page? You get lots of uncoordinated data fetches. Each component is independent so it doesn’t know about the others so they can’t coordinate.
No. You write a data layer that deduplicates requests. And since you typically need state management for fetches for UX, why not roll it all up into a tidy hook?
https://tanstack.com/query/latest
I guess the lynchpin is under-engineering at the request layer "forcing" massive over-engineering at the routing layer.
-
By the way, your self-answered rhetoricals are really really off the reservation in terms of relevance so I'm not even going to go there other than pointing out that a bad analogy is worse than no analogy.
You're trying to explain request waterfalls. Just say request waterfall. Look up the term if you have to, it's rare that you need to invent a definition for a basic and common problem.
> You're trying to explain request waterfalls
So conceptually what's the difference between a request waterfall and an N+1 query issue?
So practically what's the benefit of mentioning "Query planners inside a database" instead of request waterfall?
To say, by analogy, that coordinated data fetches are hard and we’ve been working on it for a long time in different contexts.
Analogies help me understand stuff and borrow lessons others have learned.