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

411–420 of 448 posts

Re: GraphQL kinda sucks

#411

Post by grumple »

vsareto wrote: post #95
grumple wrote: post #55

Earlier quoted context omitted.

> 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. You aren't thinking big enough. We have a graphql API where we have a bunch of enterprise users all wanting to pull out different types of data. They can decide what they want to get, and pull exactly that data. They want access to different tables, fields, and f…

I guess it works, but it still seems like an extra step compared to giving them DB access unless they're in some weird place where they can learn to use GraphQL but not Sql/NoSql

The issue is we don't want them having direct db access. Aside from multitenency, permissions, and configuration issues (all solved by graphql) they could easily bring down a database instance (avoided via limits we impose via our server). If we didn't have multitenancy then it wouldn't be a problem.

But there's also the issue that some presentation and business logic is also provided by the graphql schema. Graphql knows which nodes connect, the db itself doesn't. And special cases like overrides, formatting, etc can be handled by the graphql server.

Re: GraphQL kinda sucks

#412

Post by kubami »

mccorrinall wrote: post #42
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…

I love consuming graphql as a client. But writing resolvers and all that stuff on the backend? God, I hate it!

It's very enjoyable with python. Especially given integrations with frameworks like django.

Re: GraphQL kinda sucks

#413

Post by scottwick »

wes-k wrote: post #249
scottwick wrote: post #238

A frontend application that I work on has each component making separate tiny GraphQL queries to render just what it needs. The result is often 5-10+ GraphQL requests to render a single page. Is this a common practice? It seems like a lot of overhead to me since the backend has to perform some redundant queries (i.e. fetch and authorize the user, etc.) in order to serve each of those requests. I had thought one of th…

Use Apollo, it can stitch all those queries together into one deduped query. It’s awesome!

Could you point me to some documentation about this? Is this something that's built in to Apollo? Or just that Apollo enables building this sort of architecture more easily?

Re: GraphQL kinda sucks

#414

Post by chpmrc »

spion wrote: post #312
chpmrc wrote: post #290

Earlier quoted context omitted.

> 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 wat…

I'm not familiar with LINQ and even though it might be a good solution we're not debating GraphQL vs LINQ (which, as far as I can tell, is specific to C#, at least its reference implementation), I'm questioning your "string is bad" statement which, IMHO, doesn't make any sense.

Re: GraphQL kinda sucks

#415

Post by pheres »

willjp wrote: post #137

I think graphql is fantastic, and solves tricky design decisions (versioning, precise rest queries). However, I don't believe all graphql client libraries are created equally, and I strongly prefer those that are simpler, and closer to graphql's own syntax (ex. ariadne). This is an opinion though, my preference is generally explicit > implicit.

or server libraries for tha matter.

Everyone's experience differs quite a bit depending on the used client library (plain, apollo or relay) or the server library specific for your server languages.

Re: GraphQL kinda sucks

#416

Post by chpmrc »

spion wrote: post #341
valenterry wrote: post #337

Earlier quoted context omitted.

It would be helpful if you actually explain how LINQ does it better.

LINQ lets you write SQL queries using the (.NET) language in which you write all your other code. This means you get to take full advantage of the language (and language service) features, including the typechecker, code completion etc. Examples: https://www.c-sharpcorner.com/article/writing-complex-querie... The hard bit here is making sure the language type-checker is fully aware of the involved types, both while w…

This is just a wrapper for SQL, every language has one. The same is true for GraphQL, I've never written a GraphQL scema or query by hand, always used a good wrapper that handled all the type safety I needed. Constructing GQL queries manually is the equivalent of doing it with SQL.

At this point I'm pretty sure you're conflating the underlying technology with what a wrapper could do on top of it. And in that regard I absolutely agree with you: raw GraphQL doesn't make any sense, the same way raw SQL (in 2022) doesn't make sense either.

EDIT (mandatory before I get lynched lol): except in cases where the wrapper builds a query that is inefficient or should be tweaked manually.

Re: GraphQL kinda sucks

#417

Post by spion »

chpmrc wrote: post #416
spion wrote: post #341

Earlier quoted context omitted.

LINQ lets you write SQL queries using the (.NET) language in which you write all your other code. This means you get to take full advantage of the language (and language service) features, including the typechecker, code completion etc. Examples: https://www.c-sharpcorner.com/article/writing-complex-querie... The hard bit here is making sure the language type-checker is fully aware of the involved types, both while w…

This is just a wrapper for SQL, every language has one. The same is true for GraphQL, I've never written a GraphQL scema or query by hand, always used a good wrapper that handled all the type safety I needed. Constructing GQL queries manually is the equivalent of doing it with SQL. At this point I'm pretty sure you're conflating the underlying technology with what a wrapper could do on top of it. And in that regard I…

> I've never written a GraphQL scema or query by hand, always used a good wrapper

Could you give me an example of a good client wrapper that doesn't require you to write queries as strings?

Re: GraphQL kinda sucks

#418

Post by valenterry »

spion wrote: post #417
chpmrc wrote: post #416

Earlier quoted context omitted.

This is just a wrapper for SQL, every language has one. The same is true for GraphQL, I've never written a GraphQL scema or query by hand, always used a good wrapper that handled all the type safety I needed. Constructing GQL queries manually is the equivalent of doing it with SQL. At this point I'm pretty sure you're conflating the underlying technology with what a wrapper could do on top of it. And in that regard I…

> I've never written a GraphQL scema or query by hand, always used a good wrapper Could you give me an example of a good client wrapper that doesn't require you to write queries as strings?

Not sure if you consider it "good" but I've used this one quite successfully: https://ghostdogpr.github.io/caliban/docs/client.html#query-...

Re: GraphQL kinda sucks

#419

Post by nawgz »

kehrin wrote: post #162
nawgz wrote: post #105

Earlier quoted context omitted.

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.

It's true there's nothing in the spec preventing from returning that kind of thing, for instance a JSONB column in your underlying RDBMS would probably lead to what you describe, but it's more that when using SQL you can make "anonymous" queries where you say "give me all columns, I'll deal with their names myself", while GQL is more like "give me all these keys" and there's no way to not specify the key. I don't have great language tools to speak precisely here, hope it makes sense.

Re: GraphQL kinda sucks

#420

Post by nawgz »

ant1oz wrote: post #197
nawgz wrote: post #99

Earlier quoted context omitted.

Hasura :)

Have you every tried to version your permissions on Hasura? Not cool. Product polish is amazing, and I love the postgresql integration.

Nope, I haven't, here's hoping I won't need to!

First time thinking about the situation, sounds to me like you'd need to just make a new set of roles no? I can't imagine they'd have version support for that, not like the underlying datastore does

Post reply on HN