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

221–230 of 232 posts

Re: How and why GraphQL will influence the Sourcehut alpha

#221

Post by goto11 »

mixedCase wrote: post #220
goto11 wrote: post #214

Earlier quoted context omitted.

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.

No such thing. The database interface is SQL. The query optimizer is something run in the database.

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?

Re: How and why GraphQL will influence the Sourcehut alpha

#222

Post by goto11 »

mixedCase wrote: post #219
goto11 wrote: post #217

Earlier quoted context omitted.

> ...and other lies we tell ourselves to sleep soundly at night. So tell me how the query optimizer could possibly tell the difference between generated and hand-written SQL?

Because the SQL will not be the same. In complex cases, SQL generated by an ORM will do a combination of "more than it needs to" and plain inefficient queries. It can only do so much with what it knows about the database and the API used to call it. Hand-written SQL gives the author a chance to be more precise in its needs, not only in the SQL but also by pre-generating obvious indexes to be performant from the get-g…

Appropriate indexes will be utilized (by the query planner) whether the SQL is hand-generated or generated from some other query languages. It doesn't make a difference. How could it?

And the whole point of GraphQL is that you specify exactly what data you need, so overfetching is avoided. This is in contrast to traditional REST API's where you get a fixed resource.

Re: How and why GraphQL will influence the Sourcehut alpha

#223

Post by ahhsum »

zwkrt wrote: post #179
baddox wrote: post #38

Earlier quoted context omitted.

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

For a fun hack-week project I created a graphql server that would automatically create any necessary SQL tables to support a query given to it. So if you made the query query { user { name email { primary secondary } posts { body karma } } } It would create an entire database schema with users, emails, and posts, and the correct indexes and fk relations to support the graphql query. It would also generate mutations f…

Yo, this is legit what hasura does!

Re: How and why GraphQL will influence the Sourcehut alpha

#224

Post by jblwps »

jayd16 wrote: post #68
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…

I agree with you but I do wish for something that can improve on rest in ways GraphQL at least purports to. Query chaining/batching and specifying a sub-selection of response data seem like solid features. The graph schema seems to make good on some of the HATEOS promises. I like the idea of GraphQL but the downsides have me worried.

Graphiti always seemed like a cool project in this vein.

https://www.graphiti.dev/guides/

Re: How and why GraphQL will influence the Sourcehut alpha

#225

Post by jmull »

goto11 wrote: post #214
jmull wrote: post #169

Earlier quoted context omitted.

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

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.

There are a lot of ways to write a SQL query against a set of tables, given a set of input parameters, to get the desired result. (Not just syntactic or other superficial differences, but differences in logic and how relationships are specified.)

And, of course, an optimizer will handle different SQL queries differently.

Re: How and why GraphQL will influence the Sourcehut alpha

#226

Post by mixedCase »

goto11 wrote: post #222
mixedCase wrote: post #219

Earlier quoted context omitted.

Because the SQL will not be the same. In complex cases, SQL generated by an ORM will do a combination of "more than it needs to" and plain inefficient queries. It can only do so much with what it knows about the database and the API used to call it. Hand-written SQL gives the author a chance to be more precise in its needs, not only in the SQL but also by pre-generating obvious indexes to be performant from the get-g…

Appropriate indexes will be utilized (by the query planner) whether the SQL is hand-generated or generated from some other query languages. It doesn't make a difference. How could it? And the whole point of GraphQL is that you specify exactly what data you need, so overfetching is avoided. This is in contrast to traditional REST API's where you get a fixed resource.

> Appropriate indexes will be utilized

If present. And for that they need to be created, and which are the right ones is less obvious when working higher in the abstraction staircase.

> It doesn't make a difference. How could it?

Because the SQL generated by ORMs can be wildly stupid in many cases. Here's one blogpost with an example, where regular SQL and query builder that maps to SQL almost directly generate a decent query on a simple relation, while a full ORM does something stupid: https://blog.logrocket.com/why-you-should-avoid-orms-with-ex...

Re: How and why GraphQL will influence the Sourcehut alpha

#227

Post by mixedCase »

goto11 wrote: post #221
mixedCase wrote: post #220

Earlier quoted context omitted.

No such thing. The database interface is SQL. The query optimizer is something run in the database.

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?

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.

Re: How and why GraphQL will influence the Sourcehut alpha

#228

Post by enomad »

frou_dh wrote: post #37
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

Who will win:

Obsoleted garbage without code blocks, lambdas, if-expressions, pattern-matching, speed, kids thinking they're metaprogramming/fp gurus.

vs

Garbage dumber than C without generics, error handling, sadistic linter with unused variable-error, kids thinking they're programmers.

PS: of course python's type system better than Go, b/c anything is better than nothing. Moveover, python's type system has nothing common with python: sumtypes is useless without pattern matching and they doesn't play well with classes, scope-leaking variables isn't really static.

I believe there will be modern high-level programming language someday.

RIIR!

Re: How and why GraphQL will influence the Sourcehut alpha

#229

Post by goto11 »

mixedCase wrote: post #227
goto11 wrote: post #221

Earlier quoted context omitted.

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?

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.

This is so hand-wavy I can't really argue against it.

Re: How and why GraphQL will influence the Sourcehut alpha

#230

Post by goto11 »

mixedCase wrote: post #226
goto11 wrote: post #222

Earlier quoted context omitted.

Appropriate indexes will be utilized (by the query planner) whether the SQL is hand-generated or generated from some other query languages. It doesn't make a difference. How could it? And the whole point of GraphQL is that you specify exactly what data you need, so overfetching is avoided. This is in contrast to traditional REST API's where you get a fixed resource.

> Appropriate indexes will be utilized If present. And for that they need to be created, and which are the right ones is less obvious when working higher in the abstraction staircase. > It doesn't make a difference. How could it? Because the SQL generated by ORMs can be wildly stupid in many cases. Here's one blogpost with an example, where regular SQL and query builder that maps to SQL almost directly generate a dec…

The article shows one query generator which generates SQL which are logically equivalent to the hand written SQL, and compares it to another tool which generate inefficient queries. So it is not an inherent problem with generated SQL, just with some particular tool. So...use the right tool?

GraphQL allows you to specify what data you need. Obviously, if you use some middleware which throws this information away and just fetches everything from the database, then you have an inefficient system. But this is not a problem inherent to GraphQL or generated SQL in general.

Post reply on HN