Absolutely agree GraphQL is the transport layer between so many different other technologies.
It’s used in a number of different stacks. Mostly because it’s an efficiency optimization over what came before it in REST. In fact, I’d go out on a limb that of all the different frameworks and technologies out now, the ones that are performance optimizations are the ones that are going to last.
It's a pretty solid limb, though. The web that was there when REST and who-knows what else came about is a very different web than we have now. Tech has gotten very big since then, and a lot of attention has moved to bandwidth and perf - if for no other reason than to trim the fat to make room for bigger tech :)
GQL trims the fat. Graph Databases do. Rust and Golang do on the CPU/RAM side. These have futures.
Our users are on 3g. Our servers are cloud. We're paying real money for networked resources these days.
Ha, I almost said trunk ;) Completely agree though. I’m currently on a project that using a JSON response hit the max response size limit regularly (this was a while ago). We have to transport a lot of data in a live environment, so we ended up dropping the JSON aspect and went to a direct binary connection from the client to a Graph database. I suspect we could have survived with a GraphQL implementation. “trimming the fat” is a great way to put it. And it’s one of my passions on every project I work on. “Can this be smaller/tighter/faster?”
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.