> 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?
All sarcasm aside, having composable components server-side is only a good thing. I welcome it.
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.
Maybe it does those well, maybe not, but if you expect it do anything else, you'll certainly be disappointed.
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.
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.
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.