[deergomoo]

I remain unconvinced that GraphQL is the tech we should have chosen, but we’re using it privately to mesh together subgraphs from different teams’ various areas of concern and it seems to be working pretty well. There’s been talk of opening it up to clients, but the idea of trying to apply a permission/access control layer is nightmare material.

As for language support, I’ve used a couple of libraries on both the client and server side for both Go and PHP, and they seem pretty good. JavaScript/TypeScript definitely seem to be the first-class citizens though.

[throwaway3306a]

> but the idea of trying to apply a permission/access control layer is nightmare material.

In your case of many disparate services, the nightmare is just the same with REST.

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