Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GraphQL kinda sucks

news.ycombinator.com

Post reply on HN
Print view View original

201–210 of 448 posts

Re: GraphQL kinda sucks

#201

Post by speedgoose »

svnpenn wrote: post #14

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

A graphql query is usually sent inside a JSON document and a graphql response is usually a JSON document sent over HTTP with compression. You do have to upload the query but you can select only the data you need, and you can also do that in a single query compared to a classic almost REST API. That’s the part that saves bandwidth, sometimes.

Re: GraphQL kinda sucks

#202

Post by mattbillenstein »

mabbo wrote: post #18

Whether it was the intention or not, I find GraphQL solved a fascinating problem: it let front end developers move faster by greatly decoupling their data needs from the backend developers. Backend developers describe the data model, expose it via graphql. Front end developers, often ones who never met those backend developers, can see the data model and just use it. They can change what they're querying on the fly,…

Why do you hate it? What tooling are you using? I found it fairly painless in Python - Graphene/Flask.

Re: GraphQL kinda sucks

#203

Post by Kamq »

InvOfSmallC wrote: post #182

I admit I never seen a use case that justify the complexity of usage. Let's say you have a native app and a web app. I don't see these 2 changing that much in terms of data so a an API middlelayer is just simpler. At work we have a use case like: well we create the data layer that you can query the way you want and the field you want with many clients involved. So like an API where you can make composable queries. To…

> I admit I never seen a use case that justify the complexity of usage. Let's say you have a native app and a web app. I don't see these 2 changing that much in terms of data so a an API middlelayer is just simpler.

It has some benefits when you have multiple different products that need different "pieces" of the data, rather than 2 different clients for the same product.

I never quite understood how much hype it got, but it provides some nice benefits in an internal corporate environment, especially when data within said environment has an "owner" and accessing it from a new place requires an entire process.

Re: GraphQL kinda sucks

#204

Post by adra »

breckenedge wrote: post #23
mabbo wrote: post #18

Whether it was the intention or not, I find GraphQL solved a fascinating problem: it let front end developers move faster by greatly decoupling their data needs from the backend developers. Backend developers describe the data model, expose it via graphql. Front end developers, often ones who never met those backend developers, can see the data model and just use it. They can change what they're querying on the fly,…

I get specialization, but are there any other good reasons to divide product teams between frontend and backend? I guess it also helps establish patterns and contracts, but I think those are only helpful above a critical mass that I haven’t reached in my career yet.

Frontend teams are often feature partitioned at least in larger orgs. There will need to be some level of feature level backend knowledge to be had somewhere, but backend problems are often feature agnostic. Many companies conflate backend with platform, which have subtle differences, but end up working with similar results. Specialized backend teams work to develop a really good "platform" feature while frontend teams focus on developing customer/product oriented features.

Re: GraphQL kinda sucks

#205

Post by NotTameAntelope »

Meh, each of your complaints is solved by understanding GraphQL better.

If the main issue is you have to learn something complex, sure that’s probably a little fair, but it’s really easy to get GraphQL to do what you want once you’ve gotten over that initial learning curve.

Specifically, queries and mutations can literally do whatever you want them to.

Re: GraphQL kinda sucks

#206

Post by ant1oz »

ttfkam wrote: post #124
cudgy wrote: post #70

Earlier quoted context omitted.

You are right that this arrogant attitude is juvenile, but it is prevalent amongst humans in all areas. Unfortunately, there would be few developers to work with if you apply the policy of not working with arrogant, dogmatic developers.

I'm truly saddened to hear that this has been your experience throughout your career so far. It is not a universal experience. I hope you find a better managed shop soon that recognizes that it's easier to teach folks a tech stack than to teach someone to be a decent (or honest) person. Too many tech shops sabotage their culture and dozens of potentially great contributors in order to keep a few (or one) toxic contri…

Well said. I would also add that it is perfectly fine to have a list of red flags, and it is perfect fine to define your own bondaries. Graphql is a red flag for me too, as well is React and node.js, and even git to some extend. I love simplicity when designing web apps, their backend, their frontend and the deployment process in between. Although the tech is old , I came up that vue3+pouchdb+quasar is an amazing combination for a stable replicable dev environment, pwa, supports offline usage, and introduces possible p2p replication between browser's pouchdb instances trough webrtc.

