[ctidd]

As a counterexample to consider, I would suggest that a client-side web app is coupled to any remote data source intrinsically by a latency-sensitive connection over the network. As soon as you have enough data, you need to defer portions of it and load them on demand based on user interactions. So now the ways in which data was or wasn't factored in a way that mirrors the app impacts it.

Now, there are tradeoffs we can make to deliver an end state to a user: we can normalize and incrementally hydrate the data shown in the client and increase visible jank in the process, or we can realign the app's experience and/or data source around each other.

Decoupling UI components from business components is of course valuable, but that's different from taking that a step further and decoupling business components from the data source. The latter is a significantly more challenging proposition.

Also, there's some fuzziness here in what we mean by decouple. REST vs SOAP vs GraphQL as transfer layers can be abstracted away as implementation details, but I'd place a higher emphasis on the shape of the data and how it has to be traversed in the client. If you have a paginated list, for example, and you only want to load it once, but you need to display both a summary and load it incrementally, things can get complicated as more functionality is built out from that starting point, regardless of transfer layer.

[lhorie]

As a counter-counter-argument, one could argue that there's coupling to the database and one might as well then write db queries from their single file components. One stack (meteor) took that idea of trading loose coupling for productivity to the extreme but then suddenly found itself in an awkward position when react and npm exploded in popularity (and Mongodb lost mindshare).

Surely something else will eventually displace react and/or graphql, just as previous stacks and paradigms have been overshadowed. But then we go back to my original assertion: refactoring away from the legacy of the tools we no longer like is decidedly going to be more complex if we chose to sacrifice loose coupling in favor of something else (performance, initial dev speed, what have you)

Case in point, esbuild looks like a very promising replacement for some web plumbing. But if there needs to be extra collaboration to support this there, other stacks can take the opportunity to dash ahead (e.g. vite) while the react team is busy collab'ing with all these compiler projects.

[tomnipotent]

> but I'd place a higher emphasis on the shape of the data and how it has to be traversed in the client

There is something incredibly satisfying in rendering an entire UI experience from a single GraphQL payload, without having to build intermediary data structures to stitch it all together from multiple endpoints.