[ddaalluu2]

Their solution is graphql, but I believe that the backend should have data for each component ready.

Example social network.

  /api/pagedata/FrontPage

returns a big ass query result, all posts with comments, comment count and reactions, all the data you would ever want in your front page.

  /api/pagedata/UserProfilePage

returns all the relevant data regarding the user's profile page.

Yes, if you change or extend a certain page, you will have to change the backend query. If you have 2 different teams for frontend and backend that's not straightforward, so there should be something where the frontend team writes the detailed expected json response and the backend team transforms that into queries. Or, let's be real, the queries get generated. One could even imagine a middleware that translates expected json to graphql queries.

Why not directly graphql? Because it's a major pain in the ass, because of relay. Graphql is Facebook. And instead of having the simple structure you can easily query, they added this stupid node relay structure which makes everything overly complicated.

I could imagine a Go backend or Rust where you have a comment with the expected JSON, and you type go generate and boom generated queries with search and pagination.

[SebastianKra]

I don't know who decided it was right to flag you into oblivion, but GraphQL is unrelated to this.

You don't always have full control over the backend. You may depend on another team, or maybe even access a public API. React was (and still is) good at that, but with suspense, it's as if they forgot that a Web-App may want to do more than just "take stuff from server and show".