React , imo, is a good over engineered library suffering from fragmentation. Angular is less fragmented, and Vue is the most elegant, performant and versatile of the 3. Good Devs choose Vue after having worked with both react and angular. React Dev never tried Vue, nor Angular Dev try React. Vue Dev usually know all 3.

Having a red flag like graphql can tell a lot about technical overview and experience in failure.

Graphql solves a caching issue that Facebook has. Makes the frontend team life easy, making the backend team life hell , big big hello. Scope changes in the backend are terrible.

Unless your team is engineered driven, and engineers take tech decision, and setup the sprints, going graphql in the backend is a recipe for disaster.

Re: GraphQL kinda sucks

#207

Post by lfauve »

ant1oz wrote: post #161

I totally agree, the list of frontend pro is super cool, especially the subscribe real time API, but on the backend, it is a pure nightmare, either using very cutting edge third parties, the authorization is a super big pain in the butt to implement. Cool you got a graph, now you need to make sure only user a can edit row b, there is the shortest path, but the data storage is still centralised. And I doubt there will…

There is: https://rxdb.info/replication-graphql.html

Re: GraphQL kinda sucks

#208

Post by mattbillenstein »

toolz wrote: post #187
grumple wrote: post #61

Earlier quoted context omitted.

Curious as to why you hate it specifically. Because what you could be doing is exposing every table / field automatically based on permissions (which you could set up a system where you don't even have to be involved).

because either the boilerplate is massive or the libraries do so much for you that you have to specialize in understanding the libraries magic - front-end plus back-end code for graphql is almost always more than a traditional REST api and I mean a lot more code, not just a bit more, so more code is strongly correlated with more problems. The exception is when you use heavy libraries that have magical APIs. Then you…

What tooling are you using that requires a massive amount of extra code? You need to define the schema and write resolvers, but that's sorta similar to what you might do in REST on the backend.

On the frontend, you have a choice to use some of the heavier libraries that support all of the features (like subscriptions) - but otherwise, you can just POST a gql query to the server and it will return a blob of json, which really isn't so much more than REST.

Re: GraphQL kinda sucks

#209

Post by adra »

quickthrower2 wrote: post #25
mabbo wrote: post #18

Whether it was the intention or not, I find GraphQL solved a fascinating problem: it let front end developers move faster by greatly decoupling their data needs from the backend developers. Backend developers describe the data model, expose it via graphql. Front end developers, often ones who never met those backend developers, can see the data model and just use it. They can change what they're querying on the fly,…

It sounds like it is promoting a siloed cogs in the machine type of work ethic. Where you are either front end or back end and no one is thinking end-to-end about the system.

Sr enough developers who's role expands beyond a single team, architects, product managers, product owners, the list goes on for the roles of people who are often task of thinking big picture about the health and "end-to-end" picture of any given software project. Your narrow synicism makes me assume you don't work in a company that has a large dev org. People specialize and if you want to be the learn and do everything person, you'll find that you're doing less and learning more which isn't a good fit for most orgs.

Re: GraphQL kinda sucks

#210

Post by the_mitsuhiko »

endisneigh wrote: post #69
jongjong wrote: post #64

Some other bad things: - Makes caching more challenging since there are now more possible permutations of the data depending on what query the client uses. A hacker could just spam your server's memory with cache entries by crafting many variations of queries. - Makes access control a lot more complicated, slower and error-prone since the query needs to be analyzed in order to determine which resources are involved i…

> - Makes caching more challenging since there are now more possible permutations of the data depending on what query the client uses. A hacker could just spam your server's memory with cache entries by crafting many variations of queries. You could use something like https://stellate.co/ . > - Makes access control a lot more complicated, slower and error-prone since the query needs to be analyzed in order to determi…

If the solution for caching problems turns out to be a hosted API proxy then there are still not enough tools available. If you put some third party infrastructure in front of your API then your availability is exactly that company's availability.
Post reply on HN