31–40 of 448 posts
I tried graphql in a microservices environment and had huge headaches over schema stitching. Turns out, if you have lots of objects from disparate sources, graphql don’t like that. Now you must stitch these schemas together into an über schema roll query and use with graphql. Maybe we missed a step. Maybe we misunderstood. Maybe it was a bad decision.
> It can save you bandwidth. Get what you ask for and no more I don't, and never have believed this argument. I would bet that JSON with Gzip or Zstd is just as small, or close enough that it doesn't matter.
If you have any data sets with an open text field that you don't care about, or where you really only need to get the ID from a wide table, it will definitely save a ton of bandwidth. How often that really matters on the other hand...
As far as the versioning goes, the prevailing wisdom seems to be that it just isn't needed on graphql apis - on graphql.org they say the best practice is to avoid breaking changes. [1] That said, versioning of a graphql api has been done at scale before. Shopify has done it, using versioning in the URL, specifically their admin data api, using month-year release dates as the versions [2] [1]: https://graphql.org/lear…
> As far as the versioning goes, the prevailing wisdom seems to be that it just isn't needed on graphql apis In reality, of course API versioning is needed. The "prevailing wisdom" is people who like the tool, don't like its limitations, and want to pretend it isn't a problem. . > That said, versioning of a graphql api has been done at scale before. Shopify has done it Perl people will happily point out that object s…
I’d recommend not picking a technology that is versionless by design if you think you’re going to need it. Also I’d dispute that versioning is needed as a rule.
Ignore all the noise and just use an RPC model between your backend and frontend. All these stupid trends and overengineered abstractions will come and go, but people will still be using plain RPC in 5, 10, 100, and 1000 years.
GraphQL is a way to describe not only your API but also the entities and relationships in it. This enables certain useful things for client heavy applications, like cache normalization. If you look at clients like URQL they enable high quality features in your app that are otherwise extremely difficult.
You can also do this with JSONAPI but the GraphQL ecosystem is more developed.
Setting up GraphQL to minimize its rough edges is incredibly difficult. I've currently landed on a combination of Pothos + Genql + URQL to enable me to do everything in typescript instead of untyped strings.
It takes very high skill to use GraphQL well. Few teams get there because they don't have the upfront time to do all the research.
But if you pull it off it can be an incredibly productive system that is friendly to iteration and refactoring. I can send you some content we've produced on this if you're interested.
That said, if I'm not working on a client heavy app, I'd just use a less featureful RPC framework.
"Very Senior Dev" here (though it amuses me to call myself that). I had managed to avoid GraphQL for a while, but recently had to actually look at it and use it. I was appalled that in this day and age, this hyped silver bullet basically requires me to build queries using strings. I was honestly surprised by this: when I first heard about the idea behind GraphQL, I was certain that I'd pass in nested data structures.…
That's like saying SQL is crap because you need to build queries by hand. Conflating a protocol/spec with its implementation and/or the way it's used is not something a "very senior dev" should do (not questioning you personally, just the validity of what you wrote in this specific comment).
There are plenty of good GraphQL libraries that make writing queries/mutations and the whole schema a breeze. I've been using graphene for Python for a couple of years and, although it has some rough edges, it's actually pretty decent. And GraphQL is quite a good mental model to work with that both backend and frontend can share.
Honestly I'm getting tired of seeing these comments on HN, it's the same for Kubernetes or other technologies. Often written by someone who didn't take the time to actually study and understand the tech and use it for actual projects. Often with no data to back it up whatsoever. The quality of posts and comments here used to be a lot higher but it's slowly turning into a plaintext version of dev.to
It's not an unpopular opinion: it's true. Graphql is a terrible piece of software/paradigm. I've completely avoided it for years. If a potential new job contacts me and they use graphql, it's an immediate no from me. It's an immediate red flag that the engineering culture at the company is poorly run and would be a nightmare to work in. Run away, as fast as possible.
"Very Senior Dev" here (though it amuses me to call myself that). I had managed to avoid GraphQL for a while, but recently had to actually look at it and use it. I was appalled that in this day and age, this hyped silver bullet basically requires me to build queries using strings. I was honestly surprised by this: when I first heard about the idea behind GraphQL, I was certain that I'd pass in nested data structures.…
> I was appalled that in this day and age, this hyped silver bullet basically requires me to build queries using strings. That's like saying SQL is crap because you need to build queries by hand. Conflating a protocol/spec with its implementation and/or the way it's used is not something a "very senior dev" should do (not questioning you personally, just the validity of what you wrote in this specific comment). There…
Ignore all the noise and just use an RPC model between your backend and frontend. All these stupid trends and overengineered abstractions will come and go, but people will still be using plain RPC in 5, 10, 100, and 1000 years.
But before you use RPC, try rendering your markup on the server. That, too, reduces a lot of complexity.
Earlier quoted context omitted.
A regular api poorly implemented will have all the same cons and none of the pros.
Just make a perfect api without any drawbacks.