←back to thread

How and why GraphQL will influence the Sourcehut alpha

(sourcehut.org)
153 points michaelanckaert | 3 comments | 11 Jun 20 04:46 UTC | HN request time: 0.667s | source
Show context
WhatIsDukkha ◴[11 Jun 20 06:44 UTC] No.23485847[source]▶
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.

replies(19): >>23485889 #>>23485918 #>>23485953 #>>23485962 #>>23486202 #>>23486714 #>>23486794 #>>23487403 #>>23487603 #>>23487611 #>>23487709 #>>23488354 #>>23488907 #>>23489619 #>>23489986 #>>23490334 #>>23491786 #>>23492176 #>>23497167 #
goto11 ◴[11 Jun 20 15:02 UTC] No.23489619[source]▶
I don't see the conflict? If the GraphQL query is translated into SQL on the server, then then the query optimizer would optimize that just as effectively as if the query had been written in SQL originally.
replies(2): >>23489782 #>>23490791 #
jmull ◴[11 Jun 20 16:54 UTC] No.23490791[source]▶
The SQL your graphql implementation’s ORM middleware generates won’t optimize as well as hand-written SQL in many cases.

A decent system will provide the hooks you need to hand optimize certain cases somehow, but There are always limitations and hoops to jump through and additional complexity to manage. The extra layers that are meant to make your life easier are getting in the way instead. (May or may not still be worth it, but the point is, it’s not a foregone conclusion.)

replies(1): >>23496969 #
goto11 ◴[12 Jun 20 07:35 UTC] No.23496969[source]▶
But why wont it optimize as well as hand-written SQL? How can the query optimizer even tell the difference? Surely the SQL is transformed into some kind of syntax-independent abstract query tree before it is passed to the optimizer.
replies(2): >>23498872 #>>23501609 #
mixedCase ◴[12 Jun 20 13:14 UTC] No.23498872[source]▶
No such thing. The database interface is SQL. The query optimizer is something run in the database.
replies(1): >>23499077 #
1. goto11 ◴[12 Jun 20 13:36 UTC] No.23499077[source]▶
Yes I mean inside the database engine. The engine receives SQL and parses it and then pass the query tree to the optimizer which generate a query plan. My question is how the optimizer could have problems if the SQL is generated as opposed to hand-written? How could that make a difference?
replies(1): >>23502636 #
2. mixedCase ◴[12 Jun 20 19:18 UTC] No.23502636[source]▶
As mentioned in another the comment, because SQL that is hand-written for non-trivial cases will too often be better than what an ORM generates.
replies(1): >>23511081 #
3. goto11 ◴[13 Jun 20 17:33 UTC] No.23511081[source]▶
This is so hand-wavy I can't really argue against it.