You probably don't need GraphQL

Love GraphQL, but oh man is it being over used at my company. Management sees success with one of our large apis, now all the little niche ones have to be migrated and everyone consuming them must migrate as well.

I like it, but the small 2 endpoint APIs that haven't changed in years, have small 5 field models and no related entities, has like 1 or 2 teams that consume them DO NOT need it.

LOL, "hey guys this thing hasn't changed in years, so we need you to convert your simple API request into a big ol' POST describing the entire model."
- It's old, and therefore bad.
  We really need a cultural change in this industry. Something that sits there doing its job for a decade+ with little to no change should be seen as a success.

The argument in the blog post sounds like one of those technologies that says "it works great once you have a billion users! Just wait and see."

Tried it once. It was a testing nightmare, trying to catch all the varying edge cases. Gave up and never looked back.

GraphQL is so stupid about collections of objects. If you want uniform pagination for different types of objects you have to write separate types for each.

I don't like how it composes things together. Kindof awkward when the subportions of the query need variables. Nested objects are great to form the query to just what one needs but then extra steps to decompose into what you'll actually have client-side.

Sounds like a bunch of people here don't understand the graphql use case or implementation. I've used it projects and works no worse than other solutions, and met the requirement of not having to update tons of code when queries are refactored. It's not right for everything, but the same is true for anything.

At my workplace, we use it for East-West traffic, especially the central Identity, Authentication and Authorization service which every other service needs to access, and it works great for that use case (Since it allows the downstream services to fetch information however they like). REST can do that too, but it will be cumbersome to say the least.

"GraphQL got a lot of hype because it enabled building typesafe APIs with a better developer experience than any other API"

Haha.

No.

The experience was awful.

Come at me, type-safe bros. Your favorite tech still sucks.

Actually, that's true, across the board. Your favorite technology, it has serious flaws. Frankly, it sucks.

Now get off my lawn.

Unless it's that medicine that prolonged your favorite grandparent's life and quality. That technology is pretty great. But the rest still sucks.

I haven't used GraphQL personally but I've heard interesting things about it. It sounds like you've been burned by it so I'd be interested to hear more about your opinion beyond that you think it sucks if you're willing to share some more details.
- 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 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. I swear I really did look for it. Pinky promise. https://docs.github.com/en/graphql/overview/explorer
  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!
- 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.
Not sure why you're downvoted. You're not wrong.
I say this as a member of my local GraphQL meetup group.
It solves a lot of interesting problems with APIs at scale.
But every time some hobbyist was like, "Is it worth it?" I constantly had to bite my tongue and shrug. It's like teaching a whole new paradigm.
And even though I think GraphQL is superior, it's a lot to understand and most people probably won't give AF. Fetching JSON works just fine for 99% of use cases.
- 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.