[nwienert]

We already had composable components server side with SSR, they just didn't query data inside the render loop. But that doesn't really gain much, if anything leads to slower overall performance as now instead of doing something like GraphQL and resolving your entire tree in a single optimized database call, you're probably waterfalling all over the place.

[hotnfresh]

GraphQL hype is (and always has been, really) out of control.

GraphQL doesn’t do a damn thing to help you optimize your database calls. It also doesn’t do a thing to help with security or preventing DOS-inducing queries, which is the first question anyone who’s been around this block before (exposing remote query interfaces) has about it.

Some big frameworks that happen to speak graphql will automagic that stuff for you in simple cases, but we don’t claim e.g. the capabilities of the Rails framework with rails-api et c. as capabilities of REST or SQL or whatever.

This stuff is really annoying because you get half-technical leadership (or non-technical) thinking graphql is magic and that it’s good for all kinds of things it’s not and that it’ll save lots of time that it won’t, between the hype and the name.

[paulddraper]

GraphQL is for (1) static typing (2) front-end developer productivity and (3) front-end latency.

Maybe it does those well, maybe not, but if you expect it do anything else, you'll certainly be disappointed.

[nwienert]

GraphQL out of the box doesn't make things optimized, but with any decent setup like Postgraphile, Hasura, or just DataLoader you do get highly optimized single-pass queries vs something like having many REST endpoints where the queries end up coming in piecemeal. I know this as I've been deep into these problems and it makes a huge difference in performance.

And the comparison is valid because these optimizations do happen and do make a difference, and are pretty easy to get if you just for example choose Hasura which is a very popular library (and there are many many others too). GraphQL makes this possible in the first place, whereas RSC and REST basically don't.

[DanielHB]

it does fix waterfall HTTP requests though in 99% of the cases it does not fix waterfall database queries (by itself) and often will hide it from the developer when it is happening

I am a big fan of GraphQL, but it is no magic bullet. One of the biggest pluses for me is that it replaces Swagger with something that is sane. People often complain about GraphQL requiring a lot of tooling and libs to get working, but if you make a REST api with Swagger support you either have to maintain a swagger spec manually or have just as much (and depending on the language, more flaky) tooling. I think the only framework/language that made swagger reasonable to use is C#.

Also technically GraphQL is inherently more powerful than REST apis, so you can (technically) make a non-connected GraphQL api that mimics how a REST api works (no going from one model to another without making a new query). Losing a lot (but not all) of the advantages of graphql but keeping all the advantages of REST. Nobody does this of course because it is reaaaaallly nice to have that extra power.

[gabereiser]

who's to argue that you didn't fetch your entire tree in an optimized way and passed that to your render loop as props? I think there's patterns for this. I'm not arguing that we haven't had the capability of composability with SSR, we definitely have. What I'm arguing is that merging the two worlds of front-end and back-end in a singular nomenclature (besides just typescript) is good for velocity. Or maybe I'm just inviting more pain as mixin's become traits and the waterfall of bugs comes our way.