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.
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.
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 finda 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: 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!
…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…
Thousand yard stare at SOAP
Yo dawg, I heard you like XML over HTTP so I put XML in HTTP in your XML over HTTP.
So many technologies doing crap that plain old HTTP already does:
well, there’s a schema description built into compliant graphql apis and a tool called graphiql that consumes that and provides exactly that api explorer that you’re looking for. many graphql backend frameworks embed graphiql
Thank all that is holy, I did not use it. I had other options, which I chose, because I’m the boss.
Edit: I’m not proud of my occasional tendency to wind y’all up for fun, but I will say it helps proactively build my block list of folks who can’t take a joke.
If Json wasn’t status quo, coming from a language that’s status quo, all these comments could be reversed against it.
And well, if you’re not using JavaScript, Json is not that great anyways.
What I like about graphql that Json over rest doesn’t have it: fragments and types.
On types: have you ever got across bad swagger documentation? Like a parameter called something unclear like usertype, with no explanation of what it is or examples, ? Oh yeah, it’s a string. Very helpful. Well in graph ql, that parameter is likely to be called userType, which if you go into the schema file, you’ll likely see it’s an enum and you’ll also see all possible values. If your backend developer is half decent you’ll also get comments right there next to the enum. You don’t need a tool to spit out a html page that you’ll host somewher. Most reasonable information can be part of the schema file, and that’s it.
All that said, everyone now is familiar with Json and rest. Because of that, small projects are better doing it. But that supremacy will eventually end. And for large projects, specially with static types, graphql makes some things much easier, like types, fragments and unions.
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.
Meta, but yeah. It’s built for a company that is trying to continue ads and addictive behavior even on the millions of aging devices that have software versions from years ago. Large portions of it do not make sense for more typical companies.
“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.
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.
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 I did not find
a lack oftooling 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!Thousand yard stare at SOAP
So many technologies doing crap that plain old HTTP already does:
Made me spit my drink, laughing. Thank you. Very true.
well, there’s a schema description built into compliant graphql apis and a tool called graphiql that consumes that and provides exactly that api explorer that you’re looking for. many graphql backend frameworks embed graphiql
https://docs.github.com/en/graphql/overview/explorer
Today I learned! Thanks!
So did you ever actually use it? Or did you just read docs about it.
Thank all that is holy, I did not use it. I had other options, which I chose, because I’m the boss.
Edit: I’m not proud of my occasional tendency to wind y’all up for fun, but I will say it helps proactively build my block list of folks who can’t take a joke.
Hmm. You sure have a strong hatred of a thing you never used, about which your main objection (no HTML explorer) is completely untrue.
I don’t think anyone would say you need GraphQL for a tiny 10-20 endpoint project. It’s for big projects.
If Json wasn’t status quo, coming from a language that’s status quo, all these comments could be reversed against it.
And well, if you’re not using JavaScript, Json is not that great anyways.
What I like about graphql that Json over rest doesn’t have it: fragments and types.
On types: have you ever got across bad swagger documentation? Like a parameter called something unclear like usertype, with no explanation of what it is or examples, ? Oh yeah, it’s a string. Very helpful. Well in graph ql, that parameter is likely to be called userType, which if you go into the schema file, you’ll likely see it’s an enum and you’ll also see all possible values. If your backend developer is half decent you’ll also get comments right there next to the enum. You don’t need a tool to spit out a html page that you’ll host somewher. Most reasonable information can be part of the schema file, and that’s it.
All that said, everyone now is familiar with Json and rest. Because of that, small projects are better doing it. But that supremacy will eventually end. And for large projects, specially with static types, graphql makes some things much easier, like types, fragments and unions.
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.
Meta, but yeah. It’s built for a company that is trying to continue ads and addictive behavior even on the millions of aging devices that have software versions from years ago. Large portions of it do not make sense for more typical companies.