Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How and why GraphQL will influence the Sourcehut alpha

sourcehut.org

Post reply on HN
Print view View original

31–40 of 232 posts

Re: How and why GraphQL will influence the Sourcehut alpha

#31

Post by WhatIsDukkha »

I don't understand the attraction to Graphql. (I do understand it if maybe you actually want the things that gRPC or Thrift etc gives you)

It seems like exactly the ORM solution/problem but even more abstract and less under control since it pushes the orm out to browser clients and the frontend devs.

ORM suffer from being at beyond arms length from the query analyzer in the database server.

https://en.wikipedia.org/wiki/Query_optimization

A query optimizer that's been tuned over decades by pretty serious people.

Bad queries, overfetching, sudden performance cliffs everywhere.

Graphql actually adds another query language on top of the normal orm problem. (Maybe the answer is that graphql is so simple by design that it has no dark corners but that seems like a matter of mathematical proof that I haven't seen alluded to).

Why is graphql not going to have exactly this problem as we see people actually start to work seriously with it?

Four or five implementations in javascript, haskell and now go. From what I could see none of them were mentioning query optimization as an aspiration.

Re: How and why GraphQL will influence the Sourcehut alpha

#32

Post by tptacek »

CameronNemo wrote: post #22
philosopher1234 wrote: post #19

Earlier quoted context omitted.

Could you name some specific rough edges and missing functionality that have frustrated you? I'm a big fan of Go and have a good experience with it, so I'd be very curious to hear from someone with an opposite experience.

On several occasions I have gotten panics (segfaults), many times without using CGo. This is not something I would expect from a "high level" language that has a garbage collector. The constant use of generated code is another real pain point, particularly when I am writing business logic that needs to operate on generated types for which there is no interface available that does what I need (and why would there be?…

Null pointer exceptions in Go are, technically, SEGVs. But they're just NPEs. Do you have something more interesting than that?

Re: How and why GraphQL will influence the Sourcehut alpha

#33

Post by searchableguy »

WhatIsDukkha wrote: post #31

I don't understand the attraction to Graphql. (I do understand it if maybe you actually want the things that gRPC or Thrift etc gives you) It seems like exactly the ORM solution/problem but even more abstract and less under control since it pushes the orm out to browser clients and the frontend devs. ORM suffer from being at beyond arms length from the query analyzer in the database server. https://en.wikipedia.org/w…

That is upto the graphql framework and the consumers of them. Graphql is just a query language.

You need to have data loader (batching) on the backend to avoid n+1 queries and some other similar stuff with cache to improve the performance.

You also have cache and batching on the frontend usually. Apollo client (most popular graphql client in js) uses a normalized caching strategy (overkill and a pain).

For rate/abuse limiting, graphql requires a completely different approach. It's either point based on the numbers of nodes or edges you request so you can calculate the burden of the query before you execute it or deep introspection to avoid crashing your database. Query white listing is another option.

There are few other pain points you need to implement when you scale up. So yeah defo not needed if it's only a small project.

Re: How and why GraphQL will influence the Sourcehut alpha

#35

Post by kevan »

WhatIsDukkha wrote: post #31

I don't understand the attraction to Graphql. (I do understand it if maybe you actually want the things that gRPC or Thrift etc gives you) It seems like exactly the ORM solution/problem but even more abstract and less under control since it pushes the orm out to browser clients and the frontend devs. ORM suffer from being at beyond arms length from the query analyzer in the database server. https://en.wikipedia.org/w…

Seems like you're looking at this through the lens of a single system that could submit a query to a single database and get all the data it needs. From that perspective GraphQL is definitely an extra layer that probably doesn't make sense. But even then there's still some value in letting the client specify the shape of the the data it needs and having client SDKs (there's definitely non-GraphQL ways to achieve these too).

My impression is GraphQL starts to shine when you have multiple backend systems, probably separated based on your org chart, and the frontend team needs to stitch them together for cohesive UX. The benchmark isn't absolute performance here, it's whether it performs better than the poor mobile app making a dozen separate API calls to different backends to stitch together a view.

Re: How and why GraphQL will influence the Sourcehut alpha

#36

Post by CameronNemo »

philosopher1234 wrote: post #25
CameronNemo wrote: post #22

Earlier quoted context omitted.

On several occasions I have gotten panics (segfaults), many times without using CGo. This is not something I would expect from a "high level" language that has a garbage collector. The constant use of generated code is another real pain point, particularly when I am writing business logic that needs to operate on generated types for which there is no interface available that does what I need (and why would there be?…

>The constant use of generated code is another real pain point, particularly when I am writing business logic that needs to operate on generated types for which there is no interface available that does what I need (and why would there be? how would the library/codegen-tool author know all the permutations of business logic that might be out there?). Not sure what you mean here. Is there a particular codegen tool you…

I'm not working on anything particularly interesting. Standard CRUD service. Codegen tools used are protoc, SQLBoiler, and some custom bits. Reflection is being used to intermediate between protobuf generated types and orm types.

Re: How and why GraphQL will influence the Sourcehut alpha

#37

Post by frou_dh »

RcouF1uZ4gsC wrote: post #16

> My work on SourceHut has, on the whole, really soured my opinion of Python as a serious language for large projects. A lot of the things thank make Python great for small projects, really bite you on a large or long-lived project. For me, the two biggest are lack of types and indentation for scoping. It is really easy to mess up white space during an edit or refactor. In many languages you would just reformat. In p…

Python has a better static typesystem than Go does:

https://mypy.readthedocs.io/en/stable/kinds_of_types.html#un...

https://mypy.readthedocs.io/en/stable/kinds_of_types.html#op...

https://mypy.readthedocs.io/en/stable/generics.html

https://mypy.readthedocs.io/en/stable/protocols.html

Re: How and why GraphQL will influence the Sourcehut alpha

#38

Post by baddox »

WhatIsDukkha wrote: post #31

I don't understand the attraction to Graphql. (I do understand it if maybe you actually want the things that gRPC or Thrift etc gives you) It seems like exactly the ORM solution/problem but even more abstract and less under control since it pushes the orm out to browser clients and the frontend devs. ORM suffer from being at beyond arms length from the query analyzer in the database server. https://en.wikipedia.org/w…

GraphQL is quite similar to SQL. They’re both declarative languages, but GraphQL is declaring a desired data format, whereas SQL is declaring (roughly) a set of relational algebra operations to apply to a relational database. GraphQL is really nothing like an ORM beyond the fact that they are both software tools used to get data from a database. You might use an ORM to implement the GraphQL resolvers, but that’s certainly not required.

I wouldn’t expect the performance issues to be much more problematic than they would be for REST endpoints that offer similar functionality. If you’re offering a public API, then either way you’re going to need to solve for clients who are requesting too many expensive resources. If you control the client and the server, then you probably don’t need to worry about it beyond the testing of your client code you would need to do anyway.

As far as query optimization goes, that’s largely out of scope of GraphQL itself, although many server implementations offer interesting ways to fulfill GraphQL queries. Dataloader is neat, and beyond that, I believe you can do any inspection of the query request you want, so you could for example see the nested path “Publisher -> Book -> Author -> name” and decide to join all three of those tables together. I’m not aware of any tools that provide this optimization automatically, but it’s not difficult to imagine it existing for some ORMs like those in Django or Rails.

Re: How and why GraphQL will influence the Sourcehut alpha

#39

Post by PostThisTooFast »

WhatIsDukkha wrote: post #31

I don't understand the attraction to Graphql. (I do understand it if maybe you actually want the things that gRPC or Thrift etc gives you) It seems like exactly the ORM solution/problem but even more abstract and less under control since it pushes the orm out to browser clients and the frontend devs. ORM suffer from being at beyond arms length from the query analyzer in the database server. https://en.wikipedia.org/w…

Yeah, I thought it was going to be a breakthrough, which would relieve developers from the coding effort to keep the server-side and client-side query serialization in sync.

But no. Last I checked, it couldn't even express joins. So how is that useful?

Re: How and why GraphQL will influence the Sourcehut alpha

#40

Post by PostThisTooFast »

tleb_ wrote: post #34

I think this article misses the explanation of why GraphQL over REST. I usually don't like "x versus y" articles but here both have been tested on SourceHut, the hindsight should probably appear as useful. Thanks Drew and others for SourceHut.

What is SourceHut?
Post reply on HN