[doctor_eval]

These are just assertions with little to back them up. As TFA says, you can make all the same claims for REST. And GraphQL works the same as REST. But instead of a complex mishmash if positional and named parameters, it has a super simple query structure.

When you create a stack of REST APIs, you’re creating a DSL. But it’s a DSL with arbitrary and frequently undocumented relationships between objects, no type safety, and masses of hidden complexity.

GraphQL is simple. If you don’t think it’s simple, you don’t understand it.

> One big issue of GraphQL is also that API clients tend to suck. That's not a problem for OpenAPIs.

The clients are unnecessary. You can get ridiculously complex clients for REST, too. But you can also use GraphQL just using fetch().

The only material difference between the two from a client perspective is:

* REST gives you everything, even if you don’t want it

* GraphQL requires you to request what you want using a minimal query language.

GraphQL also lets you perform multiple queries in parallel, on the server, which REST can’t easily do.

REST is a PITA for any data model that’s more complex than CRUD.

[megadal]

> REST is a PITA for any data model that’s more complex than CRUD.

Also I'd just like to point out that for everything but queries themselves, GraphQL uses JSON. JSON is used in the C and U of GraphQL's CRUD... Explain to me why this couldn't have just been JSON and therefore a REST API again..?

Almost the only thing stopping it from being one is its "query language". I guess technically usage of one endpoint would make OpenAPI doc'ing difficult but I think possible depending on what JSON Schema/OpenAPI version you're using.

But it would also be trivial to just have separate endpoints for each schema.

You could even use all POST requests and only use the request body if you want.

[chuckadams]

> Also I'd just like to point out that for everything but queries themselves, GraphQL uses JSON.

Most clients send queries as json too, actually, not gql source. The funny thing is that GraphQL doesn't even specify JSON, or any wire format at all. It just has to be able to encode the gql type system, and JSON "just happens" to work (I'm pretty sure they did have json in mind when they wrote it, but it still isn't baked into the spec). The spec is also silent on transport, I think the whole tunneling-everything-through-POST thing came from the reference implementation.

You really seem attached to OpenAPI. I can't speak for everyone, but I for one would would much rather write SDL than json schema in yaml.

[megadal]

> you can make all the same claims for REST

That's why I mentioned OpenAPIs, which you certainly can't make the same claims about. I have never had a problem with an OpenAPI, it's almost like a litmus test of web developer competence how simple it is.

> But instead of a complex mishmash if positional and named parameters, it has a super simple query structure.

Have you ever used an OpenAPI or an OpenAPI client? I seriously implore you to look at ShipHero's GraphQL documentation and look at any OpenAPI docs and pretend like GraphQL is simpler.

But if you've ever used an OpenAPI client, you know this is just a problem in theory, not in practice. I have never accidentally passed a parameter to the body, path, query or headers when it should've been elsewhere.

The problem is non-existent, especially since most people don't write OpenAPI requests from scratch.. you can just throw the document anywhere and you will have some easier way to make requests.

And even if that's really a problem, almost every OpenAPI doc UI I've seen has an option to show you the cURL and substitutes in parameters from the UI. You could just fill out the UI and copy the cURL request.

> When you create a stack of REST APIs, you’re creating a DSL. But it’s a DSL with arbitrary and frequently undocumented relationships between objects, no type safety, and masses of hidden complexity.

I'm beginning to think this entire comment is a strawman: my argument is that a graph-based OpenAPI would have been better than GraphQL. Any REST API can be an OpenAPI. You are comparing apples to oranges.

I am comparing a RESTful Graph based data access API (like JSON:API) to GraphQL.

You are taking what sounds like the kind of REST API you'd find in a w3schools tutorial and comparing it to GraphQL.

> GraphQL is simple. If you don’t think it’s simple, you don’t understand it.

That many developers find GraphQL difficult to understand is literally a testament to its complexity. This statement contradicts itself unless you believe I'm the only developer on the internet with this opinion, which I have a hard time believing given this entire comment is filled with strawman arguments you clearly use against others who dislike GraphQL.

> The clients are unnecessary. You can get ridiculously complex clients for REST, too. But you can also use GraphQL just using fetch().

Types are unnecessary. You can get ridiculously complex with strictly typed languages, too. But you can also just type everything dynamically and go crazy if the type system in my wacky language annoys you.

> REST gives you everything, even if you don’t want it

That's completely up to the REST API. I've written several that disagree with you. I've literally written RESTful Graph based data access APIs that don't do this. Multiple. At tech startups.

> GraphQL requires you to request what you want using a minimal query language.

So it requires complexity to enforce low bandwidth, got it. There is definitely no other way to lower bandwidth than enforcing complexity.

Usually I just use ABAC. You get the fields you can see. You can select a minimal list if you want. You don't have to type out 32 field names if you need them all.

I sometimes wish GraphQL just took a chapter from SQLs book. What you described here is not a feature.

> GraphQL also lets you perform multiple queries in parallel, on the server, which REST can’t easily do.

Ironically, that is up to the GraphQL implementation. ShipHero's does not support this, and requires N+1 queries in many common cases. I suspect that's not uncommon with GraphQL APIs, but I have no evidence for this.

But my suspicion is based on the fact that rigging up a GraphQL API implementation is a daunting enough task on its own, and multiple queries feels like it would be an after-thought to someone doing a quick-and-dirty setup. Which is how most people set up bleeding-edge infrastructure (which is what GraphQL was when it was largely popular), because there's not much knowledge, documentation or expertise readily available.

> REST is a PITA for any data model that’s more complex than CRUD.

Again, you're strawmanning. You're arguing against REST, not a RESTful Graph based data access API, like JSON:API.

REST is not an API. GraphQL is. It is basically an API proxy with a query language disguised as a graph based data access API.

[brobdingnag_pp]

”I've literally written RESTful Graph based data access APIs that don't do this. Multiple. At tech startups.”

Okay mr startup man, fact is you don’t know what you’re talking about and your head is so far up your startup ass you no longer know what’s good engineering.

Why are you writing your own restful graph based data access APIs?

[megadal]

> Why are you writing your own restful graph based data access APIs?

https://en.m.wikipedia.org/wiki/Nihilism

[brobdingnag_pp]

That is a non-answer. Do you like pushing over gravestones too?