[doctor_eval]

This is nonsense. GraphQL queries are simple HTTP requests, with no more complexity than REST. You POST a query string and some JSON and it’s done. If your client makes it harder than that, don’t use it.

Here’s my workflow for creating an API with Postgraphile:

    create view graphql.object as select some,columns from table;

(That’s it)

It’s trivial to query it with curl, I’d give an example but I’m afk rn.

I’ve been using GraphQL for about the same amount of time as in the article and it solved a bunch of problems for me.

It’s so easy to use, and saves so much time - once you spend the time to understand it.

[dudus]

I've veen reading about graphql forever and never understood it. Your comment finally made it click for me. Do you happen to have any more documentation around your method of working?

[doctor_eval]

Unfortunately I’m on a bus to the airport for a couple of days so I’m a bit constrained.

If you know Postgres, I would recommend taking a look at Postgraphile. It’s awesome, and comes with an explorer web UI that really helps (GraphIQL with extras). Everything happens in real time. so if you update a view, the UI updates.

There are lots of GraphQL clients but many of them do all sorts of crap you don’t need. I just use graphql-request which is super simple. But of course you can just use fetch() too.

There are also lots of “standards” for GraphQL that make it seem more complex than it is. Ignore that stuff and just start playing with a good server like Postgraphile.

Good luck!

[megadal]

> This is nonsense. GraphQL queries are simple HTTP requests, with no more complexity than REST. You POST a query string and some JSON

The complexity of GraphQL in fact begins there, and also sort of explains a lot of why GraphQL is all but simple: Why am I using a query language instead of just passing an AST via JSON, a data format every general purpose language supports very well these days?

The answer to the above question, and most of GraphQLs other complexities: Some arbitrary design decision.

Another example: GraphQL could've easily been expressed as a REST API, even an Open API. From what I have seen, with the help of VC backing and FAANG endorsement, GraphQL mostly rose to replace JSON:API, which accomplishes pretty much all of the same goals in just JSON (and is RESTful).

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

And again, why is this the case? Some arbitrary design decision.

I feel like in general, someone creating a new DSL where it's not needed (and is obviously designed to look cool rather than actually be expressive), is a good sign they're just writing the software to stroke their ego rather than reach a meaningful end.

That's why in all the promo material for GraphQL you only see the query language, and not all of the actual setup required to send a request or even what an actual GraphQL HTTP request looks like. GraphQL, the framework, is not actually as simple and elegant as GraphQL the query language attempts to portray it as.

It's almost like someone came up with a query language for fun then came up with all the details of how a web server would utilize it afterwards.

Even today, GraphQL markets itself only as a query language (A query language for your API). When, as you have already mentioned, it is more than that.

That's why most developers know vaguely what GraphQL is ("Oh, that one language") but not how it actually works in practice. And when they actually encounter it, it feels almost like a betrayal, because it's nowhere near as simple, sleek or elegant as all the marketing they saw suggested.

At least, this was my experience when having to deal with a third party GraphQL API (funny enough, they migrated from REST, see ShipHero).

[brobdingnag_pp]

Why do you mention GraphQL and JSON:API in the same sentence? The latter is at least 10x more difficult to understand with all its edge cases around entity relations and filtering.

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