[TheGeminon]

> Instead of bouncing back and forth between the client and server, we do our database query as part of the initial request, sending the fully-populated UI straight to the user.

> But hm, how exactly would we do this?

Couldn't help but chuckle. What mysterious technology could allow us to send an entire fully-populated UI over the web?

[gabereiser]

“As if a million voices cried out in terror and were suddenly silenced” - The full circle. When they left us, they were but learners, now they have become masters. Realizing that this nirvana exists, that people have been doing it this way for ages. That a combination of interactivity with the offloading of compute and rendering is a good thing for their performance. That grey beards really do know a thing or two. /s

All sarcasm aside, having composable components server-side is only a good thing. I welcome it.

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

[benatkin]

> What mysterious technology could allow us to send an entire fully-populated UI over the web?

WebAssembly? Just kidding. But I think a lot don't realize that you could. It's pretty well supported now and a small WebAssembly library can fit in about the same size as a full page photo.

[gabereiser]

Vugu?

[paulddraper]

The Star-Bellied Sneetches