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

321–330 of 448 posts

Re: GraphQL kinda sucks

#321

Post by withinboredom »

jfengel wrote: post #316
withinboredom wrote: post #283

Earlier quoted context omitted.

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.

It’s from before the https-everywhere days, or around the same time letsencrypt was started up, IIRC. Back then, I feel like security wasn’t as big of an issue, at least for less sensitive things. Like literally the entire site would be http until you got to checkout and the only reason you had the certs was to be PCI compliant.

Re: GraphQL kinda sucks

#322

Post by crabmusket »

pan69 wrote: post #298
stickfigure wrote: post #232

The biggest problem with graphql is that you have to do a lot of non-obvious work to harden your system against DOS attacks or people that want to fly by and download your whole database. It's easy to construct a query which puts unreasonable load on your system. The more fine-grained nature of boring REST calls makes it more easy to control client impact on the system. If you want to see the kind of work you actuall…

> Note that even if you use graphql for a private api to your web client, folks will reverse engineer it and use it for their own purposes. There are no private apis on the web. How is this a GraphQL specific problem?

It's not, but the OP is saying this to pre-empt the "just use GraphQL for private APIs" defence.

Re: GraphQL kinda sucks

#323

Post by agucova »

pan69 wrote: post #298
stickfigure wrote: post #232

The biggest problem with graphql is that you have to do a lot of non-obvious work to harden your system against DOS attacks or people that want to fly by and download your whole database. It's easy to construct a query which puts unreasonable load on your system. The more fine-grained nature of boring REST calls makes it more easy to control client impact on the system. If you want to see the kind of work you actuall…

> Note that even if you use graphql for a private api to your web client, folks will reverse engineer it and use it for their own purposes. There are no private apis on the web. How is this a GraphQL specific problem?

At least compared to classical REST, usually access is limited to whatever the programmer explicitly chose to add, instead of being open by default.

Re: GraphQL kinda sucks

#324

Post by dragon-hn »

hamandcheese wrote: post #165
netik wrote: post #136

Earlier quoted context omitted.

This isn’t remotely a problem. Field by field granular security is trivial to implement in GraohQL

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…

> unless you change your schema to where everything is nullable

At my current job, this was done before I was involved. It isn’t a deal breaker, but it throws away one of the best features of GraphQL.

In the end you just have every client implement the rules that should have been in an API tier (if they are competent), or worse no validation that gets you a giant mess.

Re: GraphQL kinda sucks

#325

Post by moonchrome »

ipaddr wrote: post #296
pragmatic wrote: post #172

Earlier quoted context omitted.

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?

Back in the day we call this role Webmaster. Being able to manage your server, write your code and design the website was what a true developer tried to achieve. It is strange to see developers preferring to stay in their isolated environments and not wanting to touch the entire stack.

It's not strange at all - it takes months of work to get productive with insert whatever tech stack here even when it's within your experience domain. Problem domains are really separate. Toolchains and languages are different. It's already hard to find people competent on one stack/field - hoping to find a team of competent "full-stack", in the broadest sense of the word, is probably prohibitively expensive.

Re: GraphQL kinda sucks

#326

Post by valenterry »

replygirl wrote: post #284

> It is actually a pain to use, depending on the backend you are using you'll have to manage two or more type systems if there are no code first generates in your language hasn't been a problem for years in the ts, python, and .net communities > It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be some pattern where you don't want to allow this but for the majority of situation…

> > It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be some pattern where you don't want to allow this but for the majority of situations working with json api's you'll end up with a {[key: string] : T} somewhere

> unions

Then you need to know the keys in advance

> embedded types, and custom resolvers

That is "kind of" cheating. I think OP meant a builtin type.

> OR better api design

Sometimes possible but not always.

It's a valid criticism. Emulating another http endpoint in graphql should be super simpel in the best case, but sometimes it is not.

Another example where that is true is union inputs - you can define and return a union of types, but you cannot accept the exact same union in a mutation. Very very unfortunate.

Re: GraphQL kinda sucks

#327

Post by throwawaymaths »

I'm currently dealing with an openapi schema that declares a graphql query route. The mutations are still in rest (but it's only one endpoint -- You kind of use it like graphql). The graphql output is nonstandard so the reflection tools don't work.

The "cool" features of graphql (treating your data like a graph, so you that n+1 queries are not the consumer's issue to deal with) are not at all available, I sti have to manually do joins.

I am terrified that since graphql is all "you don't have to version your shit" there will be a breaking API change in the future that I (or worse, someone not me) will have to watch out for, so on that day our supply chain database will be horribly broken.

What the hell happened that we got APIs like this?

Re: GraphQL kinda sucks

#328

Post by valenterry »

zelphirkalt wrote: post #287

Do not forget, that GraphQL also cannot get you arbitrarily nested structure, if the client doesn't know the structure ahead of time. Its strength of defining of the structure you want returned, also becomes its weakness. If there is some tree structure you want to query, you will need to work around it. This has been discussed at length on github issues and there is unwillingness to change this. Who knows what kind…

Yes, this is a very important point.

One more very annoying shortcoming is that you can define a union of types and return them when queried, but you cannot write a mutation and ask the client to send the exact same union. You'll have to create different standalone mutations.

In general the typesystem is quite lacking. But then again, it's better than pretty much everything else language-agnostic out there.

Re: GraphQL kinda sucks

#329

Post by valenterry »

Eric_WVGG wrote: post #286

The syntax of GraphQL drives me utterly mad. I feel like there’s two approaches that one could take to approach queries: a series of programming commands (the way most ORMs work), or an attempt at “plain language” (SQL and GraphQL). Both approaches are fine, but if one wanted to take the latter approach… why not just use the syntax of SQL? It’s better in every conceivable way that GraphQL, equally legible but much mo…

Yes and no.

SQL also sucks, since you have to SELECT before defining FROM. Which means, code completion isn't there for SELECT. At least with graphql you get full code completion all the time. I agree though that it lacks in other areas. Choice between pest and colera.

Re: GraphQL kinda sucks

#330

Post by throwawaymaths »

withinboredom wrote: post #277
pdpi wrote: post #252

Earlier quoted context omitted.

Details will depend on your schema, but the moral equivalent of “SELECT * FROM master_table” is a good start.

Have you seen the “turn your database into a graphql schema” products? I shudder at the poor souls who used those products. I mean, I assume they are decent products, but man, it’s got to be so easy to screw it up and literally expose too much…

Hasura seems to be fine which we use internally in our company, though to be honest I don't do any complex queries and I don't think anyone is doing aggressively nested joins.
Post reply on HN