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

101–110 of 448 posts

Re: GraphQL kinda sucks

#101

Post by jddil »

samarthr1 wrote: post #77
mark_and_sweep wrote: post #34

Earlier quoted context omitted.

But before you use RPC, try rendering your markup on the server. That, too, reduces a lot of complexity.

At cost of reducing cache ability though no? It is cheaper for me to put my react app in front of a cdn, split out my app into an api and front end than for me to have my site be entirely uncacheable. I can also cache certain endpoints behind the cdn that are mostly invariant for users. And, the network egress of json is much lesser than the egress of markup.

What? Server rendered content is infinitely more cacheable, maybe I'm not understanding what you're saying.

In the boring old days we just did it all on the server and used the semantics of HTTP to handle caching ... it worked great.

Re: GraphQL kinda sucks

#102

Post by cersa8 »

I use GraphQL (postgraphile) for my admin backend crud. This allowed me to do some incredible fast development with only minimal customisation (couple of PostgreSQL functions). Anything outside the happy path is handled by a REST API. Maybe we shouldn't think in absolutes, eg: only use GraphQL. For the same reasons I use an ORM, and raw queries where it matters most. The cliché holds true: use the right tool for the job.

Re: GraphQL kinda sucks

#103

Post by Kaze404 »

deltasevennine wrote: post #87
thdxr wrote: post #35

Be careful with anyone with a take that says some technology is 100% bad always. Given enough experience / skill you can make any technology fairly enjoyable so I've only ever seen mixed reactions at worst from people giving things a fair try. GraphQL is a way to describe not only your API but also the entities and relationships in it. This enables certain useful things for client heavy applications, like cache norma…

>Be careful with anyone with a take that says some technology is 100% bad always. Given enough experience / skill you can make any technology fairly enjoyable so I've only ever seen mixed reactions at worst from people giving things a fair try. So what does this mean? You're saying that in the universe we live in there is absolutely nothing that is 100% bad always. Everything is good for something? There is no concep…

The point is that “bad” isn’t a useful descriptor of anything regarding their real-life applications, because it simply doesn’t mean anything. Without more context, saying something is bad is just saying you dislike it with intent to present it as objective rather than subjective.

For example:

1) “Haskell is bad because it’s too theoretical” 2) “Haskell is bad in corporate environments, as its roots in mathematical and academia make it harder for people to get productive with it compared to something like Java or C#”

The difference is clear. In my opinion it’s best if people who care about what they’re saying avoids #1, and instead frames their criticism like in #2.

Note: those examples don’t reflect my actual opinion on Haskell, it’s just something I came up with while writing this.

Re: GraphQL kinda sucks

#104

Post by locutous »

svnpenn wrote: post #14

> It can save you bandwidth. Get what you ask for and no more I don't, and never have believed this argument. I would bet that JSON with Gzip or Zstd is just as small, or close enough that it doesn't matter.

Nothing prevents you from compressing the smaller response of what you asked for.

Re: GraphQL kinda sucks

#105

Post by nawgz »

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

Re: GraphQL kinda sucks

#106

Post by vlod »

> It can save you bandwidth. Get what you ask for and no more

On the other hand, you tend to do "select * from FOO" and get more data from the db, because you don't know what the caller will ask for.

I don't think I've even seen a codebase filter the SQL based on the caller. I think I tried doing it once and it was a pita. (Please correct me if it's easy).

Re: GraphQL kinda sucks

#107

Post by vikR0001 »

NonNefarious wrote: post #84
mabbo wrote: post #18

Whether it was the intention or not, I find GraphQL solved a fascinating problem: it let front end developers move faster by greatly decoupling their data needs from the backend developers. Backend developers describe the data model, expose it via graphql. Front end developers, often ones who never met those backend developers, can see the data model and just use it. They can change what they're querying on the fly,…

I thought it was supposed to do this, but then discovered that it has no way to express joins. Has this been addressed? I don't see how you can decouple the back-end data from front-end queries without that.

You can do something like this. This query can be created and run on the client:

``` const SAMPLE_JOIN_QUERY = gql` query ($main_data_id: String!) { mainData( main_data_id: $main_data_id) { id main_data_field_1 main_data_field_2 main_data_field_3 related_data{ related_data_field_1 related_data_field_2 related_data_field_3 } } } `; ```

Re: GraphQL kinda sucks

#108

Post by Kaze404 »

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

That’s a great thread. It mimics my (admittedly limited) experience with MongoDB and it’s interesting to hear that wasn’t an outlier.

Re: GraphQL kinda sucks

#109

Post by eduction »

thdxr wrote: post #35

Be careful with anyone with a take that says some technology is 100% bad always. Given enough experience / skill you can make any technology fairly enjoyable so I've only ever seen mixed reactions at worst from people giving things a fair try. GraphQL is a way to describe not only your API but also the entities and relationships in it. This enables certain useful things for client heavy applications, like cache norma…

> Be careful with anyone with a take that says some technology is 100% bad always.

This isn’t that though; the first sentence starts “GraphQL is great, but” and then the post lists first “the good” and then “the bad.” Even the provocative headline hedges with “kinda.”

I wish there was more of this sort of balanced discussion on HN. There is a tendency among devs at least in public toward trying to get others to use the tech they use and are excited about, which is understandable, but everything involves trade offs and it would be nice to hear more of those up front (as opposed to one day “mongo is the bomb” and the next “actually mongo is terrible to back to postgres for everything).

Re: GraphQL kinda sucks

#110

Post by BerislavLopac »

vikR0001 wrote: post #96
jonhohle wrote: post #89

Earlier quoted context omitted.

If that field isn’t populated aren’t you in the exact same spot?

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.

Assuming the backend actually supports mapping of that particular field.
Post reply on HN