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

421–430 of 448 posts

Re: GraphQL kinda sucks

#421

Post by minusf »

soccersofia15 wrote: post #166
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.

Based on your logic, you’ve never worked for Airbnb, Uber, Facebook, Twitter, etc… which is also funny cause they have fantastic engineering culture. What a strange way to filter yourself out of great engineering companies just because of a piece of technology

doesnt matter how beautiful the engineering culture/talented the pool if it works on ads/surveillance/facebook.

Re: GraphQL kinda sucks

#422

Post by jensneuse »

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…

We solved this by turning GraphQL into a compile time problem and replacing it with JSON-RPC as the transport, keeping GraphQL entirely hidden on the server. It's not just great for security and performance reasons, but also comes with a lot of other benefits, like you can inject claims into Operations. Here's some more info: https://docs.wundergraph.com/docs/features/graphql-to-json-r...

Re: GraphQL kinda sucks

#423

Post by ryanbrunner »

Aeolun wrote: post #365
ryanbrunner wrote: post #346

Earlier quoted context omitted.

In my experience, "let's do something non-scalable and obviously wrong while we're exploring the problem space and replace it with something better before shipping" reduces to "let's do something non-scalable and ship to production" 100% of the time.

So you are saying it works? At least all the production systems where we’ve done this work fine, they’re just inefficient, feel vaguely dirty, and are unpleasant to work on. They’re still bringing in boatloads of money though.

I think the risk with unrestricted access to your database via GraphQL is that it's potentially a very easy DOS attack sitting waiting to be abused, and potentially a security risk if there's some information you shouldn't be exposing (as a very easy example, allowing unrestricted access to a user database would reveal password hashes, reset tokens, etc. which should never be available in a API).

I'm a fan of YAGNI, but basic security and leaving your system trivially vulnerable to attacks are a couple of exceptions in my mind.

Re: GraphQL kinda sucks

#424

Post by krainboltgreene »

imtringued wrote: post #397
krainboltgreene wrote: post #385

Earlier quoted context omitted.

> Sure, you could have a syntax for requesting (potentially recursive) nested resources in the query string of a REST API Or you could just make an endpoint that gives you the data you want.

That endpoint has to be unique for the client, otherwise someone else could abuse this API and when you filter out an attribute the rogue user depends on, you break their application.

No it doesn't. It's just a GET request with a parameter or two. People make this stuff so hard when it doesn't need to be.

Re: GraphQL kinda sucks

#425

Post by OJFord »

ojkelly wrote: post #376
OJFord wrote: post #344

You forgot number 1: '200 your graphql request succeeded, here are all your errors'. ...I get it, the gql request did succeed, I've previously described it as like a 'layer 8' on top of HTTP: the problem being that all the tooling is for HTTP. I wish 'REST' was one thing - with generated OpenAPI servers/clients & 'links' for example we could achieve what gql sets out to, if only there was a single way to do it.

Your request could be fulfilled by multiple services, some of which may have errors. Building on this are result types, where you can return a union with the intended type and something like AccessDenied for specific fields a user does have access to, but some other user might. Here you start to model the happy and unhappy paths of the data model. GraphQL itself doesn’t really say anything about the network layer, it…

Like I said, I get it. (And fwiw '200/4xx/5xx' also sit in the application layer, just HTTP not GraphQL, which is why I described it as like a 'layer 8' (a fictional one above application) over HTTP.) It's just not a good 'DX'.

Re: GraphQL kinda sucks

#426

Post by BLanen »

zoover2020 wrote: post #125
BLanen wrote: post #115

Graphql gets hyped by people who have seriously no idea what the hard problems in apis are. It quite literally solves many easy issues and pretends solve the hard ones, but does nothing to actually do this and just says that you "can". I designed a typical JSON api that had customizable fields and filters and joins and authorization on orm level on classes(could easily be extended to do authorization on fields of the…

I'm all for piggybacking off of Fielding's work, but HATEOS isn't practical and the industry reflects this.

It's not practical because HATEOAS and "Uniform interface" are unrealistic cyberpunk(in the 80s philosophical sense) pipedreams.

But people who hype graphql seems to imagine graphql solves such things. Which it doesn't do at all.

Re: GraphQL kinda sucks

#427

Post by gitgud »

philliphaydon wrote: post #51

> It can save you bandwidth. Get what you ask for and no more I feel like this a false truth. Most people are building a web app, or a mobile app and consuming an api and displaying all the data they retrieve. If you have an rest api which returns an object with 6 properties. And a graphQl scheme which returns those same 6 properties. You’re not saving anything. Now if you have a website and a mobile app, where the m…

> If you have an rest API which returns an object with 6 properties. And a graphQl scheme which returns those same 6 properties. You’re not saving anything.

Not entirely true, as it allows you schemas to scale, but your requests to remain small.

For example a "User" record might have 30 fields, and it might have more as the system evolves. But your requests that only specify "User First name" will remain the same size.

Re: GraphQL kinda sucks

#428

Post by andrewingram »

zbentley wrote: post #353
squidsoup wrote: post #301

Earlier quoted context omitted.

> Front end devs save time by.... sharing queries. So component B ends up fetching records it has no use for because its sharing GQL with component A An unfortunate problem that really only exists with Apollo. Facebook’s graphql client, relay, does not have this issue as it requires each component to explicitly declare its data dependencies.

> really only exists with Apollo Citation needed. If two components call into the same data fetching utility for expediency's sake, and that utility queries data that one or both components do not need, you have this problem. What makes that uniquely likely with Apollo?

It’s more that compared to Relay, which is explicitly designed around preventing components using data they didn’t explicitly declare as a dependency, Apollo (along with most other GraphQL clients) doesn’t go that extra mile.

Whether it’s a React component, or a just a plain old function, Relay has mechanisms to prevent the kind of problem you’re describing. It has a steep learning curve, but it’s very well considered.

Re: GraphQL kinda sucks

#429

Post by mattbillenstein »

matsemann wrote: post #231
mattbillenstein wrote: post #202

Earlier quoted context omitted.

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

If all you do is expose simple models, it's fine. But then not much different than an auto-generated REST-api. But if you want to query deep, list of childrens etc you quickly get into queries that are very hard to write on the backend (n+1 issues quickly pop up etc). To solve those you need to write complicated loaders, which all should be very general in nature and thus you can't rely on two fields backed by the sa…

The N query is the general case which devolves to the scaler query with a list of ids with only one id...

Re: GraphQL kinda sucks

#430

Post by TechZillennial »

As a senior dev having worked with REST and GraphQL API's at scale, I'm afraid I must disagree.

I feel most people's negative opinions on GraphQL are mainly due to their own lack of familiarity and expertise on the subject. They simply don't want to RTFM.

When used properly and competently, the DX buffs far outweigh a traditional REST API.

Post reply on HN