[megadal]

GraphQL literally is a "federation gateway point."

It's literally meant to be a gateway to a bunch of different external systems working in federation.

It's the exact same scope if you used a RESTful graph based data access API that connected to external systems..

Outside all the GraphQL jargon and gobbledygook you'll see that GraphQL is not some groundbreaking, unique or foundational product... The concept of generating graph based data access APIs from schemas is probably older than the concept of phones that can send emails. The only "innovation" is the "query language"...

> That doesn't matter at all.

I honestly don't know why I'm taking this seriously. Yes, it matters, your entire point was a comparison.. that your comparison is foundationally invalid matters when assessing the validity of your entire argument..

[throwaway3306a]

The whole point of my comment is that with REST you don't have any guarantees about the API and thus it's a much harder target to support. You're limiting it to json:api which is nice but I have never even seen a company use that. What happens in reality is that I get 20 apis from 20 teams, each of them completely different principle - and am supposed to build an universal auth layer for that. That's much more painful than in the companies that decided to go for GraphQL only.

[megadal]

> The whole point of my comment is that with REST

Hence your comparison is invalid

> you don't have any guarantees about the API and thus it's a much harder target to support.

You won't find a developer worth hiring who thinks OpenAPIs are more difficult to work with than GraphQL.

Every REST API can be an OpenAPI

Practically every popular general purpose language has an OpenAPI client gen implementation.

And supporting a GraphQL API is not easier than supporting a REST API. All I have to do for my stopwatch API is handle one route.

> You're limiting it to json:api which is nice

Certain constraints do come with valid comparisons, comparing like things is a requirement of a valid pros/cons comparison, not a niceity.

It makes no sense to explain the pros of using one thing over an other when no one is thinking about using one thing as a replacement for another.

It's like talking about the pros/cons of using your proprietary web based chat platform vs. using UDP. Not using UDP for the chat or anything. Just comparing the chat with UDP itself, the whole protocol. No one considering your chat is going to step back and go "wait why am I using a web chat when I can just use UDP?"

> I have never even seen a company use that

My point isn't that a company does/doesn't use it. I mentioned JSON:API because it's a valid basis of comparison, no other reason.

> What happens in reality is that I get 20 apis from 20 teams, each of them completely different principle - and am supposed to build an universal auth layer for that. That's much more painful than in the companies that decided to go for GraphQL only.

But you have by your own admission never seen another company use JSON:API.. therefore you don't actually know that it is more painful than it would be for all REST APIs.

For all I know you could, again, be talking about my Stopwatch REST API... hence your comparison is invalid. By the way, auth is easier for my stopwatch API than it is for GraphQL. :)