[blakehaswell]

> From a purist perspective, this has a "cancerous" feel (as opposed to being "encapsulated")

I have the same feeling about much of the React ecosystem (edit: though I'd say "tightly coupled" rather than "cancerous"). The other day some folks were discussing the idea of building a new UI backed by a new GraphQL schema. We started talking about the possibility of delivering the UI independently of the GraphQL schema by using an existing REST API, and the idea was shot down as the GraphQL client we're using on the frontend is highly coupled to the UI components. Changing the data source later would have been a highly intrusive change.

I totally understand the benefits that a GraphQL client provides, but it feels like a serious architectural smell that changing the data layer is such a wide-ranging change in a web app. Wrapping a data-source in an API and being able to change the implementation without the rest of the application being impacted is really compelling, and I'm not convinced it's something worth trading-off.

[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.

[throwanem]

I agree that that tight coupling is a smell, but it's also not required; the Apollo (GraphQL) tooling offers it and some of the documentation encourages it for new users, but not using it is a first-class option too. That's the paradigm around which (for example) the entire application for which I recently co-led development is built. We didn't have any trouble using it, and while replacing GQL with REST would still be a heavy lift just due to the fact that it's a highly data-driven application for which we also maintain our own backend, we wouldn't need to touch the UI to make that change.

I don't love that the docs tend somewhat to encourage the API option with tighter coupling between UI and data, and the Apollo documentation is in general pretty lightweight by my standards. To criticize on that basis is fair. But it isn't anything like forced, and to write off GraphQL or React as "cancerous" on account of someone having made a less than optimal decision in how to use them seems premature.

[blakehaswell]

> to write off GraphQL or React as "cancerous" on account of someone having made a less than optimal decision in how to use them seems premature.

Apologies, cancerous isn't how I'd describe it, but the sentiment of the quote did resonate. "Tightly coupled" is more representative of my concern.

Thanks for the counter-example!