Programming

I think he's being downvoted because he's one of those "who needs type safety?" fools. And because of the general rambling nonsense. Yeah JSON works fine for 99% of use cases but that isn't what he said.

Oh, sure.

Primaly, it was needlessly complicated.

I read through a rabbit trail of (unconvincing) documents saying "here's why the way that has worked for decades for you isn't good enough anymore" leading to "and that's why we decided not to implement this quality of life feature you have learned to expect".

It had a "only fit for the truly faithful" cult vibe, last time I checked it, which was about a year ago.

The big thing that turned me off was I did not find ~~a lack of~~ tooling to auto-generate an HTML page that helps explore the API. It seems to me that it would be easier to do so when using strong types, not harder.

Edit 3: I never found: https://docs.github.com/en/graphql/overview/explorer I swear I really did look for it. Pinky promise.

Edit: And since I'm already in brutal honestly mode, the GraphQL docs read, to me, as being by someone who didn't really deeply understand the HTTP specification, or at least couldn't really articulate why they needed a new tool that used less (as far as I could tell from the docs) of that specification, than existing tools.

Betting against hugely popular protocols sometimes, very rarely, pays off. But GraphQL is already well on the way to being forgotten. I don't expect GraphQL to reach a tool maturity level that causes me to ever take a second look.

Edit: For context, I once bet against git. So what the hell do I know. We shall see!

Why it's good:

• you get exactly what you need. Your software makes a very specific request, and that's what you get.

• Complex queries are easily handled. In a standard rest API, you might make multiple fetch requests. One call to get all the users, another call to find a specific user's data based on their ID. GraphQL can do that with a single call.

Why it sucks:

• it's a lot of boilerplate to set up on both sides. The client needs to know exactly what they want. I found myself having to teach multiple types of engineers (those implementing the middleware, those receiving the data) how to approach.

• You need to understand the schema, the logic, how to write queries. Rest Api, you make the call and you get a response that you can easily convert into a data object and manipulate it in your own language. To use GraphQL effectively, you need to know how to do that "the GraphQL way".

• The way the data is exposed is kinda a security risk. (But so is Rest APIs in general). I feel like there's more security through insecurity in rest Api, as each endpoint is its own thing. But graphQL has one single endpoint. It all depends on how it's built.

To better explain the latter - I had to create TWO graphQL endpoints (one for clients and one for higher privileges) and it was a pain to manage. But I spent a LOT of mental resources organizing that to ensure both types of customers only got exactly what they should get. Not to say it would have been easier with rest APIs, but it would have been easier to think about.

For the record: I like graphQL as a concept. Just the complexities far outweigh the benefits my team is getting. It was like we spent $100k of dev resources to save $500 a month off our AWS bill.

As the other comment already stated: it's extremely complicated and, in my experience, causes weird splits between client and server logic. Maybe I completely misunderstood the idea, but it seems like every use case requires some code in the server to do all the traversing, which also means, that every use case needs to have logic added at both ends of the conversation, which kind of defeats the purpose of loose coupling.

All that may dissolve itself if you're having hundreds or thousands of different clients and use cases, that all boil down to a relatively small set of traversing methods in the server, but who actually has that many clients/use cases?

It all seems like it's again one of those "but Google does!!!!" technologies that simply don't make sense for 99% of projects.