[csbartus]

What happened to the very elegant GraphQL? Where the client _declares_ its data needs, and _that's all_, all the rest is taken care by the framework?

Compared to GraphQL, Server Components are a big step back: you have to do manually on the server what was given by default by GraphQL

[eadmund]

> the very elegant GraphQL

The GraphQL which ‘elegantly’ returns a 200 on errors? The GraphQL which ‘elegantly’ encodes idempotent reads as mutating POSTS? The GraphQL which ‘elegantly’ creates its own ad hoc JSON-but-not-JSON language?

The right approach, of course, is HTMX-style real REST (incidentally there needs to be a quick way to distinguish real REST from fake OpenAPI-style JSON-as-a-service). E.g., the article says: ‘your client should be able to request all data for a specific screen at once.’ Yes, of course: the way to request a page is to (wait for it, JavaScript kiddies): request a page.

The even better approach is to advance the state of the art beyond JavaScript, beyond HTML and beyond CSS. There is no good reason for these three to be completely separate syntaxes. Fortunately, there is already a good universal syntax for trees of data: S-expressions. The original article mentions SDUI as ‘essentially it’s just JSON endpoints that return UI trees’: in a sane web development model the UI trees would be S-expressions macro-expanded into SHTML.

[moi2388]

N+1, security, authorisation, performance, caching, schema stitching..

[hyuuu]

N+1 is a solved problem at the framework level If GraphQL actually affects your performance, congratulations, your application is EXTREMELY popular, more so than Facebook, and they use graphql. There are also persisted queries etc.

Not sure about caching, if anything, graphql offers a more granular level of caching so it can be reused even more?

The only issue I see with graphql is the tooling makes it much harder to get it started on a new project, but the recent projects such as gql.tada makes it much easier, though still could be easier.

[csbartus]

That's a backend issue I guess ...

[5Qn8mNbc2FNCiVV]

That's the thing, this brings the benefits of GraphQL without requiring GraphQL (+Relay). This was one of the main drivers of RSC (afaik).

Obviously if you have a GraphQL backend, you could care less and the only benefit you'd get is reducing bundle size f.e. for content heavy static pages. But you'll lose client-side caching, so you can't have your cake and eat it too.

Just a matter of trade-offs

[anentropic]

Couldn't you have both?

I assumed RSC was more concerned with which end did the rendering, and GraphQL with how to fetch just the right data in one request

[hyuuu]

I was just going to say, all of this has been solved with graphql, elegantly.