[megadal]

Comparing GraphQL to REST and not a RESTful Graph-based data access API like JSON:API is just being disingenuous.

For GraphQL, you know it will be a nightmare. For REST, you don't, because you don't know what the actual API is. It could be a stopwatch API, obviously a stopwatch REST API is not comparable to GraphQL.

[throwaway3306a]

That doesn't matter at all. Handling authorization at the federation gateway point is a nightmare in any case. At least with GraphQL the scope is limited.

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

[throwaway3306a]

Lol... Again, the point is that unrestricted is harder than restricted to something g specifically designed with this in mind. You go make your own comparison, I compare things that matter in my work. Your Stopwatch api is probably simple, the api to generate PDFs of financial projections that I have to support is not.

[megadal]

So then your argument isn't that GraphQL is better than REST. It's that you need something specifically designed for graph based data access to handle graph based data access.

Which a REST API can do.

This argument is quite a goalpost shift from your original point: that it is easier to implement authz/access control in GraphQL than for a REST API.

An API to generate PDFs is not comparable to GraphQL, because it's not a Graph based data access API...

You're so disingenuous and unserious it's insane. This is why people hate GraphQL and it's devs: 100% of your talking points are non-sequitur copy paste arguments. It doesn't matter how much context is provided to prove what you're saying is nonsense — you'll just bulldoze right along with said nonsense anyways. It's like I'm talking with a zombie.

For the purpose of accountability I'm pointing out that so far you've:

- made an invalid comparison

- tried to elaborate on that comparison only to make several other logical errors

- goal post shifted to a totally different point than your original point after being called out

you've already pointed out that you have zero experience with JSON:API and that you can't come up with anything good to compare GraphQL with sort of demonstrates that your reasoning behind using it is not based on anything other than marketing as you have never actually used an alternative to GraphQL... Everything you've said I've only ever seen in GraphQL promo material.

So basically you got shilled and turned into a shiller.