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

311–320 of 448 posts

Re: GraphQL kinda sucks

#311

Post by randytandy »

Hey all, didn't think this would be anything more than 1 or 2 comments.

I appreciate everyones passion and level of thought going into the replies. I will try read most of them.

Please note that if you reading this.

My intention of this post was to get a little rant off my chest and find out about potential solutions and gotchas about using GraphQl. It's unproductive attacking me or anyone else for character like "clearly not a senior developer" or "clearly never used API's before" because if anything this is about trying to find a solution and to save each other time.

Re: GraphQL kinda sucks

#312

Post by spion »

chpmrc wrote: post #290
spion wrote: post #63

Earlier quoted context omitted.

The GP is right. GraphQL is especially annoying because it looks so close to JS/JSON, yet since no thought was put into how it might integrate into existing typed languages its actually surprisingly difficult to build a type-safe API around it. And yes, SQL is "bad" because you write query strings. The funny bit is that GraphQL may be just as hard to model in a type-safe way as SQL is, if not a little harder. At leas…

> yet since no thought was put into how it might integrate into existing typed languages [...] Says who? > [...] its actually surprisingly difficult to build a type-safe API around it. Again, says who? The consumers of the APIs I work on are mostly written in Typescript and constructing types based on the GraphQL schema is a completely automated process. Are you telling me that it's easier to build type safe APIs bas…

> Says who?

Says me, and also any other person that has tried to build a type-safe GraphQL query builder

> Consumers of the APIs I work on are mostly written in Typescript and constructing types based on the GraphQL schema is a completely automated process

Constructing "types" of what kind, and in what way? Types for queries? Do you need to rerun the tool every time you modify any of your queries? Does it need to watch your query strings to generate the right types for them?

> Ok then every single language is bad because every language's syntax is based on (conceptually) constructing strings. I don't get your point.

Instead of arguing, why not look at what LINQ does?

For the best experience, you should probably try them with an editor/compiler: https://github.com/dotnet/try-samples#basics

Re: GraphQL kinda sucks

#313

Post by breckenedge »

TheAceOfHearts wrote: post #144
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.

It depends on the kind of application and scale. Consider a large and complex application like Discord or Figma. Past a certain point, it's hard for anyone to know how every single detail works. You should probably be comfortable enough to work with both ends of the spectrum, but specialization allows you to do a much deeper dive into complex subjects. A backend engineer probably has a much deeper understanding of ev…

Right, that’s specialization. IMO those people still belong on the same feature implementation team for most organizations out there.

Re: GraphQL kinda sucks

#315

Post by breckenedge »

pragmatic wrote: post #172
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.

I think you are saying why not combine specialists on one team vs the “everyone is fullstack+devops” amateur hour dystopia that is becoming all too common?

I think we’re all amateurs at some part of the stack. I am not the CircleCI dude in my current gig, some other competent engineer is, but I’ve been the Jenkins dude in the past because I cared about it the most.

Re: GraphQL kinda sucks

#316

Post by jfengel »

withinboredom wrote: post #283
hamandcheese wrote: post #165

Earlier quoted context omitted.

I have to disagree with you there. It is possible, but it causes other annoying problems. For example, field-level security pretty much means every field could be null at any time. Depending on your graphql server implementation, this might cause an entire request to fail rather than just that field to be omitted, unless you change your schema to where everything is nullable. Checking every field can also easily lead…

Not to mention GraphQL wasn’t designed with security and user-state in mind. It was an afterthought that was bolted on, varying from framework implementation to implementation.

How the heck was that not on their minds from day 1? It's the most obvious question to ask about a project like that.

Re: GraphQL kinda sucks

#317

Post by didip »

graphql sucks ass for backend and infra people, the people who need to scale it.

It also doesn’t speak normal REST dialect so you are missing out on basic things like status 200.

Re: GraphQL kinda sucks

#318

Post by MisterSandman »

jddil wrote: post #223
Guid_NewGuid wrote: post #138

Hmm, I feel weird reading all this criticism of GQL. It reminds me of when our place switched to it and I was constantly slagging it off until my friend/colleague said "do you actually hate it or you just don't understand it?". Default hostility to new concepts and frameworks can save a lot of time, energy and mistakes in software but sometimes for some use cases the new (variation of an old) solution can be superior…

You haven't actually described any of the unique parts of GraphQL though. Generating a typesafe API whose schema is defined in a single place is trivial with an OpenApi spec and a client generator What I've noticed is people get their first taste of a type safe api and automatic client creation via GraphQL and don't understand that exists without it.

> What I've noticed is people get their first taste of a type safe api and automatic client creation via GraphQL and don't understand that exists without it.

I mean, yes, you can technically write any project in C if you're smart and dedicated enough, but data scientists still use Python because it's easier to work with for the things they need to do. The fact that GraphQL is inherently safe, while REST is inherently not, is why people like GraphQL. OpenAPI is hardly the standard in Rest APIs.

Re: GraphQL kinda sucks

#319

Post by ramesh31 »

It suffers the same peoblem as WSDL, (or “proper” REST for that matter), which is inflexibility and boilerplate. It provides a mechanics garage worth of tooling when you probably just need a swiss army knife.

Re: GraphQL kinda sucks

#320

Post by ramesh31 »

I woyld really love to be able to consume GraphQL API’s all the time, but I would never ever want to have to write or maintain one. That pretty much sums up the problem.
Post reply on HN