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

191–200 of 448 posts

Re: GraphQL kinda sucks

#191

Post by jwr »

chpmrc wrote: post #36
jwr wrote: post #21

"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…

> That's like saying SQL is crap because you need to build queries by hand

If we want to use these terms, then SQL is indeed crap, because you need put query parameters in-band instead of out-of-band. This led to numerous exploits over the years, as it's difficult to ensure the data is correctly escaped. GraphQL just repeated the same mistakes.

Re: GraphQL kinda sucks

#192

Post by YZF »

danabrams wrote: post #150
mLuby wrote: post #76

Having worked in big tech and small startups, I think GraphQL is a brilliant way to solve an organizational problem that massive tech companies have. It's that the team maintaining the API is different from the team that needs changes to the API. Due to the scale of the organization the latter doesn't have the access or know-how to easily add fields to that API themselves, so they have to wait for the maintainers to…

100% agree that it’s about dependence on other teams. That said, I’d much rather that we were communicating across a well defined api boundary, rather than a graphql api. You could, of course, very easily do this with an api layer in the middle.

Nobody seems to get the idea of building software out of pieces with well defined APIs any more . I would say it's not possible to build large software without adhering to this principle but I seem to be proven wrong. You can build large poor quality software and just throw more people at it.

The other part about team dependence is very true but it also shows a lack of knowledge/thinking/care by whoever formed the teams. It seemed for a while Amazon had things right both in terms of boundaries of teams and in terms of forcing people to use APIs- not sure what they do these days.

Re: GraphQL kinda sucks

#193

Post by mechanical_bear »

eknkc wrote: post #132
geuis wrote: post #28

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.

So you are sure that some tech that you avoided completely (and I assume have zero experience in) is a terrible piece of software. Great. What is your take on the postal service structure of Turkmenistan btw?

Their service scope is waaaay too broad, no reason to be responsible for quasi banking services, traffic fine payment, and utility payment processing.

Re: GraphQL kinda sucks

#195

Post by ant1oz »

satyrnein wrote: post #53
breckenedge wrote: post #23

Earlier quoted context omitted.

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.

From a management perspective, the fiction of the full stack developer that is equally skilled at everything is the easiest. You stick with that until you complicate your architecture (wisely or not) to the point where having specialists outweighs having to manage multiples queues of work and dependencies.

Worse approach imo.

Nowadays a full stack dev is an intermediate Fe dev, with junior backend skills. He will make your backend un-maintainable. Get a proper master on a proper contract rate to design your architecture.

Re: GraphQL kinda sucks

#196

Post by HelloNurse »

_3u10 wrote: post #116
vikR0001 wrote: post #96

Earlier quoted context omitted.

Let's say you need to get a field back that is already in the database table, but that wasn't previously returned by the GraphQL endpoint. All you have to do on the front end is ask for it and GraphQL will populate it for you on the server.

For external users of the API this can be quite helpful when you’re looking for the password column on the users table. For some reason I don’t think graphql actually works this way. Can’t quite put my finger on why allowing access to any column on a table might be a really bad idea.

Putting passwords in a database, and that database behind some kind of service that allows queries, is a stupid mistake that can be implemented with SOAP, CORBA, a remote shell, or any other protocol or API style.

I don't think GraphQL makes the problem worse except by encouraging experimentation by putting an unusually powerful query language in the hands of the users

Re: GraphQL kinda sucks

#197

Post by ant1oz »

nawgz wrote: post #99
mccorrinall wrote: post #42

Earlier quoted context omitted.

I love consuming graphql as a client. But writing resolvers and all that stuff on the backend? God, I hate it!

Hasura :)

Have you every tried to version your permissions on Hasura? Not cool. Product polish is amazing, and I love the postgresql integration.

Re: GraphQL kinda sucks

#198

Post by deltasevennine »

Kaze404 wrote: post #118
deltasevennine wrote: post #111

Earlier quoted context omitted.

Hard disagree. >The point is that “bad” isn’t a useful descriptor of anything regarding their real-life applications, because it simply doesn’t mean anything. This is just a complicated way of saying "Bad things have no meaning and don't exist in the universe." Without getting too pedantic, in general, nobody agrees with this concept. Sure if you get pedantic you may find a couple people in this world who enjoy punch…

Maybe I failed to express myself properly, but my point is that saying “X is bad.” (emphasis on the period) is not really saying anything. It’s much more productive if you explain why, how and in what environment X is bad, either before or after, like I did in example #2. In my experience when someone says “X is bad”, the response is often either “haha” (which the subject then changes), or “why” (which leads to perso…

>Maybe I failed to express myself properly, but my point is that saying “X is bad.” (emphasis on the period) is not really saying anything.

This logic also works for "X is good." or "GraphQL is good". This doesn't really say anything either and is an equally garbage statement following your logic. But your biases focus on the "bad" because you have a bias towards GraphQL.

Either way I don't agree. Saying something like criminals are bad is not an invalid statement.

If you want an explanation you can ask for it. If you don't care to know about the explanation then you don't need to ask for it. But just because somebody makes a statement without an explanation doesn't automatically make it invalid.

For example "The plane is about to crash, please pull up." This is a statement without an explanation (emphasis on the period). Should I demand an explanation or comply without one? In your words, was this statement "really saying anything?" Yes it was.

When you come to threads on HN it's mostly people looking for confirmation of their biases. They don't realize it, but almost everyone is doing this. If you weren't biased you would ask for deeper explanations. You would try to unravel the other persons reasoning and understand it in such a way so that you find a mistake in his understanding or your own. That's mainly why I'm here, but this thread is littered with posts following the same logical path as you.

Re: GraphQL kinda sucks

#200

Post by zokier »

jwr wrote: post #191
chpmrc wrote: post #36

Earlier quoted context omitted.

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

> That's like saying SQL is crap because you need to build queries by hand If we want to use these terms, then SQL is indeed crap, because you need put query parameters in-band instead of out-of-band. This led to numerous exploits over the years, as it's difficult to ensure the data is correctly escaped. GraphQL just repeated the same mistakes.

https://graphql.org/learn/queries/#variables ?
Post reply on HN