GraphQL kinda sucks • Hacker News Board

Re: GraphQL kinda sucks

#161

Post by ant1oz » Sat, Aug 06, 2022, 4:32 PM UTC

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 ever be any PWA POSSIBLE with graphql, so no offline usage, no local storage , nothing cool toward the web6 decentralised stack.

Re: GraphQL kinda sucks

#162

Post by kehrin » Sat, Aug 06, 2022, 4:32 PM UTC

nawgz wrote: post #105

kehrin wrote: post #83

> It doesn't support map/tables/dictionaries. I don't understand this point. Is this talking about implementing GraphQL on the backend? Because consuming GraphQL you get a map, you get JSON! Do you mean a more specific data structures like a Set or Stack?

I think they were complaining that you couldn’t get back a query with unknown keys like a “select * from my_table” GQL equivalent

But can't you? During development I had this with errors, where I just enter "error" as a key in my query, but the actual data was JSON. So it had keys that I didn't specify, but that I received non-the-less.

Re: GraphQL kinda sucks

#163

Post by mdaniel » Sat, Aug 06, 2022, 4:34 PM UTC

thdxr wrote: post #67

meesterdude wrote: post #57

Earlier quoted context omitted.

> Given enough experience / skill you can make any technology fairly enjoyable Have you never used MongoDB?

https://twitter.com/thdxr/status/1394903426023272452?t=BjMUo...

https://threadreaderapp.com/thread/1394903426023272452.html

Re: GraphQL kinda sucks

#164

Post by chronofar » Sat, Aug 06, 2022, 4:35 PM UTC

krschultz wrote: post #120

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…

Every company I've worked for in the last 10 years had multiple apps across several platforms, each with many versions, all running in production at once. Even if you only care about the next version you are shipping and a handful in production that's a dozen variations. In a REST paradigm you over fetch because not all of these variations need the same data, or you send less but then the clients thicker because they…

> 95% of the criticism of GraphQL is people complaining that GraphQL doesn't solve the problem of preparing the API response for these different requests.

This problem is solved by quite a few GraphQL providers nowadays. Hasura, DGraph (not true graphql but close enough), Prisma. I like Hasura quite a lot for many projects. Just define your database and you instantly have a full GQL API for the clients to use however they please, no backend required really. Doesn’t work for everything, but it’s pretty great for a wide swath of projects.

Re: GraphQL kinda sucks

#165

Post by hamandcheese » Sat, Aug 06, 2022, 4:37 PM UTC

netik wrote: post #136

sholladay wrote: post #122

Earlier quoted context omitted.

A world where the front end can access any database field it wants sounds like a security / privacy nightmare to me. Of course there are ways to prevent data from being returned but that’s fragile.

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 to performance issues, because it’s not uncommon for a large, complex graphql request to have hundreds or thousands of fields (particularly when displaying lists of data to a user).

Re: GraphQL kinda sucks

#166

Post by soccersofia15 » Sat, Aug 06, 2022, 4:38 PM UTC

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

Re: GraphQL kinda sucks

#167

Post by pharmakom » Sat, Aug 06, 2022, 4:40 PM UTC

GraphQL let’s you write optimisations once that apply across all you queries which is a huge advantage.

I think we can do better than GraphQL but until that solution arrives and achieves wide adoption I will keep using it

Re: GraphQL kinda sucks

#168

Post by mdaniel » Sat, Aug 06, 2022, 4:42 PM UTC

hn_throwaway_99 wrote: post #158

jensneuse wrote: post #151

The GraphQL specification doesn't mention HTTP. It's just a query language, like SQL, but with a different focus. I understand what people complain about in this discussion. It makes sense. Talking GraphQL between client and server can be a headache. That said, I'd like to propose a completely different use case. Have you thought about using GraphQL as a "meta-language" to compose APIs? A pure Server-Side solution to…

> It's just a query language, like SQL, but with a different focus. No, no, no! I love GraphQL, and have been using it on projects for many years now, but the thing that is difficult for me to forgive the original designers of the spec that they put "QL" in the name, confusing so many developers into thinking it is a generic query language. GraphQL is simply a spec and contract for exposing an API. Its "competing tec…

It is a query language in that one can select the fields one wishes to be returned, including conditional evaluation of interior clauses via e.g. https://spec.graphql.org/October2021/#sec--skip

The field selection is certainly possible in REST via something like /foo?include=a,b,c but starts to get just downright silly with /foo?include=a,b.c[1].d,e[*].f which has now become its own DSL

Re: GraphQL kinda sucks

#169

Post by hamandcheese » Sat, Aug 06, 2022, 4:43 PM UTC

On the point of maps, I have had success solving this in two different ways.

Option 1: return a property list. In other words, a list of objects that have a key and a value. It’s easy write a getter function to search by key, or convert it to a map outright.

Option 2: make a Json custom “scalar”, send back whatever dynamic structure you want.

Re: GraphQL kinda sucks

#170

Post by pharmakom » Sat, Aug 06, 2022, 4:43 PM UTC

I like GraphQL because it allows me to expose the data once and then let front end devs run with it. It’s a bit of work upfront but it’s less work over time.